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

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äsentation: • Vorstellung dieser Architektur, ihrer Motivation und

einer konkreten technischen Umsetzung mit Open Source Technologien

ÜBERSICHT - DIESE PRÄSENTATION

2

codecentric AG

• Motivation & Enterprise Data Hub

• Beispiel • Lambda Architektur • Lambda Architektur mit

Kafka, Storm & Hadoop • Kafka • Storm

• Zusammenfassung

AGENDA

3Hartwig HKD @ Flickr

codecentric AG

POINT-TO-POINT INTEGRATION

4

Log Search 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

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

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

codecentric AG

ENTERPRISE DATA HUB

7



• 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

codecentric AG

ENTERPRISE DATA HUB - ANFORDERUNGEN

8



1

2

31. 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

codecentric AG




• Zusammenfassung

AGENDA

9

Was ist eine Beispiel für eine Anwendung / eine Firma wo man sowas braucht?

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

10Andreas Klinke Johannsen @ Flickr

codecentric AG

PREVENTIVE MAINTENANCE II

11

Realtime Power Generation

Learned Prediction Model

Realtime Maintenance Necessity Dashboard…

EAMExternal Weather Data

Telemetry Maintenance Reports

SCADA System(s)

Explorative Analytics of Factors that influence and predict machine deterioration

…

codecentric AG




• Zusammenfassung

AGENDA

12

Wie kann eineArchitektur aussehen, mit der ein solcher Enterprise Data Hub umgesetzt werden kann? Besonders unter

Berücksichtigung der Latenz?

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

Batch Layer Speed Layer

Serving Layer

All Data

Precomputed Information

Process Stream

Incremented Information

Batch View Realtime View

Merge

Inco

ming

Da

taQu

ery

Resu

lt

• 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)

!

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

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

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


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

Inco

ming

Da

taQu

ery

Resu

lt

AM

BE

ISP

IEL

codecentric AG




• Zusammenfassung

AGENDA

19

Wie kann man diese Architektur technisch umsetzen?

20


Serving Layer

All Data

Precomputed Information

Process Stream

Incremented Information

Batch View Realtime View

Merge

Inco

ming

Da

taQu

ery

Resu

lt

Messaging System

Stream Processing System

DB / DFS Master Data

Batch Processing System

DB Batch Views DB Realtime

Application Server

NO

TWE

ND

IGE

K

0MP

ON

EN

TEN

21

Hado

op 2 / YAR

N

Apache Kafka

Storm-‐YARN

HDFS

MapReduce

HOYA (HBASE on YARN)

Application Server

TEC

HN

ISC

HE

RE

A

RC

HIT

EK

TUR

22

Hado

op 2 / YAR

N

Apache Kafka

Storm-‐YARN

HDFS

MapReduce

HOYA (HBASE on YARN)

Application Server

TEC

HN

ISC

HE

RE

A

RC

HIT

EK

TUR

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

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

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 2Writes

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 2Writes

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

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

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

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

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

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

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

codecentric AG

• Topologie: Netzwerk aus Spouts und Bolts

APACHE STORM KERNKONZEPTE IV

34

Parse

Hadoop 2 / YARNStorm

AM BEISPIELKa

fka

SensorData

Parameters

Topic A

Topic B

Parse

Parse

Sliding Window Temp.

Sliding Window Vibr.

(Micro Batched)DB Update

HOYA

(HBA

SE on YA

RN)

codecentric AG

• Jeder Spout oder Bolt wird von Tasks ausgeführt

APACHE STORM KERNKONZEPTE V

36

SensorsParse

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

38Storm

AM BEISPIEL

Parse

(Micro Batched)DB Update

Sliding Window Temp

Sliding Window Vibr.

ParseParam.

Sensors

Kafk

a

Topic A

Topic B

HOYA

(HBA

SE on YA

RN)

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

ExecutorExecutorTask Task

ExecutorTask Task

codecentric AG




• Zusammenfassung

AGENDA

40

Erreicht man mit dieser Architektur die am Anfang genannten Ziele?

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

codecentric AG

QUESTIONS?

Valentin Zacharias !!codecentric AG Zeppelinstrasse 2 76185 Karlsruhe [email protected]

www.codecentric.de blog.codecentric.de

1/27/14 42

http://blog.codecentric.de






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

Technology

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