BFFT Techbog November: Speed up your Lambda!
28.05.2017

BFFT Techblog: Speed up your Lambda!

Thema: Wie man seine Lambda Architektur unter Zuhilfenahme von Fast Data Ansätzen beschleunigt

Im Automotive Big Data Bereich haben wir es oftmals nur mit zweien der vier Vs zu tun – Velocity und Volume. Da aus dem Fahrzeug nach einer IDL spezifizierte wohlbekannte Datenströme an das Backend ausgeleitet werden, entfällt die Variety (Dokumentenvielfalt). Zudem müssen sich die Fahrzeuge über ein OAuth2-basierendes Authentifizierungsverfahren am Backend anmelden. Somit ist auch das Vertrauensniveau sichergestellt und ein weiteres V, die Veracity (Ungenauigkeit und das Vertrauensniveau der Daten), entfällt ebenso.

dv1Quelle: http://www.intergen.co.nz/blog/Tim-Mole/dates/2013/8/musings-from-a-big-data-conference/

Wird ein Big Data Kontext mit hoher Variabilität durch unstrukturierte Daten und einer Vielzahl von Dokumenten betrachtet, so ist neben der reinen Persistierung der Rohdaten in ein verteiltes Dateisystem, wie HDFS oder Amazon S3, eine umfangreiche Implementierung von Integrations- und Normalisierungsverfahren notwendig, da wir diese variablen Daten mit möglichst generischen Analysen auswerten möchten:

classic-bigdata-architekturQuelle: Bastian Kraus

Die Komplexität steigt analog dazu in jedem Batch-Processing-Job und in jeder Stream-Processing-Pipeline an, da jedes Rohdatum zuerst in das Ziel-Analyse-Format integriert werden muss. Dies lässt sich hier in einer stark vereinfachten Form aufzeigen:

raw-data-analysis-job-complexityQuelle: Quelle: Bastian Kraus

Im Automotive-Kontext steht hingegen die Struktur der zu integrierenden Daten fest. Diese Datenformate ändern sich ab dem SOP (Start of Production) nicht und bleiben über die gesamte Lebensdauer einer Fahrzeugbaureihe erhalten. Die Integrations- und Normalisierungsprozesse müssen somit nur einmal angelegt werden, und bleiben danach unverändert. Es liegt auf der Hand, dass man in diesem Kontext Datenanalysen oder weiterverarbeitende Prozesse möglichst generisch mit niedriger Komplexität implementieren möchte. Somit lässt sich deren Effizienz in der Ausführung steigern, deren Wartbarkeit verbessern und die Fehleranfälligkeit reduzieren. In der Regel werden in Kontexten mit hoher Variabilität der Daten Rohdaten zuerst integriert und normalisiert. Daher liegt es nahe, diese Normalisierung und Integration bereits bei der Ingestion der Daten in das System durchzuführen, um so die Komplexität in allen nachgelagerten Prozessen zu reduzieren. Für das von uns oftmals verwendete Lambda-Architektur-Pattern wollen wir die vormals skizzierte Vorgehensweise nun integrieren.

Die Lambda-Architektur wird in drei Schichten untergliedert: Speed-, Batch- und Serving-Layer. Die Batch-Schicht beinhaltet das Master-Dataset, auch bekannt unter dem Synonym “Die Wahrheit”, und wird über Batch-Prozessierung zu höherwertigen Sichten in die Serving-Layer verarbeitet. Der Speed-Layer beinhaltet Stream-Processing-Analysen, die ihre Daten aus dem Live-Datenstrom beziehen, und die Ergebnisse anschließend ebenfalls dem Serving-Layer bereitstellen. In den letzten Jahren gewinnt das Paradigma Fast Data zunehmend an Bedeutung und wird als nächste Evolutionsstufe von Big Data gesehen. Bei diesem Ansatz wird versucht, in Quasi-Real-Time aus dem Live-Datenstrom Erkenntnisse zu gewinnen und direkt Entscheidungen abzuleiten. Es lässt sich erkennen, dass wir hier beide Ansätze durch Vorverlagerung der Datenintegration bei der Ingestion von Daten in das System vereinen können:

fast-lambda-architekturQuelle: Bastian Kraus

Dieser Ansatz bringt einige zusätzliche funktionale Anforderungen, welche das Backend erfüllen muss, um mit großer Last umgehen zu können:

– Dynamische lastgetriebene Skalierbarkeit der Micro-Services von Ingestion und Integration (sowohl Up- und Down-Scale)
– Starke Robustheit der Integrationsalgorithmik, da ansonsten die Wahrheit verfälscht wird
– Der zentrale Pufferspeicher zwischen Ingestion, Integration und Weiterverteilung muss für große Datenmengen und Lastspitzen angemessen dimensioniert werden (Durchsatz und Puffergröße)
– Die Integrationsschnittstellen müssen Backpressure im Datenstrom implementieren, um die nachgelagerten Systeme nicht zu überlasten

Erfüllt das Backend diese Anforderungen können wir sowohl mit unserer Wahrheit als auch unseren Live-Datenstrom an allen Stellen mit einem wohldefinierten, polyglotten und effizienten Datenformat arbeiten. Beispiele hierfür sind Apache Thrift, Avro oder Googles Protocol-Buffers.

Neben der Reduzierung hinsichtlich der Komplexität von Laufzeit und Algorithmen des Analyse-Codes und -Prozesses müssen sich Data-Analysten und Entwickler nicht mehr um die Normalisierung und Integration kümmern. Zudem wird hierdurch ein wesentlicher Single-Point-of-Failure eliminiert, der zu falschen Analyse-Ergebnissen durch fehlerhaften Integrations-Code führen kann..


Autor: Bastian K. (ehemals Team Big Data, Entwicklung Konzepte & Tooling)
Kontakt: techblog@bfft.de 
Bildquellen: http://www.intergen.co.nz/blog/Tim-Mole/dates/2013/8/musings-from-a-big-data-conference/; Bastian K.

Themenvorschau Dezember 2016: „H2O, when should I go to work?“ – Wie man mit einfachen Mitteln einen Prototypen für eine Machine-Learning-Applikation mit H2O entwickeln kann.


Jobs bei BFFT: