8. Big Data und NoSQL-Datenbanken

8. Big Data und NoSQL-Datenbanken
 Motivation
Big Data
– wachsende Mengen und Vielfalt an Daten
– Herausforderungen
– Einsatzbereiche
 Systemarchitekturen
für Big Data Analytics
– Analyse-Pipeline, Hadoop, MapReduce
 NoSQL-Datenbanken
– Eigenschaften
– Document Stores (MongoDB)
– Graph-Datenbanken (neo4J)
 Big
Data Kompetenzzentrum ScaDS Dresden/Leipzig
SS14, © Prof. Dr. E. Rahm
8- 1
DBS 2
Big Data
SS14, © Prof. Dr. E. Rahm
8- 2
DBS 2
Wie groß ist Big Data?
 Big wandelt sich schnell
– Gigabytes, Terabytes (1012)
– Petabytes (1015), Exabytes (1018), Zettabytes (1021),……

ca 1.8 ZB wurden in 2011 erzeugt; ~8 ZB in 2015
D
E
a
x
t
a
a
b
y
s
t
i
e
z
s
e
Source: IDC’s Digital Universe study, sponsored by EMC, June 2011
SS14, © Prof. Dr. E. Rahm
DBS 2
8- 3
Datenproduzenten:
Web, Soziale Netze, Smartphones, Sensoren …
30 billion RFID
tags today
(1.3B in 2005)
12+ TBs
camera
phones world
wide
100s of
millions of
GPS
enabled
data every day
? TBs of
of tweet data
every day
4.6
billion
devices sold
annually
25+ TBs of
log data every
day
2+
billion
76 million smart meters
people on
the Web by
end 2011
in 2009…
200M by 2014
SS14, © Prof. Dr. E. Rahm
8- 4
DBS 2
Stark zunehmende Erfassung von Daten

Gartner:
– pro Tag werden 2.5 Exabytes an Daten generiert
– 90% aller Daten weltweit wurden in den 2 letzten Jahren erzeugt.
SS14, © Prof. Dr. E. Rahm
8- 5
DBS 2
Big Data Challenges
VolumeSkalierbarkeit von Terabytes
nach Petabytes (1K TBs) bis
Zettabytes (1 Milliarde TBs)
Variety variierende Komplexität:
strukturiert, teilstrukturiert,
Text / Bild / Video
Velocity:Near-Realtime, Streaming
Veracity: Vertrauenswürdigkeit
Value Erzielen des (wirtschaftl.)
Nutzens durch Analysen
SS14, © Prof. Dr. E. Rahm
8- 6
DBS 2
Potentiale für Big Data-Technologien

Analyse von Website-Navigation
 Analyse und Optimierung von Web-Advertizing und
Recommendations
 personalisierte Medizin
– auf Basis erfolgter Behandlungen (anonymisiert) in Abhängigekit
klinischer und genetischer Merkmalen

Energieversorgung: Verbrauchsanalysen, Überwachung
Windstrom-Erzeugung …
 Industrie 4.0 (“Internet der Dinge”)
 Kriminalitätsbekämpfung
– missbräuchliche Kreditkartennutzung
– Fake-Angebote/Plagiate in Auktionsplattformen oder Shops
– unwahre ärztliche Abrechnungen …
SS14, © Prof. Dr. E. Rahm
DBS 2
8- 7
Anwendungsdomänen für
Big Data Analytics
Smarter Healthcare
Multi-channel sales
Finance
Log Analysis
Homeland Security
Traffic Control
Telecom
Search Quality
Fraud and Risk
Retail: Churn, NBO
Manufacturing
SS14, © Prof. Dr. E. Rahm
Trading Analytics
8- 8
DBS 2
Big Data Analyse-Pipeline
Quelle: Agrawal et al: Big Data: Challenges and Opportunities, 2011
SS14, © Prof. Dr. E. Rahm
8- 9
DBS 2
Technologie-Trends

Massiv skalierbare Cloud-Architekturen
– mehrere Daten-Center (Cluster) mit Tausenden von Server-Rechnern und replizierter
Datenhaltung

Frameworks zur automatischen Parallelisierung datenintensiver
Aufgaben
– Hadoop und Ansätze wie Map/Reduce und Pregel/Giraph (parallele Graphverarbeitung)

Nutzung von NoSQL-DBS v.a. für weniger strukturierte Daten
 Effizientere SQL-Systeme („NewSQL“)
– In-Memory Datenbanken / Data Warehouses
– Column Stores (statt bzw zusätzlich zu Record Stores)

schnellere Externspeicher (SSD)
SS14, © Prof. Dr. E. Rahm
8- 10
DBS 2
MapReduce

Framework zur automatischen Parallelisierung von Auswertungen auf
großen Datenmengen
– Entwicklung bei Google
– Populäre Open-Source-Implementierung im Rahmen von Hadoop

Nutzung v.a. zur Verarbeitung riesiger Mengen teilstrukturierter Daten in
einem verteilten Dateisystem
– Konstruktion Suchmaschinenindex
– Clusterung von News-Artikeln
– Spam-Erkennung …
SS14, © Prof. Dr. E. Rahm
DBS 2
8- 11
MapReduce

Verwendung zweier Funktionen: Map und Reduce
 Map-Anwendung pro Eingabeobjekt zur Erzeugung von Key-value Paaren
– Jedes Key-Value-Paar wird einem Reduce-Task zugeordnet

Reduce-Anwendung für jede Objektgruppe mit gleichem Key
Reduce Phase
Grouping
Grouping
Partitioning
Grouping
Map Phase
SS14, © Prof. Dr. E. Rahm
8- 12
DBS 2
MR-Beispiel: Generierung Text-Index
hamlet.txt
to be or
not to be
12th.txt
be not
afraid of
greatness
SS14, © Prof. Dr. E. Rahm
to, hamlet.txt
be, hamlet.txt
or, hamlet.txt
not, hamlet.txt
afraid, (12th.txt)
be, (12th.txt, hamlet.txt)
greatness, (12th.txt)
not, (12th.txt, hamlet.txt)
of, (12th.txt)
or, (hamlet.txt)
to, (hamlet.txt)
be, 12th.txt
not, 12th.txt
afraid, 12th.txt
of, 12th.txt
greatness, 12th.txt
8- 13
DBS 2
NoSQL-Datenbanken
SS14, © Prof. Dr. E. Rahm
8- 14
DBS 2
Relationale Datenbanken
universelle Verbreitung und auf absehbare Zeit ungefährdet für die
meisten DB-Anwendungen

SQL = mächtige, deklarative Query-Sprache
– Standardisierung
– Breite Programmierunterstützung (JDBC, Hibernate, …)

ACID
 reife Technologie
 automatische Parallelisierung
 …
SS14, © Prof. Dr. E. Rahm
8- 15
DBS 2
Probleme (objekt-)relationaler Datenbanken

Schema-getrieben
– weniger geeignet für semi-strukturierte Daten
– zu starr für irreguläre Daten, häufige Änderungen

relativ hohe Kosten, v.a. für Parallele DBS (kein Open-Source System)

Skalierbarkeitsprobleme für Big Data (Web Scale)
– Milliarden von Webseiten
– Milliarden von Nutzern von Websites und sozialen Netzen

ACID / strenge Konsistenz nicht immer erforderlich
SS14, © Prof. Dr. E. Rahm
8- 16
DBS 2
NoSQL-Datenbanken

nach www.nosql-database.org neuartige DBS die meist
–
–
–
–



nicht-relational,
open-source,
verteilt und
horizontal (auf große Datenmengen) skalierbar sind
ursprünglicher Fokus: moderne “web-scale” Datenbanken
Entwicklung seit ca. 2009
weitere Charakteristika:
– schema-frei,
– Datenreplikation, einfache API,
– meist kein ACID (-> eventually consistent )

zunehmende Koexistenz mit SQL
– “NoSql" wird als “Not only Sql“ interpretiert
SS14, © Prof. Dr. E. Rahm
8- 17
DBS 2
Arten von NoSQL-Systemen

Key Value Stores
– Amazon Dynamo, Voldemort, Membase, Redis …
– Speicherung eines Werts (z.B. BLOB) pro nutzer-definiertem Schlüssel
bzw. Speicherung von Attribut/Wert-Paaren
– nur einfache key-basierte Lookup/Änderungs-Zugriffe (get, put)

Erweiterte Record-Stores / Wide Column Store
– Google BigData / Hbase, Hypertable, Cassandra …
– Tabellen-basierte Speicherung mit flexibler Erweiterung um neue
Attribute

Dokument-Datenbanken
– CouchDB, MongoDB …
– Speicherung semistrukturierter Daten als Dokument (z.B. JSON)

Graph-Datenbanken
– Neo4J, Titan, OrientDB …
– Speicherung / Auswertung großer Graph-Strukturen
SS14, © Prof. Dr. E. Rahm
8- 18
DBS 2
Grobeinordnung NoSQL-Systeme
SS14, © Prof. Dr. E. Rahm
8- 19
DBS 2
Key-Value Stores

Speicherung von Schlüssel-Werte-Paare
– im einfachsten Fall bleiben Werte systemseitig uninterpretiert (BLOBs)
– flexibel, kein Schema
– günstig für wenig strukturierte Inhalte bzw stark variable Inhalte, z.B. TwitterNachrichten, Webseiten etc.
– keine Verwaltung von Beziehungen

schnelle Lese/Schreibzugriffe über Schlüssel
– put (key, value)
– get (key)

keine komplexen Queries (z.B. Bereichsabfragen)
SS14, © Prof. Dr. E. Rahm
8- 20
DBS 2
Dokumenten-Datenbanken

Schemalose Speicherung von Dokumenten, v.a. im JSON-Format
 JSON (JavaScript Object Notation)
– geschachtelte Objekt-Notation
– Datentypen: String, Zahl, Array [...], Boolean, Nullwert
– Objekt { ….} umfasst Menge von Key-Value (Attribut/Wert-) Paaren

JSON einfacher als XML, leicht lesbar / schreibbar
 Beispiel (JSON vs. XML)
{
"Herausgeber": "Mastercard",
"Nummer": "1234-5678-9012-3456",
"Währung": "EURO",
"Inhaber": {
"Name": "Mustermann",
"Vorname": "Max",
"männlich": true,
"Hobbys": [ "Reiten", "Golfen", "Lesen" ],
"Kinder": [],
"Partner": null
}
}
SS14, © Prof. Dr. E. Rahm
<Kreditkarte Herausgeber="Mastercard"
Nummer="1234-5678-9012-3456"
Waehrung="EURO">
<Inhaber Name="Mustermann" Vorname="Max"
maennlich=true Partner="null">
<Hobbys>
<Hobby>Reiten</Hobby>
<Hobby>Golfen</Hobby>
<Hobby>Lesen</Hobby>
</Hobbys>
<Kinder />
</Inhaber>
</Kreditkarte>
8- 21
DBS 2
MongoDB

zunehmend Verbreitung findender Dokumenten-Store
– Fa. 10 Gen; open source-Version verfügbar
– JSON-Dokumente, gespeichert als BSON
(Binary JSON)

DB besteht aus Kollektionen von Dokumenten
 Einfache Anfragesprache
– Indexierung von Attributen möglich
– Map/Reduce-Unterstützung

Skalierbarkeit und Fehlertoleranz
– Skalierbarkeit durch horizontale Partitionierung
der Dokumentenkollektionen unter vielen Knoten
(“Sharding”)
– Automatische Replikation mit Konsistenzwahrung

kein ACID, z.B. bzgl Synchronisation
– Änderungen nur bzgl einzelner Dokumente atomar
SS14, © Prof. Dr. E. Rahm
8- 22
DBS 2
Beispiel: relational vs. dokumentenorientiert

Keine Beziehungen zwischen Dokumenten (-> keine Joins) sondern
geschachtelte Komponenten (ähnlich NF2, jedoch ohne Schemazwang)
– Redundanz bei n:m-Beziehungen
SS14, © Prof. Dr. E. Rahm
8- 23
DBS 2
MongoDB: Operationen

Beispiele:
SS14, © Prof. Dr. E. Rahm
8- 24
DBS 2
MongoDB: Operationen (2)
SS14, © Prof. Dr. E. Rahm
8- 25
DBS 2
Graph-Datenbanken

Bessere Unterstützung stark vernetzter Daten als mit Relationenmodell
– Soziale Netzwerke
– Protein-Netzwerke
– stark vernetzte Webdaten / Unternehmensdaten / …

Graph-Verwaltung im Relationenmodell oft nicht ausreichend schnell
– viele Tabellen, viele Joins
– langsame Traversierung von Kanten
– langsame Umsetzung von Graph-Algorithmen

Graph-Datenbanken
– Graph-Datenmodell mit Gleichbehandlung von Entities und Relationships
– Graph-Anfragesprachen
– Optimierte Graph-Operationen (z.B. finde „friends of friends“)
SS14, © Prof. Dr. E. Rahm
8- 26
DBS 2
Neo4J

Native Graph-Datenbank von Neo Technology
–
–
–
–

Community Edition (open-source) + kommerzielle Varianten
in Java realisiert , Unterstützung weiterer Sprachen (Ruby, Python)
ACID-Unterstützung
Skalierbarkeit durch Datenreplikation
Zentrale Datenstruktur: Property-Graphen
– Knoten/Kanten haben einen Typ (Label)
– Knoten und Kanten können Properties (Attribute)
haben
– Property: Key-Value-Paar (Attributname + Wert)
– gerichtete Kanten
SS14, © Prof. Dr. E. Rahm
8- 27
DBS 2
Property-Graphen

Mehrere, gerichtete Kanten
zwischen zwei Knoten möglich
(gerichteter „Multigraph“)
– Labels für Knoten/Kanten
– Properties für Knoten/Kanten

Konstanter Aufwand zur Traversierung zu
Nachbarknoten (statt Join im RM)
SS14, © Prof. Dr. E. Rahm
8- 28
DBS 2
Query-Sprache Cypher

Merkmale
–
–
–
–

Pattern Matching
OLTP-artige Lese/Änderungsoperationen
schnelle Traversierungen
ACID-basierte Updates
Klauseln:
SS14, © Prof. Dr. E. Rahm
DBS 2
8- 29
Beispiel 1
Beispiel-Graph
Beispielanfrage (Friend Of Friend)
Ergebnis:
Quelle: Neo4J Tutorial, http://docs.neo4j.org
SS14, © Prof. Dr. E. Rahm
8- 30
DBS 2
Beispiel 2

Finde Personen mit ähnlichen Interessen (Recommendations)
SS14, © Prof. Dr. E. Rahm
8- 31
DBS 2
Big Data Kompetenzzentrum

BMBF-Ausschreibung 2013 zur Einrichtung von 2 Kompetenzzentren in
Deutschland für Big Data
– mehrstufiges Auswahlverfahren

Ankündigung der Gewinner auf der CeBIT 2014
– ScaDS Dresden/Leipzig
– Berlin Big Data Center (BBDC)

ScaDS Dresden/Leipzig (Competence Center for Scalable Data Services and
Solutions Dresden/Leipzig)
– wissenschaftliche Koordinatoren: Nagel (TUD), Rahm (UL)
– offizieller Start: Okt. 2014
– Förderumfang: ca. 5 Mill. Euro

UL: Masterstudium Informatik mit Schwerpunkt Big Data Analytics
SS14, © Prof. Dr. E. Rahm
8- 32
DBS 2
ScaDS Dresden/Leipzig: Struktur
Lebenswissenschaften
Materialwissenschaft
Servicezentrum
Umwelt- /Verkehrswissenschaften
Digital Humanities
Business Data
Big Data Life Cycle Management und Workflows
Datenqualität /
Datenintegration
Wissensextraktion
Visuelle Analyse
Effiziente Big Data Architekturen
SS14, © Prof. Dr. E. Rahm
8- 33
DBS 2
Zusammenfassung

Big Data Herausforderungen
– Volume, Variety, Velocity, Veracity, …
– Skalierbare Analysen / Machine Learning

Unterschiedliche Architekturen: Cloud/Hadoop-Cluster,
In-Memory Warehouses, Kombinationen
 NoSQL
– Auslöser: webskalierbares Data Management
– semistrukturierte schemafreie Daten
– meist Verzicht auf SQL/ACID

Unterschiedliche Systemarten
– Key/Value-Stores, erweiterte Record-Stores (Spaltenfamilien)
– Dokumenten Stores
– Graph-Datenbanken

Hauptproblem: fehlende Standards
SS14, © Prof. Dr. E. Rahm
8- 34
DBS 2