Vorstellung der Lambda Architektur, ihrer Motivation und einer konkreten technischen Umsetzung mit den Open Source Technologien Hadoop 2, Kafka und Storm.
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
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
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
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
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)