Realtime BigData Step by Step mit Lambda, Kafka, Storm und Hadoop
•
9 gefällt mir•4,673 views
Vorstellung der Lambda Architektur, ihrer Motivation und einer konkreten technischen Umsetzung mit den Open Source Technologien Hadoop 2, Kafka und Storm.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (15)
Ähnlich wie Realtime BigData Step by Step mit Lambda, Kafka, Storm und Hadoop
Ähnlich wie Realtime BigData Step by Step mit Lambda, Kafka, Storm und Hadoop (20)
Realtime BigData Step by Step mit Lambda, Kafka, Storm und Hadoop
- 1. 25/3/14 1 Realtime Big Data - Step by Step mit Lambda, Kafka, Storm & Hadoop
- 2. codecentric AG • Lambda Architektur • ist eine neue abstrakte Architektur für ‘Realtime Big Data’ ! • Ziel dieser Präsentation: • Vorstellung dieser Architektur, ihrer Motivation und einer konkreten technischen Umsetzung mit Open Source Technologien ÜBERSICHT - DIESE PRÄSENTATION 2
- 3. codecentric AG • Motivation & Enterprise Data Hub • Beispiel • Lambda Architektur • Lambda Architektur mit Kafka, Storm & Hadoop • Kafka • Storm • Zusammenfassung AGENDA 3 Hartwig HKD @ Flickr
- 4. codecentric AG POINT-TO-POINT INTEGRATION 4 og earch Monitoring DWH DWH n Rec. Engine … CRM Sales User Tracking LogsERP • Daten werden zu vielfältigen DWH- Systemen gebracht • Vorwiegend strukturierten Daten • Üblicherweise nur ‘wichtige’ (und interne) Daten
- 5. codecentric AG HERAUSFORDERUNGEN 5 • Rigidität • Neue Auswertungen sind oft nur teuer und langwierig zu realisieren, da die Gesamtheit der notwendiger Daten oft in keinen System vorhanden ist; neue Systeme und ETL Strecken geschaffen werden müssen • Langsam • Integrationen basierend auf täglichen / wöchentlichen ETL Prozessen kann zunehmende Anforderungen an Echtzeitnähe nicht erfüllen
- 6. codecentric AG • Fragil • Netzwerk vielfältiger Dienste oft ohne eingebaute Unterstützung für Parallelisierung und Ausfallsicherheit machen Betrieb, Wartung und Weiterentwicklung kompliziert • Teuer • Hohe Kosten für kommerzielle Lösungen zum Umgang mit den anfallenden großen Datenmengen HERAUSFORDERUNGEN II 6
- 7. codecentric AG ENTERPRISE DATA HUB 7 Log Search Monitoring DWH DWH n Rec. Engine … CRM Sales User Tracking LogsERP • Ablegen aller Daten in ‘ursprünglicher’ Form • Unterstützen von ad-hoc queries über allen Daten • Robuste und parallelisierte (Voraus-) Berechnung von Sichten für andere Systeme
- 8. codecentric AG ENTERPRISE DATA HUB - ANFORDERUNGEN 8 Log Search Monitoring DWH DWH n Rec. Engine … CRM Sales User Tracking LogsERP 1 2 3 1. System zur skalierbaren kostengünstigen Speicherung 2. System zur skalierbaren Berechnung bel. Sichten (auch mit geringer Latenz) 3. System zur Beantwortung von Ad-hoc Queries auf diesen Daten
- 9. codecentric AG • Motivation & Enterprise Data Hub • Beispiel • Lambda Architektur • Lambda Architektur mit Kafka, Storm & Hadoop • Kafka • Storm • Zusammenfassung AGENDA 9 Was ist eine Beispiel für eine Anwendung / eine Firma wo man sowas braucht?
- 10. codecentric AG Verarbeitung aller Daten zu einem überwachten Maschinenpark (z.B. Windkraft) ! Integration von Zustandsdaten, Wetterprognosen, Daten zu Wartungsarbeiten, Manuelle Diagnosen … ! Beispielhafte Realtime Views: • Agregierte Leistungs- und Zustandsdaten • Aktuelle Verschleißprognose • Abweichung vom Normalverhalten, Anomalien PREVENTIVE MAINTENANCE 10 Andreas Klinke Johannsen @ Flickr
- 11. codecentric AG PREVENTIVE MAINTENANCE II 11 Realtime Power Generation Learned Prediction Model Realtime Maintenance Necessity Dashboard… EAM External Weather Data Telemetry Maintenance Reports SCADA System(s) Explorative Analytics of Factors that influence and predict machine deterioration …
- 12. codecentric AG • Motivation & Enterprise Data Hub • Beispiel • Lambda Architektur • Lambda Architektur mit Kafka, Storm & Hadoop • Kafka • Storm • Zusammenfassung AGENDA 12 Wie kann eine Architektur aussehen, mit der ein solcher Enterprise Data Hub umgesetzt werden kann? Besonders unter Berücksichtigung der Latenz?
- 13. codecentric AG • Architektur und Design Prinzipien für den Bau von skalierbaren Echtzeitsystemen • Entwickelt von Nathan Marz (früher bei Twitter) • Beschrieben in “Big Data - Principles and best practices of scalable realtime data systems” LAMBDA ARCHITEKTUR 13
- 14. 14 Batch Layer Speed Layer Serving Layer All Data Precomputed Information Process Stream Incremented Information Batch View Realtime View Merge Incoming Data Query Result • Speicherung aller Daten als immutable (append- only) master dataset ! • Vorausberechnung von Sichten auf dem master dataset in Batch Prozessen ! • Separater “Speed Layer” zur Berechnung von Echtzeit Sichten (dort wo notwendig und nur auf den Daten seit dem letzten Batch Prozess) !
- 15. codecentric AG • “Alle Daten”, damit • … auch zukünftige Fragen beantwortet werden können • … Fehler in der Aggregation von Daten korrigiert werden können ! • “Immutable & Append Only”, damit • … Fehler mit geringerer Wahrscheinlichkeit Daten vernichten • … die gesamt Geschichte des Datensatzes abgefragt werden kann. SPEICHERUNG ALLER DATEN ALS IMMUTABLE APPEND ONLY DATASET 15
- 16. codecentric AG • auf Basis der Masterdaten und unter Verwendung des gesamten Datenbestandes • anstatt der Speicherung der Master Daten gleich in einer zur schnellen Abfrage geeigneten Form • anstatt der inkrementellen Berechnung der Sichten ! • … um zu sehr großen Datenmengen skalieren zu können • … damit die Daten gleichzeitig in möglichst normalisierter Form gespeichert werden können und skalierbar abgefragt werden können • …um die Komplexität möglichst gering zu halten VORAUSBERECHNUNG VON SICHTEN IN BATCH PROZESSEN … 16
- 17. codecentric AG • Berechnet Sichten inkrementell nur auf den Daten seit dem letzten Batch lauf • Berechnete Sichten werden verworfen, sobald der Batch Prozess die zugrundeliegenden Daten verarbeitet hat • Ziel ist die Konzentration der kompliziertesten Teile dort, wo • Es wirklich notwendig ist • Datenmengen kleiner sind • Nur temporäre Ergebnisse berechnet werden SEPARATER SPEED LAYER 17 Absorbed into batch view Not yet absorbed Batch View Realtime VIew
- 18. 18 Batch Layer Speed Layer Serving Layer All Data about monitored Machines Machine Learning Monitoring Data Aggregate Data over Sensors and Time Deterioration Model Most Recent Monitoring Data Realtime Need for Maintenance Incoming Data Query Result AMBEISPIEL
- 19. codecentric AG • Motivation & Enterprise Data Hub • Beispiel • Lambda Architektur • Lambda Architektur mit Kafka, Storm & Hadoop • Kafka • Storm • Zusammenfassung AGENDA 19 Wie kann man diese Architektur technisch umsetzen?
- 20. 20 Batch Layer Speed Layer Serving Layer All Data Precomputed Information Process Stream Incremented Information Batch View Realtime View Merge Incoming Data Query Result Messaging System Stream Processing System DB / DFS Master Data Batch Processing System DB Batch Views DB Realtime Application Server NOTWENDIGE K0MPONENTEN
- 21. 21 Hadoop 2 / YARN Apache Kafka Storm-‐YARN HDFS MapReduce HOYA (HBASE on YARN) Application Server TECHNISCHERE ARCHITEKTUR
- 22. 22 Hadoop 2 / YARN Apache Kafka Storm-‐YARN HDFS MapReduce HOYA (HBASE on YARN) Application Server TECHNISCHERE ARCHITEKTUR
- 23. codecentric AG APACHE KAFA • Kafka ist ein verteilter, partitionierter, replizierter Commit Log Dienst ! • Es erfüllt die Funktion einer nachrichtenorientierten Middleware ! • Entwickelt von LinkedIn 23
- 24. codecentric AG • Kafka verwaltet Nachrichtenströme in Topics (Kategorien) ! • Producer veröffentlichen Nachrichten in Topics ! • Consumer abonnieren Nachrichten von Topics ! • Kafka läuft als ein Cluster aus Brokern APACHE KAFKA - KERNKONZEPTE 24 Kafka Cluster producer producer producer consumer consumer consumer
- 25. codecentric AG • Topics bestehen aus Partitionen (für Skalierbarkeit und Paralellisierung) • Nachrichten einer Partition sind geordnet und durch Offset eindeutig identifiziert • Nachrichten werden für einen konfigurierten Zeitraum gehalten • Producer entscheiden über Partition (z.B. Round Robin, nach Schlüssel) APACHE KAFKA - KERNKONZEPTE II 25 1 2 3 4 5 76 8 9 1 2 3 4 1 2 3 4 5 76 Partition 0 Partition 1 Partition 2 Writes
- 26. codecentric AG • Partitionen sind über den Cluster verteilt • Für jede Partition gibt es einen Leader und 0..n Follower • Der Leader verarbeitet alle Anfragen für eine Partition • Der Follower replizieren den Leader und können dessen Funktion im Falle eines Ausfalls übernehmen APACHE KAFKA - KERNKONZEPTE IV 26 1 2 3 4 5 76 8 9 1 2 3 4 1 2 3 4 5 76 Partition 0 Partition 1 Partition 2 Writes
- 27. codecentric AG • Nachrichten sind Byte Arrays Variabler Länge (die durch Kafka nicht interpretiert werden) • End-To-End Kompression von Nachrichten (-Batches) wird unterstützt • Kafka erlaubt sowohl Publish-Subscribe als auch Queue Semantik (und Mischungen APACHE KAFKA - KERNKONZEPTE III 27
- 28. codecentric AG ! ! ! • Skalierbarkeit • Robustheit dank Replikation • Verwendbar als Datenquelle für Speed und Batch Layer • Gute Integration mit Storm und Hadoop WARUM APACHE KAFKA 28
- 29. codecentric AG • Open Source System für skalierbare, fehlertolerante Echtzeitberechnung* auf Datenströmen • (Auch) von Nathan Marz bei Backtype und dann Twitter entwickelt • 2011 als “Twitter Storm”, veröffentlicht, seit 2013 im Apache Incubator Program • Storm auf YARN von Yahoo verfügbar, auch Hortonworks arbeitet an integration APACHE STORM 29*: Business Realtime
- 30. codecentric AG • Schnell - bis zu einer Millionen kleiner Nachrichten pro Knoten • Skalierbar - durch Parallele, über den Cluster verteilte Berechnungen • Fehlertolerant - Ausfallende Worker und Knoten werden automatisch kompensiert • Verlässlich - Storm garantiert “at least once” oder “exactly once” für die Verarbeitung von Nachrichten • Einfach zu verwalten WARUM STORM? 30
- 31. codecentric AG • Storm verarbeitet Ströme von Tupeln (listen von beliebigen Werten • Tupel Strömen werden transformiert (und Datenbanken auf dieser Basis aktualisiert) ! • Am Beispiel: Ein Tupel ist z.B. ein Messwert eines Vibrationssensors oder die Änderung einer Einstellung (z.B. Anstellwinkel) APACHE STORM KERNKONZEPTE I 31 Tuple Tuple Tuple TupleTuple Tuple Tuple Stream
- 32. codecentric AG • Spout: Quelle von Eventströmen, bsp: • Kafka Spout sendet Nachrichten als Tuples • Timer Spout sendet regelmaßige Zeittuple • Im Beispiel: • Aktuelle gemessene Temperaturdaten einer Maschine wurden in einem Kafka Topic veröffentlich. Ein Kafka Spout emittiert diese dann für die Verarbeitung in Storm APACHE STORM KERNKONZEPTE II 32
- 33. codecentric AG • Bolt: Berechnet und generiert output Streams auf Basis beliebig vieler input Stream • Im Beispiel: Ein Bolt sammelt die Werte von drei Vibrationssensoren mit unterschiedlichen Abtastfrequenzen, prüft auf Konsistenz und emittiert (über Sensoren und kurze Zeiträume) gemittelte Werte APACHE STORM KERNKONZEPTE III 33
- 34. codecentric AG • Topologie: Netzwerk aus Spouts und Bolts APACHE STORM KERNKONZEPTE IV 34 Parse
- 35. Hadoop 2 / YARN Storm AM BEISPIEL Kafka SensorData Parameters Topic A Topic B Parse Parse Sliding Window Temp. Sliding Window Vibr. (Micro Batched) DB Update HOYA (HBASE on YARN)
- 36. codecentric AG • Jeder Spout oder Bolt wird von Tasks ausgeführt APACHE STORM KERNKONZEPTE V 36 Sensors Parse
- 37. codecentric AG Die Verteilung der Events an Tasks wird über Stream Groupings konfiguriert • shuffle: Zufall • field: auf basis eines Feldes im Tupel • all: an jeden Task eines Bolts • global: alles an einen Task • (none, local or shuffle, direct) APACHE STORM KERNKONZEPTE VII 37 Parse Sliding Window Temp Sensors
- 38. 38Storm AM BEISPIEL Parse (Micro Batched) DB Update Sliding Window Temp Sliding Window Vibr. ParseParam. Sensors Kafka Topic A Topic B HOYA (HBASE on YARN)
- 39. codecentric AG • Apache Storm wird in Worker Knoten ausgeführt • Auf Worker Knoten werden 1..n Worker Prozesse ausgeführt (einer pro Topologie) • Innerhalb eines Worker Prozesses gibt es 1..n Executors (einen pro Komponente, i.e. konkreten Bolt oder Spout) • Innerhalb eines Executors gibt es 1..n tasks (die die gleiche Komponente ausführen) • Ein Nimbus Knoten koordiniert das Gesamtsystem APACHE STORM KERNKONZEPTE VI 39 Worker Node Worker Process Worker Process ExecutorExecutor Task Task Executor Task Task
- 40. codecentric AG • Motivation & Enterprise Data Hub • Beispiel • Lambda Architektur • Lambda Architektur mit Kafka, Storm & Hadoop • Kafka • Storm • Zusammenfassung AGENDA 40 Erreicht man mit dieser Architektur die am Anfang genannten Ziele?
- 41. codecentric AG HERAUSFORDERUNGEN 41 • RigideAgile • Ad-hoc Abfragen über gesamten Datenbestand möglich • Sichten mit neuen Daten ohne größere Programmierarbeiten erweiterbar • LangsamSchnell • (Nah-) Echtzeitverarbeitung von Events möglich und ETL Frequenz einfach konfigurierbar • FragilRobust • Aufbau ausschließlich auf verteilte Systeme bei denen Ausfallsicherheit ein wichtiges Kriterium • Robustheit gegenüber menschlichen Fehlern durch Aufbewahren der Rohdaten • TeuerKostengünstig • Geringe Lizenzkosten und Verwendung von Commodity Hardware
- 42. codecentric AG QUESTIONS? Valentin Zacharias ! ! codecentric AG Zeppelinstrasse 2 76185 Karlsruhe ! valentin.zacharias@codecentric.de www.codecentric.de blog.codecentric.de 1/27/14 42
Hinweis der Redaktion
- http://www.flickr.com/photos/16230215@N08/7852444560/
- Motivation: Was ist das Problem mit aktueller DWH / Informationsintegrationsarchitektur im Unternehmen Beispiel: Einführung in ein Beispiel was wir dann durch die ganzen Folien verwenden werden. http://www.flickr.com/photos/16230215@N08/7852444560/
- Ergebnis ist eine Systemlandschaft dieser Form - vielfältige Verbindungen zwischen verschiedenen Systemen
- Risiko Datenverlust durch menschlichen Fehler.
- http://www.flickr.com/photos/30788482@N00/1022097482/
- SCADA - supervisory control and data acquisition EAM - Enterprise Asset Managing
- (Manning Early Access Programm)
- (A): All new data is sent to both the batch layer and the speed layer. In the batch layer, new data is appended to the master dataset. In the speed layer, the new data is consumed to do incremental updates of the realtime views. (B): The master dataset is an immutable, append-only set of data. The master dataset only contains the rawest information that is not derived from any other information you have. We will have a thorough discussion on the importance of immutability in the upcoming chapter. (C): The batch layer precomputes query functions from scratch. The results of the batch layer are called "batch views." The batch layer runs in a while(true) loop and continuously recomputes the batch views from scratch. The strength of the batch layer is its ability to compute arbitrary functions on arbitrary data. This gives it the power to support any application. (D): The serving layer indexes the batch views produced by the batch layer and makes it possible to get particular values out of a batch view very quickly. The serving layer is a scalable database that swaps in new batch views as they're made available. Because of the latency of the batch layer, the results available from the serving layer are always out of date by a few hours. (E): The speed layer compensates for the high latency of updates to the serving layer. It uses fast incremental algorithms and read/write databases to produce realtime views that are always up to date. The speed layer only deals with recent data, because any data older than that has been absorbed into the batch layer and accounted for in the serving layer. The speed layer is significantly more complex than the batch and serving layers, but that complexity is compensated by the fact that the realtime views can be continuously discarded as data makes its way through the batch and serving layers. So the potential negative impact of that complexity is greatly limited. (F): Queries are resolved by getting results from both the batch and realtime views and merging them together.
- Kafka maintains feeds of messages in categories called topics. We'll call processes that publish messages to a Kafka topic producers. We'll call processes that subscribe to topics and process the feed of published messages consumers.. Kafka is run as a cluster comprised of one or more servers each of which is called a broker. So, at a high level, producers send messages over the network to the Kafka cluster which in turn serves them up to consumers like this:
- Skalierbarkeit - topics die größer sind als eine Maschine Konfigurierbarer Zeitraum (Tage, Wochen) - unabhängig davon ob jemand die schon gelesen hat. Gespeichert wird nur der Offset und der durch den Consumenten kontrolliert - aufgrund der anderen Eigenschaften ist dadurch auch ein Zurückspulen möglich.
- In comparison to most messaging systems Kafka has better throughput, built-in partitioning, replication, and fault-tolerance which makes it a good solution for large scale message processing applications. Schnell - Ein einzelner Kafka Broker kann hunderte MBs Lese- und Schreibvorgänge für tausende Clients verarbeiten Skalierbar - Ein einzelner Kafka Cluster kann als zentrales System die Events für eine große Organisation verwalten Dauerhaft - Alle Nachrichten werden auf der Festplatte gehalten und im Cluster repliziert. Ein einzelner Broker kann Terabytes an Nachrichten halten Verteilt - Kafka ist von Grund auf als verteiltes System mit starken Garantien für Verlässlichkeit aufgebaut
- werden andere Ströme und teilweise Datenbank updates Streams, Spouts Bolts Topologies Storm Resources (Nimbus, Supervisor)
- werden andere Ströme und teilweise Datenbank updates Streams, Spouts Bolts Topologies Storm Resources (Nimbus, Supervisor)
- werden andere Ströme und teilweise Datenbank updates Streams, Spouts Bolts Topologies Storm Resources (Nimbus, Supervisor)