Lambdaarchitektur für BigData

Abteilung / Bereich / Datum (Tag.Monat.Jahr)
Lambda Architektur für BigData-Projekte
Analytics
Andreas Buckenhofer, 19.11.2014

2 Daimler TSS/About me
Zur Person
Andreas Buckenhofer, Senior DB Professional
Seit 2009 bei Daimler TSS im Fachgebiet
Data Warehouse & Data Integration (Cognos/Informatica)
Schwerpunkt DWH/CRM seit 1998
• Entwickler
• Administrator
• Berater

TSS Unternehmenspräsentation / Mai 2013 / V8.0
Unternehmensüberblick
Unsere Geschäftsfelder
3
Kundenspezifische
Individual- und
Standardlösungen für
alle Konzernbereiche.
Leistungen auf Basis
von Konzern- und
Industriestandards:
schnell, flexibel und
kosteneffizient.
Know-how und
Kapazitäten in den
Disziplinen Technologie,
Strategie, Methodik,
Prozesssteuerung und
-qualität sowie
Sicherheit.
Softwarelösungen,
Infrastrukturen und
Dienstleistungen für
Händlerbetriebe
werden durch unsere
100% Tochtergesell-
schaft Daimler IT
Retail GmbH erbracht.
Solutions Consulting IT RetailServices

Daimler TSS / Lambda Architektur / 19.11.2014 4
1. Motivation Lambda Architektur
2. Batch-Layer
3. Speed-Layer
4. Serving-Layer
5. Zusammenfassung
Agenda

… ist eine neue abstrakte Architektur für ‘Realtime Big Data“
Ziel dieser Präsentation:
• Vorstellung dieser Architektur und einer möglichen Umsetzung mit Hadoop
Stack
• Konzept/Methode wichtiger als Tools
„Wer die Anforderungen versteht, weiß welches der vielen Tools geeignet ist“
• Datenmodellierung inkl. Serialisierung und Schema ist auch für BigData
relevant
Motivation Lambda Architektur
Ziel der Präsentation

• Entwickelt von Nathan Marz
(früher bei Twitter)
Quelle

• Robust und fehlertolerant (HW Fehler, SW Fehler, Operationale Fehler)
• Lese- und Schreibzugriffe mit niedriger Latenzzeit
• Skalierbar
• Allgemein verwendbar (unterstützt viele Anwendungen)
• Erweiterbar (flexibel bei Änderungen)
• Ermöglicht Ad-hoc Abfragen
• Minimale Wartung
• Debugging möglich
Eigenschaften eines Big Data Systems

“Raw data”: atomare Daten, z.B. Events.
• Alle Daten werden gespeichert
• Daten werden nicht geändert
• Daten sind zeitbasiert
• Daten sind eindeutig
“Derived data”: Daten bzw Informationen, die abgeleitet sind.
• Transformationen
• Aggregationen
Data as new oil

Query = function ( all data )
Überblick Lambda Architektur
Abfragen
All
Data
Query
Precomputed
Performance
View

Übersicht
Batch Layer
All Data
Speed Layer
RealTime Views
Serving Layer
Batch Views
Query
(merge)
Data Stream

Preventive Maintenance, z.B.: Leistungs- und Zustandsdaten überwachen,
Aktuelle Verschleißprognose, Abweichung vom Normalverhalten, Anomalien
• Produktionssteuerungen liefern Events (Meßdaten)
• Vorgabe: Zusammenführung/Speicherung in Hadoop (Hortonworks)
• Analyse, Monitoring und Reporting der Daten
• Viele Auswertungen sind nicht zeitkritisch (kein Bedarf für
Realtime/Rightime)
• Jedoch einige kritische Advanced Analytics Auswertungen (RightTime,
Streaming)
Use Case

Use Case - JSON

2. Batch-Layer
3. Speed-Layer
4. Serving-Layer
5. Zusammenfassung
Agenda

Übersicht
Batch Layer
All Data
Speed Layer
RealTime Views
Serving Layer
Batch Views
Query
(merge)
Data Stream

Speichert „Master Dataset“ (unveränderliche, ständig wachsende Daten)
• damit zukünftige Fragen beantwortet werden können, da die gesamte Historie
vorliegt
• bei neuen Algorithmen Neuberechnungen durchgeführt werden können
Berechnet beliebige Batch Views (ständige Neuberechnung)
Batch Layer
Eigenschaften

“My own personal opinion is that data analysis is much less important than
data re-analysis. It’s hard for a data team to get things right on the very first try,
and the team shouldn’t be faulted for their honest efforts. When everything is
available for review, and when more data is added over time, you’ll increase your
chances of converging to someplace near the truth.”–Jules J. Berman.
http://www.odbms.org/blog/2014/07/big-data-science-interview-jules-j-
berman/
Batch-Layer
Analytics vs Re-Analytics

Hadoop HDFS
Hadoop MapReduce
Hadoop Hive
Batch Layer
Tools

Batch Layer
Masterdatensatz
• Atomare, unveränderliche Daten: CR(D) statt CRUD
• Create: Einmalige Anlage eines Datensatzes inkl. Zeitstempel
• Read: Lesen des Datensatzes beliebig oft
• Delete: Löschen von Daten nur in bestimmten Situationen: Einhaltung
gesetzlicher Vorgaben oder Entfernung der Daten nach 8/10/? Jahren
(Löschen z.B. mit Hilfe geeigneter Partitionierung)
• “Normalisierte” Speicherung der Daten
• Keine Redundanz notwendig
• Möglich: Speicherung z.B. als SAT-Tabelle und “Kombination” mit RDBMS
(Data Vault 2.0)

Events liegen i.d.R. als textähnliche Strukturen vor (JSON, CSV, u.ä.)
• sehr flexibel, aber langsam und speicherintensiv
Batch Layer
Serialisierung und Schema 1(3)

JSON, CSV, etc sind fehleranfällig
keine Validierung während dem Schreiben
schema-on-write vs schema-on-read
Mehrwert von Schemata
• Strukturelle Integrität
• Verhindert Korruption
• Frühzeitige Erkennung von Fehlern
Batch Layer

Zur Abspeicherung des Masterdatensätzes ist ein Format mit Schema sinnvoll
Quelle: Holmes - Hadoop in Practice - Manning 2014
Batch Layer

2. Batch-Layer
3. Speed-Layer
4. Serving-Layer
5. Zusammenfassung
Agenda

Übersicht
Batch Layer
All Data
Speed Layer
RealTime Views
Serving Layer
Batch Views
Query
(merge)
Data Stream

Berechnet Realtime-Views inkrementell auf Daten, die noch nicht als Batch-Views
vorliegen.
Bereits berechnete Realtime-Views werden verworfen sobald die Daten auch
durch Batch-Views verfügbar sind.
Speed Layer ist komplexer, schneller und Daten in den Realtime-Views sind nur
temporär.
Speed Layer
Eigenschaften

Verarbeitung
• Kontinuierliche Verarbeitung von Datenströmen
Speicherung
• Speicherung der Ergebnisse in einem eingeschränkten Zeitraum (wahrlfreies
Schreiben und Lesen)
• Keine Speicherung der Rohdaten (raw data), da im Batch Layer vorhanden
Speed Layer
Komponenten

Verarbeitung
• Storm
• zukünftig ggf. Spark Streaming
Speicherung
• HBase, Cassandra
• ElasticSearch
• zukünftig ggf. Spark
Sowie zur Anlieferung der Daten: Kafka, MQ
Speed Layer
Tools

2. Batch-Layer
3. Speed-Layer
4. Serving-Layer
5. Zusammenfassung
Agenda

Übersicht
Batch Layer
All Data
Speed Layer
RealTime Views
Serving Layer
Batch Views
Query
(merge)
Data Stream

Vorausberechnung von Sichten durch Batch-Layer
• Schnelle Datenzugriffe: wahlfreier Zugriff (Random Reads) auf Batch Views
inkl. Indexierung
• Neuberechnung der Batch Views aus allen Daten und keine inkrementelle
Berechnung
Abweichungen möglich, z.B. durch geeignete Partitionierung
• Datenhaltung / Datenmodellierung optimiert für Analysetool
Serving Layer
Eigenschaften

Abfragen kombinieren Batch-Views und Realtime-Views
• Berechnung von Durchschnittswerten
• Identifikation von Anomalien
Serving Layer
Herausforderungen
?

Elephant-DB
Hbase, Cassandra
Serving Layer
Tools

2. Batch-Layer
3. Speed-Layer
4. Serving-Layer
5. Zusammenfassung
Agenda

• Systematischer, strukturierter Ansatz
• Fokus nicht nur auf Tools, sondern auf Methoden/Verfahren
• Herausstellung unveränderlicher Masterdatensatz
Zusammenfassung
Vorteile

• Lambda-Architektur erfordert mehrere/viele Technologien
• Hoher Aufwand zur Wartung des Codes (Batch und Streaming)
• Komplex, da viele Tools und Programmiersprachen
• Nathan Marz stellt viele Tools vor, die nicht Bestandteil eines verfügbaren
Tools-Stacks sind bzw entwickelt eigene Tools (Elephant-DB, Pail, u.a.)
Zusammenfassung
Nachteile

Use Case - Tools
Batch Layer
All Data
Speed Layer
RealTime Views
Serving Layer
Batch Views
Query
(merge)
Data Stream

• Hinterfragen der Anforderungen. Nicht immer Realtime nötig. Oft reicht Batch-
Layer aus.
• Keine BigData-Technologie löst alle Probleme gleich gut
• Lambda Architektur ist ein möglicher, komplexer Ansatz. Alternativen, z.B.
KAPPA (Jay Kreps)
• Beschränkung auf wenige Tools (z.B. eine DB für Speed und Serving Layer).
Verfügbarer Hadoop Stack von Hortonworks enthält alle nötigen
Komponenten (HDFS, Storm, HBASE). Andere Stacks, z.B. Cloudera auch
nahezu komplett.
• Sensoren werden immer leistungsfähiger und übernehmen zunehmend
Aufgaben eines Speed Layers
Zusammenfassung
Use Case - KISS

Vielen Dank!
Daimler TSS GmbH
Wilhelm-Runge-Straße 11
89081 Ulm
Telefon +49 731 505-06
Fax +49 731 505-65 99
tss@daimler.com
Internet: www.daimler-tss.com
Intranet: intra.corpintra.net/intra-itc/tss
Intranet-Portal-Code: @TSS
Daimler TSS GmbH
Sitz und Registergericht: Ulm, HRB-Nr.: 3844
Geschäftsführung: Dr. Stefan Eberhardt (Vorsitzender), Steffen Bäuerle

JSON&Co sehr flexibel, aber langsame Verarbeitung und schlechte Komprimierung.
Batch-Layer
Speicherung der Daten in „normalisierter“ Form unter Verwendung von
z.B. Avro, ORCfile, Parquet
Speed-Layer
Verarbeitung der Rohdaten
Speicherung der Ergebnisse optimiert für Abfragen
Serving Layer
Speicherung der Ergebnisse optimiert für Abfragen
Zusammenfassung
Datenmodellierung auch für BigData 1(2)

Datenmodellierung auch im Hadoop bzw NoSQL-Umfeld wichtig
• Performanz zu garantieren
• Entwicklung beschleunigen
• Qualität des Produkt verbessern
• Wartungskosten reduzieren
• gemeinsames Verständnis fördern
“Data modeling is the process of learning about the data, and regardless of
technology, this process must be performed for a successful application.”
Steve Hoberman: Data Modeling for Mongo DB, Technics Publications 2014
Zusammenfassung
Datenmodellierung auch für BigData 2(2)

Lambda-Architektur
Literaturhinweise
http://radar.oreilly.com/2014/07/questioning-the-lambda-architecture.html
http://lambda-architecture.net/
http://techblog.netflix.com/2013/12/announcing-suro-backbone-of-netflixs.html

Lambdaarchitektur für BigData

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (19)

Ähnlich wie Lambdaarchitektur für BigData

Ähnlich wie Lambdaarchitektur für BigData (20)

Lambdaarchitektur für BigData