Wide-column Stores für Architekten (HBase, Cassandra)

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 Person
Andreas Buckenhofer
Andreas Buckenhofer
Senior DB Professional
E-Mail: andreas.buckenhofer@daimler.com
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 prescriptive
Analytics 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 Beijing
1 Mitarbeiter
Standorte
Daimler TSS Asia
Hub Kuala Lumpur
36 Mitarbeiter
MY
Daimler TSS India
Hub Bangalore
21 Mitarbeiter
IN
Ulm (Hauptsitz)
Raum Stuttgart
Böblingen, Echterdingen,
Leinfelden, Möhringen
Berlin
DE Daimler TSS Deutschland
6 Standorte
660 Mitarbeiter
CN
TSS Unternehmenspräsentation / März 2015 / V9.8

1. NoSQL
4. Architektur
5. Use Cases
6. Zusammenfassung
Überblick

• Key Value Stores
• Document Stores / Dokumentenorientierte Datenbanken
• Graph DBs
• Wide-column stores (column-oriented stores)
NoSQL
Datenbanken

NoSQL
Key Value Stores
Einfaches Datenmodell mit Paaren aus
eindeutigem Schlüssel und Wert/Werteliste.
Der Zugriff auf die Daten erfolgt
ausschließlich über den Schlüssel.
Daten sollten idealerweise in den Speicher
passen für schnelle Lesezugriffe (Caching)
Beispiel: Redis, Aerospike, Oracle NoSQL.
Key Value
userID1 ISBN1
userID2 ISBN2, ISBN8, ISBN9
userID3

NoSQL
Document Stores
Strukturen (XML, JSON, BSON) werden
in der Datenbank abgelegt.
Variables Schema.
Werte sind selbstbeschreibend (enthalten
Metadaten).
Zugriff über Schlüssel oder Indexierung
möglich.
Die Datenbank interpretiert das Modell
nicht.
Beispiel: MongoDB, CouchDB.
ID: 12345
Name: Mustermann
Geboren: 04.02.1992
ID: 637
Name: Berger
Adresse: ab 01.01.2005
PLZ: 89004
Stadt: Ulm
ab 01.07.2010
PLZ: 80990
Stadt: München

NoSQL
Graph 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üpfungen
zwischen den Daten.
Optimiert für Graphabfragen,
z.B. Graphtraversal.
Beispiel: Neo4J.
user1
user2
user4
user3
user5

NoSQL
Wide 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

1. NoSQL
4. Architektur
5. Use Cases
6. Zusammenfassung
Überblick

BigData – Volume, Velocity, Variety
• Speicherung großer Datenmengen und interaktive Abfragen
• Flexible Speicherung von Daten
• Variable Spalten
• Hohe Skalierbarkeit
Motivation
Warum Wide-column Store?

Basis für Wide-column Stores:
• Datenmodell: Google BigTable
research.google.com/archive/bigtable-osdi06.pdf
• Architektur Amazon Dynamo für Cassandra
Bekannteste Produkte (Apache)
Motivation
Wide-column Stores

Motivation
HBase = Hadoop NoSQL Database

Motivation
HBase - 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

Motivation
Cassandra
entwickelt bei:

Motivation
HBase / Cassandra Beginn
2006
2008
2010
2012
HBase
Entwicklung
beginnt
HBase
Apache
Projekt
Cassandra 0.1
HBase 0.2
Cassandra
Apache
Projekt

1. NoSQL
4. Architektur
5. Use Cases
6. Zusammenfassung
Überblick

Datenmodellierung Wide-column Stores
Spalte (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)

Spalte
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

Zeile (row)
Zeile: Menge von sortierten Spalten
Spalten sind sortiert anhand von Name (Key)
RowKey

Zeile (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

Column Family
Column Family: Menge von sortierten Zeilen
Ein oder mehrere Column Families werden zu einer Tabelle zusammengefasst
Zeile ist sortiert und indexiert durch RowKey

Column 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}}}}

Modellierungsmuster
Entitäten
Column Family als optimierte Abfrage
Events / Zeitreihen

Entitäten
Einfacher RowKey
Einheitliche, bekannte Spaltennamen
Oft wenige Spalten
Schemalos

Entitäten - Stücklistenauflösung
P
|
+-------+
| 1x | 1x
C1 B
|
+-------+------+
| 1x | 1x | 2x
C1 C2 C3
Auftrags-
prognose
Produkt-
katalog
Teilebedarf

Part C2 1 t2
Part C1 2 t1
… … …
FahrzeugID1
Part D1 3 t5
Part C5 20 t1
… … …
FahrzeugID2

Keine Indexe
Abfrage-orientiertes Datenmodell
Denormalisierung und Duplizierung
Spaltenwerte sind die Row Keys von Entitäten

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.

FahrzeugID3 (NULL) t2
… … …
PartID C1
… … …
PartID D8

Events / 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

Events / Zeitreihen
Änderungen führen zu einer Versionierung von Stücklisten (d.h. Abspeicherung
einzelner Versionen)
… … …
MD5(PartID) +
MD5(Änderungsdatum)

Events / 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 wie
GPS-Daten, CPU, usw
+
Zeitstempel stündlich
20.4.2015 20:00:00

Operationen
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

1. NoSQL
4. Architektur
5. Use Cases
6. Zusammenfassung
Überblick

Architektur
Überblick (HBase)
HMaster
HRegionServer1 HRegionServer2 HRegionServerN
HDFS-Datanode1 HDFS-Datanode2 HDFS-DatanodeN
Client Zookeeper
Location to
Meta-Tab

Architektur
Datenverteilung
HRegionServer1 HRegionServer2 HRegionServerN
Region2 Region3
RegionX
RegionY
Region1
RowKey A
RowKey B
RowKey C
RowKey D
RowKey I
RowKey J
Region1

Architektur
RegionserverWAL(write-aheadLog)
Region1
HFile
HDFS - Datanode1
HFile
Mem
Store
Region2
HFile HFile
Mem
Store
HFile
Block Cache
RAM
Festplatte

Architektur
Regionserver – Schreiben (Write)WAL(write-aheadLog)
Region1
HFile
HDFS - Datanode1
HFile
Mem
Store
Region2
HFile HFile
Mem
Store
HFile
1
2
Block Cache
HFile
(neu)
…3
4

Architektur
Regionserver – Lesen (Read)WAL(write-aheadLog)
Region1
HFile
HDFS - Datanode1
HFile
Mem
Store
Region2
HFile HFile
Mem
Store
HFile
1
2
3
4
Block Cache
3

Architektur
Dateityp: 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

Architektur
Dateityp: 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“

Architektur
Compactions
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

Architektur
Anbindung
API
• Viel Code
• Anwendung ist sehr stark am Datenmodell ausgerichtet
SQL
• Cassandra: CQL
• HBase: SQL over Hive
• HBase: Phoenix

1. NoSQL
4. Architektur
5. Use Cases
6. Zusammenfassung
Überblick

Use Cases
Materialized Views
Quelldaten
Auswertungen / Analyse
Analytische oder
Adhoc-Abfragen
Interaktive
Abfragen
Mat Views

Use Cases
Lambda Architektur
Batch Layer
All Data
Speed Layer
RealTime Views
Serving Layer
Batch Views
Query
(merge)
Data Stream, z.B. EventLogs

Use Cases
SuchIndex, Text Analytics
(Text-) Quelldaten, z.B. Logs
Indizierung
Dokumente

1. NoSQL
4. Architektur
5. Use Cases
6. Zusammenfassung
Überblick

Zusammenfassung
Datenmodellierung 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

Zusammenfassung
Wide-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

Vielen Dank!
Daimler TSS GmbH
Wilhelm-Runge-Straße 11
89081 Ulm
Telefon +49 731 505-06
Fax +49 731 505-65 99
tss@daimler.com
Internet: www.daimler-tss.com
Daimler TSS GmbH
Sitz und Registergericht: Ulm, HRB-Nr.: 3844
Geschäftsführung: Dr. Stefan Eberhardt (Vorsitzender), Steffen Bäuerle

HBase vs Cassandra
Eigenschaften 1(2)
HBase Cassandra
Infrastuktur Wird i.d.R. mit Hadoop
verwendet (Standalone
möglich). Nutzung häufig in
BigData / DWH / Analytics
Architekturen.
Standalone. Nutzung häufig
zur Auswertung Real/Right
Time 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.

HBase vs Cassandra
Eigenschaften 2(2)
HBase Cassandra
Sortierung RowKey Automatisch, nicht änderbar.
Kurze Scans nach RowKeys
möglich und sinnvoll.
Konfigurierbar, ob
Sortierung nach RowKey
erwünscht ist.
Coprocessors Erweiterung von HBase
vergleichbar mit Stored
Procedures, Trigger
Nicht unterstützt
CAP-Theorem CP CP oder AP möglich
Sekundäre Indexe Nein
(nur über Phoenix)
Ja

Datenmodellierung
Sekundä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)

Datenmodellierung
Latenz vs Durchsatz
Niedrige Latenz Durchsatz
Put
Get Short
Scan
Bulk
Import
Full
Scan

Zusammenfassung
Workloads Hadoop
Durchsatz
Interaktiv
Wahlfrei Sequentiell / Full Scan
HBase
Spark on HDFS
HDFS / MapReduce

Architektur
Cassandra
Memtables
SSTable
SSTable
SSTable
SSTable SSTable
Compaction
Flush
CommitLog
CommitLog
Daten
RAM
Festplatte

Architektur
Cassandra – Ring ohne Masterknoten
row1
row1
row1

Wide-column Stores für Architekten (HBase, Cassandra)

Recomendados

Recomendados

Mais conteúdo relacionado

Destaque

Destaque (20)

Semelhante a Wide-column Stores für Architekten (HBase, Cassandra)

Semelhante a Wide-column Stores für Architekten (HBase, Cassandra) (20)

Mais de Andreas Buckenhofer

Mais de Andreas Buckenhofer (7)

Wide-column Stores für Architekten (HBase, Cassandra)