Cloud Data Management

Transkript

1 Cloud Data Management Kapitel 6: Large-Scale Datenanalyse Lars Kolb Sommersemester 2014 Universität Leipzig Institut für Informatik 1

2 Einführung Hadoop (und darauf aufbauende Frameworks) Einfache Parallelisierung von Berechnungen in Cluster-Umgebungen Fehlertoleranz Frei verfügbar Große Community Viele Optimierungsansätze aus Forschung ( letztes Kapitel) Design-Schwächen SPOF, begrenzte horizontale Skalierbarkeit ( Hadoop 2.x.x) Nicht optimal für alle Anwendungsfälle Echtzeit-Anwendungen Ad-hoc Aggregation großer Datenmengen ( Dremel) Iterative Anwendungen Maschinelle Lernverfahren ( Spark) 2

3 Inhaltsverzeichnis Hadoop 2.x.x HDFS Federation HDFS High Availability YARN (= MRv2= MapReduce 2.0) Google Dremel Hierarchisches, spaltenorientiertes Echtzeit-Anfragsystem zur Aggregation verteilter, geschachtelter Datensätze Apache Spark Parallele In-memory Datenanalyse in Cloud-Umgebungen 3

4 Hadoop: Versionen und Features (02/2010-bis 05/2012) 0.23 Alpha - HDFS append/sync - HDFS Symlinks - Distributed RAID FS - Kerberos - YARN (MRv2) - HDFS Federation 0.21 Alpha - HDFS append/sync, - HDFS Symlinks - Distributed RAID FS - Kein Kerberos Stable 0.22 Beta - HDFS append/sync - HDFS Symlinks - Distributed RAID FS - Kerberos (nur für HDFS nicht für MapReduce) - Veröffentlicht nach Alpha HDFS HA Beta - HDFS append/sync - Kerberos - Keine Symlinks - kein Distr. RAID FS - Ohne Verbesserungen/ Bugfixes aus Umbenannt in Quelle:

5 Hadoop: Versionen und Features (aktuell) Hadoop 1.0 reicherte um HDFS append/sync und Kerberos an Aktuell stabile Apache Hadoop Version: Hadoop 0.23 führte Features verschiedener Zweige zusammen HDFS Federation, Kerberos, HDFS append/sync, HDFS Symlinks, RAID FS, YARN Fortgeführt in alpha (aktuell: beta) HDFS High Availability (HDFS HA) Cloudera s Distribution Including Apache Hadoop (CDH) Vorkonfigurierte stabile Open Source Distribution für Produktivbetrieb Cloudera Manager, Hadoop, HBase, Hive, Pig, Impala, Mahout, Flume, Oozie, Sqoop, Regelmäßige Update- und Releasezyklen Support, Lizensierung und Consulting, Paketierung für verschiedene Plattformen Aktuell (basiert auf Hadoop 2.0.0) YARN (MRv2) oder klassische Jobtracker/Tasktracker-Implementierung (MRv1) Jobtracker High Availability für MRv1 5

6 HDFS Federation: Motivation Speicherkapazität kann durch Hinzufügen von Datanodes erweitert werden Ein Namenode verwaltet Namespace des ganzen Clusters Dateibaum+Metadaten und Block Locations aus Performanzgründen komplett im RAM Yahoo! Blockgröße: 128MB Durchschnittliche Datei 600B Heap (1 File+2-3 Blockobjekte) 100Mio Dateien 60GB Heap 1PB Daten 1GB Heap HS des Namenodes begrenzt horizontale Skalierbarkeit des Clusters Vertikale Skalierung des Namenodes Durchsatz von Lese/Schreiboperationen durch 1 Knoten bestimmt Mehr Clusterknoten Mehr Block Reports Mehr Tasktracker (agieren selber als HDFS clients) 6 Quelle: [Federation]

7 HDFS Federation: Grundidee Mehrere unabhängige Namenodes Keine Kommunikation, jeder NN verwaltet einen eigenen Namespace 1 Block Pool pro Namespace Datanodes speichern Blöcke aller Namespaces Vorteile Echte Horizontale Skalierbarkeit Performanz Höherer Clusterdurchsatz ermöglicht höheren Parallelitätsgrad (MapReduce) Multi-tenancy & Isolation Verschiedene Mandanten können sich ein Cluster teilen Verschiedene Anwendungen (z.b. Produktivanwendungen wie HBase) haben verschiedene Anforderungen eigener Namenode Block Pool Abstraktion ermöglicht Realisierung anderer verteilter Dateisysteme 7

8 HDFS Federation: Mount Tables Aufteilung des globalen Namespaces auf mehrere NNs soll für Clients weitesgehend transparent sein Kein explizites Handling verschiedener FileSystem Objekte pro Namespace Abwärtskompatibilität ViewFs Bereitstellung einer globalen Sicht Verwenden Client-seitiger Mount Tables ähnlich /etc/fstab in unixartigen OS core-site.xml fs.default.name: viewfs://mymounttable fs.viewfs.mounttable.mymounttable.link./insights: hdfs://namenode2:port/insights Es können auch andere Dateisysteme (S3, Local) gemounted werden 8 Quelle: [Federation]

9 HDFS High Availability: Motivation Namenode ist Single Point of Failure (SPOF) Hält FS Tree, Metadaten und Block Locations im Hauptspeicher Zusätzlich 2 Dateien im lokalen FS fsimage: Schnappschuss des FS beim Start des NNs (ohne Block Locations) edits log: Protokolierung aller Änderungen gegenüber fsimage (WAL) Beim Neustart des NN wird fsimage mit edits log gemerged NN wird selten neugestartet großer edits log Merge dauert lange Vor HDFS HA: Secondary Namenode ( Checkpoint Node ) Secondary NN kopiert in regelmäßigen Abständen fsimage und edit log vom NN Mergen von fsimage und edits log Zurückkopieren der aktualisierten und Ersetzen der alten fsimage Datei Im Falle eines geplanten Neustarts muss NN trotzdem auf Block Reports der einzelnen Datanodes warten mehrere Stunden für große Cluster (2000 nodes) Defekt des NNs Änderungen seit letztem Checkpoint verloren Vor HDFS HA: redundante Speicherung von fsimage und edits log (versch. Platten/NFS) 9

10 HDFS HA: Grundidee Verwenden von 2 Namenodes pro Cluster (Namespace bei Federation) Active Namenode bearbeitet Client-Anfragen Standby Namenode für schnelles Failover ( Hot Standby ) Secondary Namenode ( Checkpoint Node ) nicht mehr benötigt Datenodes senden Block Reports periodisch an beide Knoten Synchronisation von fsimage und edits log Active NN schreibt/aktualisiert edits log synchron in gemeinsam zugänglichen, hochverfügbaren Speicher 2 Varianten NFS Quorum-based Standby NN überwacht diesen Speicher kontinuierlich und wendet Änderungen auf eigenem Filesystem-Abbild im HS an Failover Nur wenige Änderungen müssen nachgefahren werden, Block Locations aktuell Manuell (Wartung): <3s, automatisch: 30-40s 10

11 HDFS HA: Fencing und Client Failover Fencing Split Brain-Szenario Beide NNs nehmen an sie sind Active NN Widersprüchliche Änderungen am FS Tree Es darf zu einem Zeitpunkt nur einen NN geben Lösung Standby NN verhindert, dass anderer NN Änderungen am gemeinsamen Speicher macht Jeder Node kann anderem den Zugriff entziehen (aber sich nicht selber wieder erlauben) sshfence: Kill des Active NN durch SSH Befehl shell: Beliebiges Shell Script (STONITH: Shoot The Other Node In The Head) Client Failover Umrouten der HDFS Clients zum Active NN Konfiguration eines Paars von Namenode-Adressen bei Clients Verwenden der Adressen in konfigurierter Reihenfolge Timeout: Retry anderer NN (vormals Standby jetzt Active) Kontaktiert Client den Standby NN Antwort-Code Retry Active NN 11

12 HDFS HA: NFS Hochwertiges NAS Auf Rechnern beider NNs ist ein bestimmtes Verzeichnis auf einem Dateiserver gemounted (Lese- und Schreibzugriff für die NN-Prozesse) Hochverfügbarkeit Mehrere Netzwerkanbindungen Redundante Stromversorgung Mehrere Platten / RAID Automatisches Failover Verwendet Apache ZooKeeper-Quorum Hochverfügbarer Koordinationsservice Verteilte Synchronisation von Konfigurationen, Mitgliedschaft, Leader Election, Jeder NN hat dauerhafte Verbindung zu ZooKeeper-Cluster Active NN Crash ZooKeeper-Session Timeout ZooKeeper informiert Standby NN, dass Failover initiiert werden muss Dazu ZooKeeper Failover Controller-Prozess (ZKFC) auf jedem NN Active NN Election, ZooKeeper Session Management, Health Monitoring 12 Quelle: [HDFSHA]

13 HDFS HA: NFS Nachteile Nachteile NAS-Variante Teure Spezialhardware Komplexe Administration (Redundante Netzwerkverbindungen, Mount-Optionen, ) NAS ist noch immer SPOF Linux NAS clients buggy Design-Ziele Quorum-based Verteilter replizierter Speicher ( HDFS) für edits log Ausfall/Nichtverfügbarkeit mehrere Knoten tollerabel solange die Mehrheit der Knoten erreichbar ist Anzahl der tollerierbaren Fehler konfigurierbar Anzahl der Speicherknoten soll ohne Performanzeinbußen erhöht werden können Durchsatz nicht vom langsamsten Knoten bestimmt Verwenden der im Hadoop-Cluster verfügbaren Ressourcen 13

14 HDFS HA: Quorum-based Jeder NN kommuniziert mit einer Gruppe von JournalNodes (JNs) Ungerade Anzahl von n JNs auf n Cluster-Knoten Änderungen am edits log werden durch Active NN synchron zur Mehrheit der JNs geloggt Standby NN überwacht JNs kontinuierlich Im Falle eines Failovers liest Standby NN alle ausstehenden Änderungen von den Journal Nodes bevor er zum Active NN wird JNs erlauben zu einem Zeitpunkt nur einem NN Schreibzugriff Jeder Quorum JournalManager hat eine eindeutige epoch number tot. Ordnung Jede Schreiboperation an JN trägt epoch number Jeder JN speichert die größte zuletzt gesehene epoch number [Quelle: HDFSHA] Schreibanfordeurngen von NNs mit kleinerer epoch number werden ignoriert Wenn Namenode zum Active NN wird generiert er mit Zustimmung der Mehrheit der JNs eine neue epoch number implizites Fencing Explizites Fencing zur Vermeidung der Beantwortung von Leseanfragen durch vorherigen Active NN 14

15 YARN (=MRv2=MapReduce 2.0): Motivation Schlechte Auslastung der Cluster-Ressourcen Statische Konfiguration der Slots für Map-/Reduce-Tasks pro Tasktracker Map-Slots können nicht für Reduce-Tasks genutzt werden (und umgekehrt) Engpass Jobtracker - Skalierbarkeit nur bis zu paralleler Tasks Ressource Management Überwachung Trasktracker (Heartbeats, Blacklisting, Cluster Capacity) Zuteilung von Slots zu Tasks Job Scheduling und Monitoring Ausführen von MapReduce Jobs Quelle: [YARN] Überwachen laufender und ausstehender Tasks (Speculative Execution, Neustart fehlgeschlagener Tasks, Aggregieren der Counter) Kein Support für andere Programmiermodelle als MapReduce 15

16 YARN: Grundidee Dezentralisierung Quelle: 16

17 YARN: Dezentralisierung Globaler Ressource Manager (RM) Applications Manager (AsM) Submission von Anwendungen Start/Monitoring/Neustart von Application masters Überwachen des Fortschritt aller Anwendungen Scheduler: Zuteilung von Ressourcen zu Anwendungen Application Master (AM) Mini-Jobtracker für eine Anwendung (z.b. 1 MapReduce Job) Leichtgewichtiger Prozess auf Slave-Node Task Scheduling und Monitoring Anforderung der benötigten Ressourcen (RAM, CPU, Bandbreite, Disk) vom RM Allokation und Monitoring aller gewährten Container auf zugewiesenen NMs Fortschrittsbericht an AsM Node Manager (NM) Slave-Prozess, Ausführung und Überwachen von abstrakten Containern Fortschrittsbericht an AM Bericht über belegte Ressourcen an RM 17

18 YARN: Application Submission Priority,Hostname,Ressources,#Containers 1, host1, 1GB, 1 1, host2, 2GB, 1 host1 host2 Quelle:[YARN] RM kann neugestartet werden ohne dass laufende Anwendungen neugestartet werden müssen RM High Availability noch in Entwicklung Abstraktion (Ressourcen, Container) erlaubt Implementierung verschiedener verteilter Frameworks auf Basis von HDFS und YARN MapReduce, Apache HAMA, Apache Giraph, Open MPI, Apache Spark 18

19 Inhaltsverzeichnis Hadoop 2.x.x HDFS Federation HDFS High Availability YARN (= MRv2= MapReduce 2.0) Google Dremel Hierarchisches, spaltenorientiertes Echtzeit-Anfragsystem zur Aggregation verteilter, geschachtelter Datensätze Apache Spark Parallele In-memory Datenanalyse in Cloud-Umgebungen 19

20 Google Dremel Skalierbares System für verteilte Ausführung von Leseanfragen auf riesigen Mengen geschachtelter Daten Effizientere Bearbeitung im Vrgl. zur Ausführung einer Menge von MapReduce Jobs Building Blocks Spaltenbasierte Speicherung geschachtelter Datensätze SQL-ähnliche Anfragesprache Multi-level Execution trees Open Source-Implementierung: Apache Drill Quellen für die folgenden Folien: [Dremel1], [Dremel2] 20

21 Google Dremel : Datenmodell Attribute können Werte sein oder ein bis mehrere Unterattribute haben Pflichtattribute sein [1,1] optional sein [0,1] wiederholt Auftreten (Reihenfolge relevant) [0,*] vs. A.B.C=c 1 A.B.C=c 2 A.B.D=d 3 A.B.D=d 4 A.B.D=d 1 A.B.D=d 2 A.E=e 1 A.E=e 2 - Bei Projektion Lesen weniger Daten A.E=e 3 - Bessere (De)Kompressionseigenschaften 21

22 Google Dremel : Spaltenbasierte Zerlegung Sequentielle Speicherung aller Werte eines Attributes Zusätzliche Information (r,d) für jeden Wert um Datensätze rekonstruieren zu können r 2 r 1 Repetition level r: At what repeated field in the field's path the value has repeated #repeated Fields im Pfadpräfix der mit Vorgänger übereinstimmt (incl. Element, das Record identifiziert) r 1.Name 1.Language 1.Code: en-us (r=0) r 1.Name 1.Language 2.Code: en (r=2) r 1.Name 2 (r=1) r 1.Name 3.Language 1.Code: en-gb (r=1) r 2.Name 1 (r=0) 22 Defenition Level d: How many fields in paths that could be undefined are actually present #optionaler und repeated fields im Pfad (ohne Element das Record identifiziert): r 1.Links.Forward 2 : 40 (d=2) Wenn d kleiner als max. mögliche Anzahl optionaler und repeated fields NULL

23 Google Dremel : Rekonstruktion Notwendig für Interoperabilität mit satzorientierten Tools (z.b. MapReduce) Gegeben: Teilmenge der benötigten Attribute Gesucht: Ausgangsdatensätze mit originaler Schachtelung und Reihenfolge (nicht benötige Attribute fallen weg) Endlicher Automat Zustand entspricht einem Field Reader für entsprechendes Attribut Bei Übergang in einen Zustand liest der Field Reader den nächsten Wert und fügt diesen zum aktuellem Datensatz hinzu Anschließend wird r des darauffolgenden Wertes gelesen Entspricht Zustandsübergang 23

24 Google Dremel : Rekonstruktion (2) Wird nur eine Teilmenge der Attribute benötigt, kann ein einfacherer Automat konstruiert/verwendet werden 24

25 Google Dremel : SQL-ähnliche Anfragesprache Optimiert für select-project-aggregate auf einer Tabelle Single scan Intra-Record und Inter-Record Aggregation 25

26 Google Dremel: Anfrageausführung Serving Tree Hierarchische Anfrageausführung Jeder Knoten schreibt Anfrage in Menge von Teilanfragen um und aggregiert die resultierenden Teilergebnisse Blattknoten kommunizieren mit Storage Layer Fehlertolleranz durch Mehrfachvergabe einer Teilanfrage 26

27 Google Dremel: Evaluierung SELECT SUM(CountWords(field)) / COUNT(*) FROM T1 T1: 85 Mrd. Datensätze / 87 TB Zugriff nur auf ein Attribut MR Overhead Starten des/der Job/s Task Scheduling Lesen vollständiger Datensätze execution time (sec) on 3000 nodes (87 TB) (0.5 TB) Tiefe der Serving Tree-Topologie Q2: SELECT country, SUM(item.amount) FROM T2 GROUP BY country Q3: SELECT domain, SUM(item.amount) FROM T2 WHERE domain CONTAINS.net GROUP BY domain T2: 24 Mrd. Datensätze/ 13TB 27 (60GB. 100s of records) (180GB, 1.1 Mio records)

28 Inhaltsverzeichnis Hadoop 2.x.x HDFS Federation HDFS High Availability YARN (= MRv2= MapReduce 2.0) Google Dremel Hierarchisches, spaltenorientiertes Echtzeit-Anfragsystem zur Aggregation verteilter, geschachtelter Datensätze Apache Spark Parallele In-memory Datenanalyse in Cloud-Umgebungen 28

29 Apache Spark: Motivation MapReduce ist ungeignet für iterative und interaktive Anwendungen Materialisierung von Map-Ergebnissen im lokalen FS Materialisierung und Replikation von Reduce-Ergebnissen im HDFS Ansatz: Caching im Hauptspeicher Eine Größenordnung schneller als Externspeicherzugriff 95% aller Anfragen an Facebooks Hive Cluster könnten komplett aus HS beantwortet werden [Spark] Quelle: [Spark2] Bisherige Ansätze (z.b. RAMCloud) erfordern Replikation und verteilte Speicherung um Fehlertoleranz gewährleisten zu können 29 Quelle: [Spark2]

30 Apache Spark: Übersicht Ursprünglich Forschungsprojekt der UC Berkely zur parallelen Analyse großer Datenmengen in Cluster-Umgebungen [Spark] Apache Incubator-Projekt: Auf Datensätze eines Datasets können verschiedene Funktionen (höherer Ordnung) angewendet werden erzeugen neues Dataset map, flatmap, filter, groupbykey, reducebykey, join, cogroup, mapvalues, partition, In-memory Caching von Datasets für effiziente Multi-pass-Operationen Iterative Algorithmen (Machine Learning, PageRank, K-means, ) Interaktive Datenanalyse (z.b. SQL) Fehlertoleranz Keine Replikation gecachter Daten sondern Neuberechnung verlorener Partitionen 30

31 Apache Spark: Resilient Distributed Datasets Verteilte Kollektion von Datensätzen Read-only Generiert durch Anwendung bestimmter Transformationen auf Basisdatenquelle (HDFS) oder Existierendem RDD Nutzer kann RDDs im Hauptspeicher der Worker-Nodes cachen Erlaubt Wiederverwendung in späteren Operationen Ausschreiben auf Sekundärspeicher bei HS-Mangel Lineage-Information RDD kennt seine Vater-RDDs sowie die Berechnungsvorschrift mit welcher es aus diesen abgeleitet wurde Verlorene Partitionen können bei Bedarf neuberechnet werden 31

32 Apache Spark: Beispiel Zeitstempel (=vierte Spalte) der Log-Einträge die mit ERROR starten und HDFS enthalten 32

33 Apache Spark: Transformationen & Aktionen Beispiele: Quelle: [Spark] 33

34 Apache Spark: K-means Clustering Analog zu Beispiel aus Kapitel 3 S.25 Lokale Ausführung 34

35 Apache Spark: K-means Clustering (2) 35

36 Apache Spark: Architektur [Spark3] Quelle: [Spark3] BlockManager Write-once Key-Value Store pro Worker Caching von RDDs Bereitstellen eines Shuffle-Services Verwalten eines StorageLevels pro Block Externspeicher, RAM Auslagern gecachter Daten auf Externspeicher bei HS-Mangel 36

37 Apache Spark: Scheduling DAGScheduler: Kind-Partition hängt von einer konst. Anzahl von Partitionen der Vater-RDDs ab Pipelining mehrerer Transformationen in 1 Task Shuffle-Operationen markieren Stage-Grenzen Parallele Ausführung der Tasks eines Stages Keine Neuberechnung von Stages, deren Ergebnis bereits im Cache vorliegt (Stage 1) TaskScheduler Berücksichtigen Datenlokalität (Cache, HDFS Blöcke) Task-Failure Neuberechnung auf anderen Knoten solange abhängige Partitionen verfügbar sind sonst: parallele RDD-Recovery 37

38 Apache Spark: RDD Recovery Lineage-Information eines RDDs Menge von Partitionen (z.b. HDFS Blöcke, Reduce-Tasks, ) Menge von Abhängigkeiten zu Vater-RDDs Funktion um eine Partition ausgehend von Vater-RDD zu berechnen Bevorzugte Knoten zur Berechnung einer Partition (HDFS block location, Knoten welcher Partition eines RDDs cacht, shuffle on each parent, ) Information über Partitionierung Fehlertoleranz für Shuffle-Transformationen Join, GroupByKey, reducebykey, Pufferung der Zwischenergebnisse im Haupt- bzw. Externspeicher der Erzeuger 38 Quelle: [Spark2]

39 Apache Spark: Evaluation [Spark] Logistic Regression (1Mrd Punkte, 100GB) K-Means (1Mrd. Punkte, 100GB, 10 Cluster) Knoten

40 Zusammenfassung Hadoop 2.x.x HDFS Federation: Echte horizontale Skalierbarkeit des Clusters HDFS HA: Namenode SPOF YARN: Generisches Management von Cluster-Ressourcen Google Dremel Spaltenorientierte Speicherung geschachtelter Daten Interaktive Analyse von read-only Daten Scan & Aggregate (auf Teilmenge der Spalten) Hierarchische Anfragebearbeitung: Multi-level aggregation tree Apache Spark Parallele, fehlertollerante Datenanalyse mit In-memory Caching von Datensätzen Ausführungsumgebung für Erweiterungen SQL - Shark ( Graphanalyse - GraphX Machine Learning - MLbase ( Analyse auf kontinuierlicher Datenströme: Spark Streaming 40

41 Quellen & Literatur [Dremel1] Melnik et. al.: Dremel: Interactive Analysis of Web-Scale Datasets. Commun. ACM 2011 [Dremel2] [Spark] Zaharia et. al.: Resilient Distributed Datasets: A Fault-Tolerant Abstraction for In- Memory Cluster Computing. NSDI 2012 [Spark2]: [Spark3]: [HDFSHA]: [Federation]: [YARN]: [YARN2]: 41