Abteilung / Bereich / Datum (Tag.Monat.Jahr)
Wide-column Stores für Architekten
Analytics / Andreas Buckenhofer / 23.04.2015
Wide-column Stores für Architekten / Andreas Buckenhofer 2
1. NoSQL
2. Motivation Wide-column Stores
3. Datenmodellierung Wide-column Stores
4. Architektur
5. Use Cases
6. Zusammenfassung
Titel der PräsentationÜberblick
3
Zur PersonAndreas Buckenhofer
Andreas Buckenhofer
Senior DB ProfessionalE-Mail: [email protected]
Seit 2009 bei Daimler TSS im Fachgebiet
Data Warehouse & Data Integration (Cognos/Informatica) - Department Analytics
Schwerpunkt DWH/CRM seit 1998 als
• Entwickler
• Administrator
• Berater
Wide-column Stores für Architekten / Andreas Buckenhofer
TSS Unternehmenspräsentation / März 2015 / V9.8
Ganzheitliche Betreuung (Erhebung, Auswertung, Visualisierung und Interpretation), unabhängige Beratung und Optimierung der Geschäftsabläufe.
Von klassischer BI bis hin zu predictive und prescriptiveAnalytics bieten wir Leistungen unter Berücksichtigung der Datensicherheit.
Dabei verknüpfen wir fachliche Erfahrung und IT-Know-how im Daimler-Kontext mit dem Blick fürs große Ganze.Analytics. Das große
Ganze verstehen, um Daten nutzbar machen.
Daimler TSS China
Hub Beijing1 Mitarbeiter
Standorte
Daimler TSS Asia
Hub Kuala Lumpur36 Mitarbeiter
MY
Daimler TSS India
Hub Bangalore21 Mitarbeiter
IN
Ulm (Hauptsitz)
Raum Stuttgart
Böblingen, Echterdingen, Leinfelden, Möhringen
Berlin
DE Daimler TSS Deutschland
6 Standorte660 Mitarbeiter
CN
TSS Unternehmenspräsentation / März 2015 / V9.8
Wide-column Stores für Architekten / Andreas Buckenhofer 6
1. NoSQL
2. Motivation Wide-column Stores
3. Datenmodellierung Wide-column Stores
4. Architektur
5. Use Cases
6. Zusammenfassung
Wide-column Stores für ArchitektenÜberblick
Wide-column Stores für Architekten / Andreas Buckenhofer 7
• Key Value Stores
• Document Stores / Dokumentenorientierte Datenbanken
• Graph DBs
• Wide-column stores (column-oriented stores)
NoSQLDatenbanken
NoSQLKey Value Stores
Einfaches Datenmodell mit Paaren auseindeutigem Schlüssel und Wert/Werteliste.
Der Zugriff auf die Daten erfolgt ausschließlich über den Schlüssel.
Daten sollten idealerweise in den Speicherpassen für schnelle Lesezugriffe (Caching)
Beispiel: Redis, Aerospike, Oracle NoSQL.
Key Value
userID1 ISBN1
userID2 ISBN2, ISBN8, ISBN9
userID3
Wide-column Stores für Architekten / Andreas Buckenhofer 8
NoSQLDocument Stores
Strukturen (XML, JSON, BSON) werden in der Datenbank abgelegt.
Variables Schema.
Werte sind selbstbeschreibend (enthaltenMetadaten).
Zugriff über Schlüssel oder Indexierung möglich.
Die Datenbank interpretiert das Modell nicht.
Beispiel: MongoDB, CouchDB.
ID: 12345Name: MustermannGeboren: 04.02.1992
ID: 637Name: BergerAdresse: ab 01.01.2005
PLZ: 89004Stadt: Ulm
ab 01.07.2010PLZ: 80990Stadt: München
Wide-column Stores für Architekten / Andreas Buckenhofer 9
NoSQLGraph DBs
Das Datenmodell beinhaltet Elemente für die Modellierung von Knoten und Kanten sowie deren Eigenschaften.
Die gesuchten Information sind weniger die Daten selbst, sondern die Verknüpfungenzwischen den Daten.
Optimiert für Graphabfragen, z.B. Graphtraversal.
Beispiel: Neo4J.
user1
user2
user4
user3
user5
Wide-column Stores für Architekten / Andreas Buckenhofer 10
NoSQLWide Column Stores
Daten sind spaltenweise organisiert als Schlüssel und Werte („columns“). Diese Daten können durch übergeordnete Schlüssel weiter gruppiert werden („column family“).
Zugriff über Schlüssel.
Hohe Skalierbarkeit mit Standard HW.
Beispiel: HBase, Cassandra.
Name (Key) Value TimestampRowKey
Name (Key) Value TimestampRowKey
Name (Key) Value TimestampRowKey
Wide-column Stores für Architekten / Andreas Buckenhofer 11
Wide-column Stores für Architekten / Andreas Buckenhofer 12
1. NoSQL
2. Motivation Wide-column Stores
3. Datenmodellierung Wide-column Stores
4. Architektur
5. Use Cases
6. Zusammenfassung
Wide-column Stores für ArchitektenÜberblick
Wide-column Stores für Architekten / Andreas Buckenhofer 13
BigData – Volume, Velocity, Variety
• Speicherung großer Datenmengen und interaktive Abfragen
• Flexible Speicherung von Daten
• Variable Spalten
• Hohe Skalierbarkeit
MotivationWarum Wide-column Store?
Wide-column Stores für Architekten / Andreas Buckenhofer 14
Basis für Wide-column Stores:
• Datenmodell: Google BigTableresearch.google.com/archive/bigtable-osdi06.pdf
• Architektur Amazon Dynamo für Cassandra
Bekannteste Produkte (Apache)
MotivationWide-column Stores
Wide-column Stores für Architekten / Andreas Buckenhofer 15
MotivationHBase = Hadoop NoSQL Database
Wide-column Stores für Architekten / Andreas Buckenhofer 16
MotivationHBase - Low Latency
HDFS / Hive / MapReduce (Hadoop) HBase basiert auf HDFS
Batch Interaktiv (ms)
Sequentielles Lesen und Schreiben wahlfreies Lesen und Schreiben
Optimiert für Full Scan Optimiert für einzelne Datensätze bzw Short Scan
append-only, keine updates und deletes insert=updates und deletes
Wide-column Stores für Architekten / Andreas Buckenhofer 17
MotivationCassandra
entwickelt bei:
Wide-column Stores für Architekten / Andreas Buckenhofer 18
MotivationHBase / Cassandra Beginn
2006
2008
2010
2012
HBaseEntwicklung beginnt
HBaseApache Projekt
Cassandra 0.1
HBase 0.2
Cassandra Apache Projekt
Wide-column Stores für Architekten / Andreas Buckenhofer 19
1. NoSQL
2. Motivation Wide-column Stores
3. Datenmodellierung Wide-column Stores
4. Architektur
5. Use Cases
6. Zusammenfassung
Wide-column Stores für ArchitektenÜberblick
Wide-column Stores für Architekten / Andreas Buckenhofer 20
Datenmodellierung Wide-column StoresSpalte (column)
Name (Key) Value Timestamp
Basis: Spalte (wide-column stores, column-oriented DBs)
Key-Value Paare mit Zeitstempel
Name (Key) ist Identifikator für Spalte
Spalten werden dynamisch erzeugt (keine Definition vorab)
Wide-column Stores für Architekten / Andreas Buckenhofer 21
Datenmodellierung Wide-column StoresSpalte
Keine Datentypen
• Byte[]
• Schema-los, schema-on-read
• Gilt auch für RowKey
Kleine Zellgrößen 0-5MB
Kurze Namen/Keys für bessere Performance / weniger Datenvolumen (sofern Namen/Keys feststehen)
Speicherung von Werten als Spaltennamen und leerem Wert möglich
Wide-column Stores für Architekten / Andreas Buckenhofer 22
Datenmodellierung Wide-column StoresZeile (row)
Zeile: Menge von sortierten Spalten
Spalten sind sortiert anhand von Name (Key)
Name (Key) Value Timestamp
Name (Key) Value Timestamp
Name (Key) Value Timestamp
RowKey
Wide-column Stores für Architekten / Andreas Buckenhofer 23
Datenmodellierung Wide-column StoresZeile (row)
RowKey Design: wichtigster Teil der Datenmodellierung
• RowKeys sind die einzigen Indexe
• Gewährleistet schnellen Lesezugriff
• Antipattern: nur Zeitstempel als Rowkey, Gefahr von Hotspots beim Schreiben
• Oft zusammengesetzt (z.B. Metrik + Zeitstempel)
• Unterschiedlich lange Felder in zusammengesetzen Keys (Scan-Zugriff ist aufwändiger)
• Oft Hashing
Zeilenänderungen sind atomar, auch bei Tausenden von Spalten
Wide-column Stores für Architekten / Andreas Buckenhofer 24
Datenmodellierung Wide-column StoresColumn Family
Column Family: Menge von sortierten Zeilen
Ein oder mehrere Column Families werden zu einer Tabelle zusammengefasst
Zeile ist sortiert und indexiert durch RowKey
Name (Key) Value TimestampRowKey
Name (Key) Value TimestampRowKey
Name (Key) Value TimestampRowKey
Wide-column Stores für Architekten / Andreas Buckenhofer 25
Datenmodellierung Wide-column StoresColumn Family
Column Families können sehr breit werden, aber auch sehr schmal sein
Namen (column family qualifier) von Column Families werden vorab definiert
Keine Joins
• Denormalisierung
• Duplizierung der Daten falls nötig
• Verknüpfung / Join der Daten im Programmcode
Qualifizierter Zugriff auf eine Zelle:
{RowKey => {column family => {column qualifier (Name / Key) => {timestamp}}}}
Wide-column Stores für Architekten / Andreas Buckenhofer 26
Datenmodellierung Wide-column StoresModellierungsmuster
Entitäten
Column Family als optimierte Abfrage
Events / Zeitreihen
Wide-column Stores für Architekten / Andreas Buckenhofer 27
Datenmodellierung Wide-column StoresEntitäten
Einfacher RowKey
Einheitliche, bekannte Spaltennamen
Oft wenige Spalten
Schemalos
Wide-column Stores für Architekten / Andreas Buckenhofer 28
Datenmodellierung Wide-column StoresEntitäten - Stücklistenauflösung
P
|
+-------+
| 1x | 1x
C1 B
|
+-------+------+
| 1x | 1x | 2x
C1 C2 C3
Auftrags-prognose
Produkt-katalog
Teilebedarf
Wide-column Stores für Architekten / Andreas Buckenhofer 29
Datenmodellierung Wide-column StoresEntitäten - Stücklistenauflösung
Part C2 1 t2
Part C1 2 t1
… … …
FahrzeugID1
Part D1 3 t5
Part C5 20 t1
… … …
FahrzeugID2
Wide-column Stores für Architekten / Andreas Buckenhofer 30
Datenmodellierung Wide-column StoresColumn Family als optimierte Abfrage
Keine Indexe
Abfrage-orientiertes Datenmodell
Denormalisierung und Duplizierung
Spaltenwerte sind die Row Keys von Entitäten
Wide-column Stores für Architekten / Andreas Buckenhofer 31
Datenmodellierung Wide-column StoresColumn Family als optimierte Abfrage
Abfrage: In welchen aufgelösten Stücklisten kommt Teil C2 vor?
Scan über alle Zeilen (d.h. über alle Regionserver) �
Kein universelles Datenmodell bzw SQL wie bei RDBMS: Bei der Datenmodellierung bei Wide-column Stores ist die Berücksichtigung von Abfragen von Beginn an nötig.
Wide-column Stores für Architekten / Andreas Buckenhofer 32
Datenmodellierung Wide-column StoresEntitäten - Stücklistenauflösung
FahrzeugID3 (NULL) t2
FahrzeugID1 (NULL) t1
… … …
PartID C1
FahrzeugID4 (NULL) t2
FahrzeugID3 (NULL) t1
… … …
PartID D8
Wide-column Stores für Architekten / Andreas Buckenhofer 33
Datenmodellierung Wide-column StoresEvents / Zeitreihen
RowKey als Zeitelement
Meist zusammengesetzter RowKey zur Vermeidung von Hot Spots
Hashing einzelner RowKey-Komponenten
Spaltenwerte als Events
Spaltenwerte als Messwerte
Column Families können sehr breit werden
Wide-column Stores für Architekten / Andreas Buckenhofer 34
Datenmodellierung Wide-column StoresEvents / Zeitreihen
Änderungen führen zu einer Versionierung von Stücklisten (d.h. Abspeicherung einzelner Versionen)
FahrzeugID3 (NULL) t2
FahrzeugID1 (NULL) t1
… … …
MD5(PartID) + MD5(Änderungsdatum)
Wide-column Stores für Architekten / Andreas Buckenhofer 35
Datenmodellierung Wide-column StoresEvents / Zeitreihen - OpenTSDB
Time-Offset Messung t2
Time-Offset Messung t1
… … …
MetricKey + Basetimestamp
+10 (48.136,11.578) t2
+0 (48.137,11.577) t1
+12 (48.135,11.578) t3
01 + 1429552800
01 = codierte Metrik wieGPS-Daten, CPU, usw+Zeitstempel stündlich 20.4.2015 20:00:00
Wide-column Stores für Architekten / Andreas Buckenhofer 36
Datenmodellierung Wide-column StoresOperationen
Put
• Zeile Einfügen (insert bzw update)
Delete
• Zeile löschen
Get
• Zeile lesen
Scan
• Lesen mehrerer Zeilen (profitiert von Sortierung)
• Angabe von Filter möglich
Wide-column Stores für Architekten / Andreas Buckenhofer 37
1. NoSQL
2. Motivation Wide-column Stores
3. Datenmodellierung Wide-column Stores
4. Architektur
5. Use Cases
6. Zusammenfassung
Wide-column Stores für ArchitektenÜberblick
Wide-column Stores für Architekten / Andreas Buckenhofer 38
ArchitekturÜberblick (HBase)
HMaster
HRegionServer1 HRegionServer2 HRegionServerN
HDFS-Datanode1 HDFS-Datanode2 HDFS-DatanodeN
Client Zookeeper
Location toMeta-Tab
Wide-column Stores für Architekten / Andreas Buckenhofer 39
ArchitekturDatenverteilung
HRegionServer1 HRegionServer2 HRegionServerN
Region2 Region3
RegionX
RegionY
Region1
RowKey A
RowKey B
RowKey C
RowKey D
RowKey I
RowKey J
Region1
Wide-column Stores für Architekten / Andreas Buckenhofer 40
ArchitekturRegionserver
WAL (write-ahead
Log)
Region1
HFile
HDFS - Datanode1
HFileMemStore
Region2
HFile HFileMemStoreHFile
Block Cache
RAMFestplatte
Wide-column Stores für Architekten / Andreas Buckenhofer 41
ArchitekturRegionserver – Schreiben (Write)
WAL (write-ahead
Log)
Region1
HFile
HDFS - Datanode1
HFileMemStore
Region2
HFile HFileMemStoreHFile
1
2
Block Cache
HFile(neu)
…3
4
Wide-column Stores für Architekten / Andreas Buckenhofer 42
ArchitekturRegionserver – Lesen (Read)
WAL (write-ahead
Log)
Region1
HFile
HDFS - Datanode1
HFileMemStore
Region2
HFile HFileMemStoreHFile
1
23
4
Block Cache
3
Wide-column Stores für Architekten / Andreas Buckenhofer 43
ArchitekturDateityp: Log
WAL (Write-ahead Logs)
• Schreibezugriffe erfolgen zuerst in WAL
• Sequentielles Schreiben
• Nur Hinzufügen von Daten
• Neue Datei wird regelmäßig erstellt
• Eine aktive Datei pro Server
Wide-column Stores für Architekten / Andreas Buckenhofer 44
ArchitekturDateityp: Datendateien
HFiles
• unveränderlich (Daten werden einmalig eingefügt)
• ein oder mehrere Dateien pro Column Family (performancekritisch, falls zu viele Dateien)
• Wahlfreies (random) oder Sequentielles Lesen
• Mehrere GB groß
• werden erstellt durch Flush aus MemStore oder durch „Compaction“
• Bloom Filter (In-memory Bitmap Index zum Auffinden der RowKeys)
Links / References
• Werden erstellt bei „Region split“
Wide-column Stores für Architekten / Andreas Buckenhofer 45
ArchitekturCompactions
Zusammenführen von Datendateien und Sortierung von RowKeys
Server bleibt online
Kleinere Regionen führen zu performanteren Zusammenführungen
Minor
• Zusammenführen von HFiles (>= 2) in eine neue HFile-Datei
Major
• zusätzlich: Löschen der Daten bei Delete-Operationen
• zusätzlich: Löschen von ungültigen (expired) Zellen
• Reduzierung auf 1 HFile
Wide-column Stores für Architekten / Andreas Buckenhofer 46
ArchitekturAnbindung
API
• Viel Code
• Anwendung ist sehr stark am Datenmodell ausgerichtet
SQL
• Cassandra: CQL
• HBase: SQL over Hive
• HBase: Phoenix
Wide-column Stores für Architekten / Andreas Buckenhofer 47
1. NoSQL
2. Motivation Wide-column Stores
3. Datenmodellierung Wide-column Stores
4. Architektur
5. Use Cases
6. Zusammenfassung
Wide-column Stores für ArchitektenÜberblick
Wide-column Stores für Architekten / Andreas Buckenhofer 48
Use CasesMaterialized Views
Quelldaten
Auswertungen / Analyse
Analytische oder Adhoc-Abfragen
InteraktiveAbfragen
Mat Views
Wide-column Stores für Architekten / Andreas Buckenhofer 49
Use CasesLambda Architektur
Batch Layer
All Data
Speed Layer
RealTime Views
Serving Layer
Batch Views
Query(merge)
Data Stream, z.B. EventLogs
Wide-column Stores für Architekten / Andreas Buckenhofer 50
Use CasesSuchIndex, Text Analytics
(Text-) Quelldaten, z.B. Logs
IndizierungDokumente
Wide-column Stores für Architekten / Andreas Buckenhofer 51
1. NoSQL
2. Motivation Wide-column Stores
3. Datenmodellierung Wide-column Stores
4. Architektur
5. Use Cases
6. Zusammenfassung
Wide-column Stores für ArchitektenÜberblick
Wide-column Stores für Architekten / Andreas Buckenhofer 52
ZusammenfassungDatenmodellierung auch für BigData
• Skalierbarkeit
• Hohe Schreibperformance
• Interaktive Abfragen (ms)
•Wahlfreies Lesen und Schreiben
• Datenmodell hat mehr Struktur im Vergleich zu anderen NoSQL-DBs
• Apache Open Source
• Community
• Viele Personen + Apache, nicht nur kommerzielle Unternehmen wie Hortonworks, Cloudera, DataStax, etc
Wide-column Stores für Architekten / Andreas Buckenhofer 53
ZusammenfassungWide-column Stores
Datenmodellierung auch im Hadoop bzw NoSQL-Umfeld wichtig, um
• Daten zu verstehen
• Performanz zu garantieren
• Entwicklung zu beschleunigen
• Qualität der Software zu verbessern
• Wartungskosten zu reduzieren
• Gemeinsames Verständnis zu fördern
• Schema-on-read: Modellversionen auch nach Jahren noch verstehen
“Data modeling is the process of learning about the data, and regardless of
technology, this process must be performed for a successful application.”Quelle Zitat: Steve Hoberman: Data Modeling for Mongo DB, Technics Publications 2014
Wide-column Stores für Architekten / Andreas Buckenhofer 54
Vielen Dank!
Daimler TSS GmbH
Wilhelm-Runge-Straße 1189081 UlmTelefon +49 731 505-06Fax +49 731 505-65 [email protected]
Internet: www.daimler-tss.com
Daimler TSS GmbHSitz und Registergericht: Ulm, HRB-Nr.: 3844 Geschäftsführung: Dr. Stefan Eberhardt (Vorsitzender), Steffen Bäuerle
Wide-column Stores für Architekten / Andreas Buckenhofer 55
HBase vs CassandraEigenschaften 1(2)
HBase Cassandra
Infrastuktur Wird i.d.R. mit Hadoopverwendet (Standalonemöglich). Nutzung häufig in BigData / DWH / Analytics Architekturen.
Standalone. Nutzung häufig zur Auswertung Real/RightTime Transaktionen.
Serverknoten Master und Slaves(Regions).
Alle Knoten sind gleichberechtigt. Kein Masterknoten.
Cluster, Replikation Replikation zu einem gespiegelten Cluster möglich. Replikation über Rechenzentrumsgrenzen nicht empfohlen.
Knoten sind als Ring angeordnet. Daten werden repliziert, auch über Rechenzentrumsgrenzen hinweg möglich.
Wide-column Stores für Architekten / Andreas Buckenhofer 56
HBase vs CassandraEigenschaften 2(2)
HBase Cassandra
Sortierung RowKey Automatisch, nicht änderbar. Kurze Scans nach RowKeysmöglich und sinnvoll.
Konfigurierbar, ob Sortierung nach RowKeyerwünscht ist.
Coprocessors Erweiterung von HBasevergleichbar mit StoredProcedures, Trigger
Nicht unterstützt
CAP-Theorem CP CP oder AP möglich
Sekundäre Indexe Nein(nur über Phoenix)
Ja
Wide-column Stores für Architekten / Andreas Buckenhofer 57
DatenmodellierungSekundäre Indexe (Cassandra)
Cassandra: Indexierung von Spaltenwerten möglich
• Für Werte mit geringer (!) Kardinalität
• Gegenteil von Indexen in relationalen DBs (hohe Kardinalität)
Wide-column Stores für Architekten / Andreas Buckenhofer 58
DatenmodellierungLatenz vs Durchsatz
Niedrige Latenz Durchsatz
Put
Get Short Scan
BulkImport
FullScan
Wide-column Stores für Architekten / Andreas Buckenhofer 59
ZusammenfassungWorkloads Hadoop
Durchsatz
Interaktiv
Wahlfrei Sequentiell / Full Scan
HBaseSpark on HDFS
HDFS / MapReduce
Wide-column Stores für Architekten / Andreas Buckenhofer 60
ArchitekturCassandra
Memtables
SSTableSSTableSSTableSSTable SSTable
Compaction
Flush
CommitLogCommitLog
Daten
RAMFestplatte
Wide-column Stores für Architekten / Andreas Buckenhofer 61
ArchitekturCassandra – Ring ohne Masterknoten
row1
row1
row1