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 Big Data SS14, Prof. Dr. E. Rahm 8-2
Big wandelt sich schnell Gigabytes, Terabytes (10 12 ) Wie groß ist Big Data? Petabytes (10 15 ), Exabytes (10 18 ), Zettabytes (10 21 ), ca 1.8 ZB wurden in 2011 erzeugt; ~8 ZB in 2015 D a t a s i z e E x a b y t e s Source: IDC s Digital Universe study, sponsored by EMC, June 2011 SS14, Prof. Dr. E. Rahm 8-3 Datenproduzenten: Web, Soziale Netze, Smartphones, Sensoren 12+ TBs of tweet data every day 30 billion RFID tags today (1.3B in 2005) 4.6 billion camera phones world wide? TBs of data every day 100s of millions of GPS enabled devices sold annually 25+ TBs of log data every day 76 million smart meters in 2009 200M by 2014 2+ billion people on the Web by end 2011 SS14, Prof. Dr. E. Rahm 8-4
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 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
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 8-7 Anwendungsdomänen für Big Data Analytics Smarter Healthcare Multi-channel sales Finance Log Analysis Homeland Security Traffic Control Telecom Search Quality Manufacturing Trading Analytics Fraud and Risk Retail: Churn, NBO SS14, Prof. Dr. E. Rahm 8-8
Big Data Analyse-Pipeline Quelle: Agrawal et al: Big Data: Challenges and Opportunities, 2011 SS14, Prof. Dr. E. Rahm 8-9 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
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 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 Map Phase Reduce Phase Partitioning Grouping Grouping Grouping SS14, Prof. Dr. E. Rahm 8-12
MR-Beispiel: Generierung Text-Index hamlet.txt to be or not to be 12th.txt be not afraid of greatness to, hamlet.txt be, hamlet.txt or, hamlet.txt not, hamlet.txt be, 12th.txt not, 12th.txt afraid, 12th.txt of, 12th.txt greatness, 12th.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) SS14, Prof. Dr. E. Rahm 8-13 NoSQL-Datenbanken SS14, Prof. Dr. E. Rahm 8-14
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 Relationale Datenbanken SS14, Prof. Dr. E. Rahm 8-15 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
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 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
Grobeinordnung NoSQL-Systeme SS14, Prof. Dr. E. Rahm 8-19 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. Twitter- Nachrichten, 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
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 } } <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> SS14, Prof. Dr. E. Rahm 8-21 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
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 MongoDB: Operationen Beispiele: SS14, Prof. Dr. E. Rahm 8-24
MongoDB: Operationen (2) SS14, Prof. Dr. E. Rahm 8-25 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
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 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
Merkmale Query-Sprache Cypher Pattern Matching OLTP-artige Lese/Änderungsoperationen schnelle Traversierungen ACID-basierte Updates Klauseln: SS14, Prof. Dr. E. Rahm 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
Beispiel 2 Finde Personen mit ähnlichen Interessen (Recommendations) SS14, Prof. Dr. E. Rahm 8-31 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
ScaDS Dresden/Leipzig: Struktur Lebenswissenschaften Materialwissenschaft Umwelt- /Verkehrswissenschaften Servicezentrum 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 Big Data Herausforderungen Zusammenfassung 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