25/3/14 1
Realtime Big Data - 

Step by Step mit Lambda, Kafka, Storm & Hadoop
codecentric	
  AG
• Lambda Architektur
• ist eine neue abstrakte Architektur für ‘Realtime Big
Data’
!
• Ziel dieser Präse...
codecentric	
  AG
• Motivation & Enterprise
Data Hub
• Beispiel
• Lambda Architektur
• Lambda Architektur mit
Kafka, Storm...
codecentric	
  AG
POINT-TO-POINT INTEGRATION
4
og	
  
earch
Monitoring DWH DWH	
  n
Rec.	
  Engine	
  
…
CRM Sales
User	
 ...
codecentric	
  AG
HERAUSFORDERUNGEN
5
• Rigidität
• Neue Auswertungen sind oft nur teuer und langwierig
zu realisieren, da...
codecentric	
  AG
• Fragil
• Netzwerk vielfältiger Dienste oft ohne eingebaute
Unterstützung für Parallelisierung und Ausf...
codecentric	
  AG
ENTERPRISE DATA HUB
7
Log	
  
Search
Monitoring DWH DWH	
  n
Rec.	
  Engine	
  
…
CRM Sales
User	
  
Tra...
codecentric	
  AG
ENTERPRISE DATA HUB -
ANFORDERUNGEN
8
Log	
  
Search
Monitoring DWH DWH	
  n
Rec.	
  Engine	
  
…
CRM Sa...
codecentric	
  AG
• Motivation & Enterprise
Data Hub
• Beispiel
• Lambda Architektur
• Lambda Architektur mit
Kafka, Storm...
codecentric	
  AG
Verarbeitung aller Daten zu einem
überwachten Maschinenpark (z.B.
Windkraft)
!
Integration von Zustandsd...
codecentric	
  AG
PREVENTIVE MAINTENANCE II
11
Realtime	
  
Power	
  
Generation
Learned	
  
Prediction	
  
Model
Realtime...
codecentric	
  AG
• Motivation & Enterprise
Data Hub
• Beispiel
• Lambda Architektur
• Lambda Architektur mit
Kafka, Storm...
codecentric	
  AG
• Architektur und Design
Prinzipien für den Bau von
skalierbaren
Echtzeitsystemen
• Entwickelt von Natha...
14
Batch Layer Speed Layer
Serving Layer
All Data
Precomputed
Information
Process Stream
Incremented
Information
Batch Vie...
codecentric	
  AG
• “Alle Daten”, damit
• … auch zukünftige Fragen beantwortet werden
können
• … Fehler in der Aggregation...
codecentric	
  AG
• auf Basis der Masterdaten und unter Verwendung des
gesamten Datenbestandes
• anstatt der Speicherung d...
codecentric	
  AG
• Berechnet Sichten inkrementell
nur auf den Daten seit dem
letzten Batch lauf
• Berechnete Sichten werd...
18
Batch Layer Speed Layer
Serving Layer
All Data about
monitored Machines
Machine Learning
Monitoring Data
Aggregate Data...
codecentric	
  AG
• Motivation & Enterprise
Data Hub
• Beispiel
• Lambda Architektur
• Lambda Architektur mit
Kafka, Storm...
20
Batch Layer Speed Layer
Serving Layer
All Data
Precomputed
Information
Process Stream
Incremented
Information
Batch Vie...
21
Hadoop	
  2	
  /	
  YARN
Apache	
  Kafka
Storm-­‐YARN
HDFS
MapReduce
HOYA	
  (HBASE	
  on	
  YARN)
Application	
  Serve...
22
Hadoop	
  2	
  /	
  YARN
Apache	
  Kafka
Storm-­‐YARN
HDFS
MapReduce
HOYA	
  (HBASE	
  on	
  YARN)
Application	
  Serve...
codecentric	
  AG
APACHE KAFA
• Kafka ist ein verteilter,
partitionierter, replizierter
Commit Log Dienst
!
• Es erfüllt d...
codecentric	
  AG
• Kafka verwaltet
Nachrichtenströme in
Topics (Kategorien)
!
• Producer veröffentlichen
Nachrichten in T...
codecentric	
  AG
• Topics bestehen aus
Partitionen (für
Skalierbarkeit und
Paralellisierung)
• Nachrichten einer Partitio...
codecentric	
  AG
• Partitionen sind über den
Cluster verteilt
• Für jede Partition gibt es
einen Leader und 0..n
Follower...
codecentric	
  AG
• Nachrichten sind Byte
Arrays Variabler Länge (die
durch Kafka nicht
interpretiert werden)
• End-To-End...
codecentric	
  AG
!
!
!
• Skalierbarkeit
• Robustheit dank Replikation
• Verwendbar als Datenquelle
für Speed und Batch La...
codecentric	
  AG
• Open Source System für
skalierbare, fehlertolerante
Echtzeitberechnung* auf
Datenströmen
• (Auch) von ...
codecentric	
  AG
• Schnell - bis zu einer Millionen
kleiner Nachrichten pro Knoten
• Skalierbar - durch Parallele, über
d...
codecentric	
  AG
• Storm verarbeitet Ströme von Tupeln (listen von
beliebigen Werten
• Tupel Strömen werden transformiert...
codecentric	
  AG
• Spout: Quelle von Eventströmen, bsp:
• Kafka Spout sendet Nachrichten als
Tuples
• Timer Spout sendet ...
codecentric	
  AG
• Bolt: Berechnet und generiert output Streams auf
Basis beliebig vieler input Stream
• Im Beispiel: Ein...
codecentric	
  AG
• Topologie: Netzwerk
aus Spouts und
Bolts
APACHE STORM KERNKONZEPTE IV
34
Parse
Hadoop 2 / YARN
Storm
AM BEISPIEL
Kafka
SensorData
Parameters
Topic A
Topic B
Parse
Parse
Sliding 

Window Temp.
Sliding 
...
codecentric	
  AG
• Jeder Spout oder Bolt
wird von Tasks
ausgeführt
APACHE STORM KERNKONZEPTE V
36
Sensors
Parse
codecentric	
  AG
Die Verteilung der Events
an Tasks wird über Stream
Groupings konfiguriert
• shuffle: Zufall
• field: au...
38Storm
AM BEISPIEL
Parse
(Micro Batched)

DB Update
Sliding 

Window Temp
Sliding 

Window Vibr.
ParseParam.
Sensors
Kafk...
codecentric	
  AG
• Apache Storm wird in Worker Knoten
ausgeführt
• Auf Worker Knoten werden 1..n Worker
Prozesse ausgefüh...
codecentric	
  AG
• Motivation & Enterprise
Data Hub
• Beispiel
• Lambda Architektur
• Lambda Architektur mit
Kafka, Storm...
codecentric	
  AG
HERAUSFORDERUNGEN
41
• RigideAgile
• Ad-hoc Abfragen über gesamten Datenbestand möglich
• Sichten mit ne...
codecentric	
  AG
QUESTIONS?
Valentin Zacharias
!
!
codecentric AG
Zeppelinstrasse 2
76185 Karlsruhe
!
valentin.zacharias@...
Nächste SlideShare
Wird geladen in …5
×

Realtime BigData Step by Step mit Lambda, Kafka, Storm und Hadoop

2.786 Aufrufe

Veröffentlicht am

Vorstellung der Lambda Architektur, ihrer Motivation und einer konkreten technischen Umsetzung mit den Open Source Technologien Hadoop 2, Kafka und Storm.

Veröffentlicht in: Technologie
0 Kommentare
6 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

Keine Downloads
Aufrufe
Aufrufe insgesamt
2.786
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
44
Aktionen
Geteilt
0
Downloads
48
Kommentare
0
Gefällt mir
6
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie
  • 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)
  • Realtime BigData Step by Step mit Lambda, Kafka, Storm und Hadoop

    1. 1. 25/3/14 1 Realtime Big Data - 
 Step by Step mit Lambda, Kafka, Storm & Hadoop
    2. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 21 Hadoop  2  /  YARN Apache  Kafka Storm-­‐YARN HDFS MapReduce HOYA  (HBASE  on  YARN) Application  Server TECHNISCHERE ARCHITEKTUR
    22. 22. 22 Hadoop  2  /  YARN Apache  Kafka Storm-­‐YARN HDFS MapReduce HOYA  (HBASE  on  YARN) Application  Server TECHNISCHERE ARCHITEKTUR
    23. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 34. codecentric  AG • Topologie: Netzwerk aus Spouts und Bolts APACHE STORM KERNKONZEPTE IV 34 Parse
    35. 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. 36. codecentric  AG • Jeder Spout oder Bolt wird von Tasks ausgeführt APACHE STORM KERNKONZEPTE V 36 Sensors Parse
    37. 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. 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. 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. 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. 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. 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

    ×