Aufbau einer Fast Data Plattform

Ausschnitt aus dem Buch Fast Data in der Praxis

Motivation

Der folgende Post ist ein Ausschnitt des Kapitels Aufbau einer Fast Data Plattform aus dem E-Book Fast Data in der Praxis, das ich gerade schreibe. Wenn Sie über eine erste Version und weitere Kapitel informiert werden möchten, können Sie sich auf folgender Seite eintragen: Zur Buchseite.

Das Ziel, das durch eine Fast Data Plattform erreicht werden soll, ist es Ereignisse inner- und außerhalb des Unternehmens zu erfassen, neue Erkenntnisse zu gewinnen und zeitnah auf bestimmte Ereignisse zu reagieren.

Neben der technischen Herausforderung, eine solche Plattform überhaupt umsetzen zu können, empfiehlt es sich, eine zentrale Plattform zu schaffen, die von sämtlichen Produktteams des Unternehmens als Basisinfrastruktur genutzt wird.

Durch die Tatsache, dass damit allen ein zentrales System zur Verfügung gestellt wird, wird die Plattform zu einem Verbindungspunkt auf organisatorischer Ebene - Daten aus verschiedensten Quellen können miteinander kombiniert oder korreliert werden. Eine Silobildung gibt es nicht. Gleichzeitig werden die Systeme des Unternehmens voneinander entkoppelt, d.h. ein System, das Daten produziert, muss nichts über die Systeme wissen, die die Daten konsumieren. Umgekehrt interessieren sich auch die Konsumenten nur für die Daten, nicht für die Produzenten. Auch für die Integration von Microservices ist die Plattform bestens geeignet.

Eine Fast Data Plattform erlaubt durch Unterstützung von großen Datenmengen, Nah-Echtzeitverarbeitung und Data-Streaming ein breites Spektrum an Anwendungsfällen. Ein klassischer Bereich, für den auch viele Big Data Plattformen (wie z.B. Data Lakes) zunächst eingerichtet werden, ist Analytics. Hier können neben regelmäßigem Reporting die KPIs des Unternehmens zeitnah überwacht werden. Außerdem kann man mit den Daten der Plattform auch direkt gearbeitet werden, diesen Bereich umschreibe ich mit Reaktion, da es oft darum geht, auf Ereignisse zu reagieren. Hier werden bisherige Prozesse digitalisiert, und völlig neue Dienstleistungen und datengetriebene Produkte entwickelt, sowie vorhandene Produkte mit mehr Intelligenz ausgestattet.

Beispiel (Analytics): In einem e-Shop sollen laufende Kennzahlen ermittelt und auf einem Dashboard angezeigt werden. Einige sollen zeitnah aktuell sein, um ggf. mit Marketingaktionen zu reagieren oder eine Recommendation Engine dynamisch zu steuern.
Beispiel (Reaktion): Eine Wetter-App soll den Nutzer auf Basis seiner aktuellen Geo-Location und Wettervorhersagen in seiner Region mit einer Push Notification warnen.

Ein Strom an Daten

Da ständig neue Ereignisse (engl. Event) auftreten, bilden sie einen kontinuierlichen Datenstrom (engl. Stream). Die Grundlagen zu Event Streams und Stream Processing habe ich in einem vorherigen Blog Post erklärt.

Eine Fast Data Plattform bildet selbst ebenfalls einen kontinuerlichen Strom. Im Gegensatz zu einem “Netz” von Systemen, das kreuz und quer Daten miteinander austauscht, werden Events in die Plattform gespeist, dort dann in Streams transformiert, und schließlich in Use-Case-bezogene Systeme ausgegeben.

Solange das Unternehmen existiert, läuft die Plattform dauerhaft weiter und verarbeitet die eingehenden Daten. Wie bei den Streams beschrieben, gibt es niemals ein finales Ergebnis. Outputs werden entweder überschrieben oder ständig hinzugefügt.

Beispiel: In einem e-Shop werden alle Bestellungen an die Fast Data Plattform übermittelt. Aus den Bestellungen wird der durchschnittliche Bruttobestellwert pro Stunde ermittelt, der dann auf einem Dashboard angezeigt wird. Während die Zeit fortschreitet, erscheinen neue Bestellungen, und der Bestellwert der aktuellen Stunde wird aktualisiert. Bricht die nächste Stunde an, wird der vorherige Bestellwert nicht mehr verändert, sondern der Wert für die neue Stunde wird wieder nach und nach aufsummiert. Der aktuelle Wert pro Stunde wird in eine Datenbank geschrieben und von einem Dashboard aus der Datenbank ausgelesen und angezeigt.

Die Basis - der zentrale Datenhub / Streaming Plattform

Die Grundlage einer Fast Data Plattform bildet immer die zentrale Datenanlaufstelle (engl. Hub). Sie ist die Sammelort für alle Events, die im gesamten Unternehmen anfallen. Die Events werden in der Datenplattform je nach Typ in eigene Container gelegt und nach Thema kategorisiert. Alle Bestellungen landen im Container für Bestellungen, alle Webseiten-Klicks im Container für Webseiten-Klicks.

Da mit Strömen gearbeitet werden soll, muss der Datenhub gleichzeitig die Funktionen einer Streaming Plattform erfüllen. Eine Streaming Plattform muss das Konzept von Data-Streams direkt unterstützen, und ihre programmatische Anbindung (APIs) entsprechend das Verarbeiten von Streams ermöglichen.

Aktivitäten einer Fast Data Plattform

Innerhalb der Fast Data Plattform laufen folgende Aktivitäten permanent ab.

Zunächst müssen die Daten in Form von Events in den zentralen Datenhub eingespeist (ingest, englisch für aufnehmen oder einnehmen) werden. Die Events stammen aus verschiedensten Quellen, wie beispielsweise einem Online Shop, einer Mobile App, Sensoren, Backend Services, sowie bereits existierenden Datenbanken und Altsystemen.

Die Verarbeitung der Events kann man mit transformieren und ableiten (engl. derive) zusammenfassen. Diese dauerhaft ablaufende Aktivität bildet das Herzstück der Plattform. Hier werden aus den Rohdaten, also den reinen Fakten, Informationen erzeugt. Manche Rohdaten müssen noch angereichert oder so vorbereitet (also transformiert) werden, dass sie in den folgenden Arbeitsschritten leichter zu verarbeiten sind oder Datenschutzbestimmungen entsprechen. Nun können die diversen Datenströme miteinander korreliert oder im Strom Berechnungen ausgeführt werden.

Sowohl die rohen Events als auch die berechneten Informationen werden in der Plattform gespeichert, teilweise auch dauerhaft oder zumindest über einen längeren Zeitraum verwahrt (engl. to store).

Schließlich werden die berechneten Ergebnisse ausgeliefert (engl. to serve). In den meisten Fällen wird das nicht direkt aus dem Datenhub geschehen, sondern über Datenbanken. Dabei wird je nach Use Case die passende Datenbank gewählt. Die Anforderungen an Datenbanken entspannen sich durch die Tatsache, dass Daten nicht in der Datenbank selbst berechnet werden müssen, sondern dort nur für die spätere Abfrage optimiert hinterlegt werden.

Komponenten einer Fast Data Plattform

Ingest

Grundsätzlich ist es möglich, dass die Quellen ihre Events direkt an die Plattform senden. Tatsächlich geht das oft nur bei unternehmensinternen Backend-Diensten, da sich nur diese im gleichen Netz und der entsprechenden Sicherheitszone befinden.

Für alle anderen Fälle werden die Daten über einen Sammeldienst vermittelt, den so genannten Collector. Dieser soll auch sicherstellen, dass das Event nicht unstrukturiert sondern in einem fest definierten Format vorliegt um spätere ETL-Schritte zu vermeiden. Der Collector empfängt das Event, entweder direkt im richtigen Format, oder wandelt es in ein für die Plattform akzeptables Format um. Gerade Daten, die direkt aus Datenbanken kommen, liegen in einem vom Hersteller bestimmten Format vor, genauso wenn bereits bestehende Systeme angebunden werden.

Auch ein App- oder JavaScript-Frontend wird üblicherweise einen Collector ansprechen, der dann app- und webspezifische Themen wie Security, CORS, oder Cookies behandelt. Dies ermöglicht eine saubere Trennung von Zuständigkeiten, da sich der Hub nach wie vor nur um die Datenhaltung kümmert.

Die direkt oder vom Collector geschriebenen Streams werden als Input-Streams bezeichnet und sollten ausschließlich Rohdaten und keine berechneten Werte enthalten.

Transform & Derive: Stream Processing

Individuelle Services verarbeiten wie schon beschrieben die Rohdaten aus den Input-Streams und leiten aus diesen Informationen Streams ab. Daher heißen die Streams, die sie erzeugen, abgeleitete Streams (engl. Derived Stream). Es bietet sich auch an, die Informationen immer in eigene Streams zu schreiben statt direkt in eine Datenbank. So können auch andere Dienste auf die abgeleiteten Daten zugreifen und ein eigener, meist einfacherer Service kann sich darum kümmern, Datenbanken aus Streams zu befüllen.

Die Streaming Services können wie ganz normale Backend-Services entwickelt werden. Es bietet sich jedoch auch an, Stream Processing Frameworks einzusetzen, die Stream-Berechnungen wie Windowing und Rolling Counts bereits mitliefern.

Transform & Derive: Big Data Tools

Neben Stream Processing werden die Daten auch über diverse Big Data Tools verarbeitet, ein Sammelbegriff für alles, was nicht wieder einen Stream ausgibt, aber auf großen Datenmengen operieren kann. Hierzu zählt die Berechnung von Reports, Statistiken, und Machine Learning-Modellen.

Store: Long Term Storage (LTS)

Ein Sonderthema ist die Langzeitspeicherung von Daten. Der zentrale Datenhub selbst ist oft nicht dafür ausgelegt, Streams komplett zu speichern, sondern behält die Daten nur begrenzt vor, beispielsweise über einen Zeitfaktor (TTL, Time-to-Live) oder über Größenbeschränkungen. Das liegt oft nur daran, dass die Hardware-Umgebung für den zentralen Datenhub eher für eine gute Performance und Redundanz ausgelegt und damit kostspieliger ist.

Sollen Daten längerfristig gespeichert oder archiviert werden, was für Reporting, Audits und Machine Learning wichtig sein kann, sollten sie in einen Langzeitspeicher geschrieben werden. Dieser ist meistens für niedrige Kosten und einfachen Zugriff optimiert, wie z.B. Ein S3-Bucket.

Serve

Schließlich sollen die berechneten Ergebnisse angezeigt oder in einem Datenprodukt (z.B. die Recommendations, die im e-Shop erscheinen) verwendet werden. In den meisten Fällen wird das nicht direkt oder nur teilweise aus dem Stream geschehen. Ein Dashboard zeigt üblicherweise einen Verlauf von Daten über ein definiertes Zeitintervall (z.B. die letzten sieben Tage) in Graphen an. Per WebSocket könnten diese aber auch automatisch um neu berechnete Daten erweitert werden und damit aktuell bleiben ohne dass der Nutzer die Seite neu laden muss.

Event Streams produzieren oft Time Series-Daten, also Werte, die für einen bestimmten Zeitstempel gelten. Daher werden gerne Datenbanken wie Cassandra eingesetzt, die aufgrund ihres Spaltenformates Werte pro Zeit effizient auslesen können. Je nach Anwendungsfall, also in Abhängigkeit davon wie die Daten abgefragt werden sollen, kann auch eine SQL-Datenbank oder ein Suchindex wie ElasticSearch oder SOLR befüllt werden.

Monitoring, Logging, Alerting

Kein inhaltliches Herzstück der Plattform, aber auch technische Kennzahlen der Plattform selbst müssen überwacht werden können, z.B. wie schnell die Datenströme verarbeitet werden, wie viele Events durch die Plattform laufen, ob das Stream Processing kontinuierlich durchläuft oder Fehler wirft, ob Machine Learning Modelle gut performen, und vieles mehr.

Beispiel: Wetter-App

Wie würde man nun die die eingangs erwähnte Wetter-App mit Hilfe einer Fast Data Plattform umsetzen? Zur Erinnerung soll der Nutzer auf Basis seiner aktuellen Ortung und zu dem ermittelten Ort passenden Wettervorhersagen mit einer Push Notification über angekündigte Unwetter gewarnt werden.

Im ersten Schritt werden die Events modelliert. Wie man das tun kann, wird in folgenden Kapiteln weiter im Detail erklärt. Wir haben uns nun erst mal zwei einfache Events überlegt. LocationChangedEvent sagt aus, dass sich die Ortung des Nutzers signifikant verändert hat. Das Event enthält neben einer User ID die Geo-Koordinaten. ForecastReceivedEvent sagt aus, dass eine neue Vorhersage eingetroffen ist und enthält einen enumerierten Wert für das angekündigte Wetter und Geo-Koordinaten für das betroffene Gebiet.

Die Mobile-App fragt in einem bestimmten Zeitintervall den Standort des Nutzers ab und übermittelt die Koordinaten an den Collector. Dieser speichert die Koordinaten samt der Nutzerkennung als Event in den Datenhub. Diese Events bilden den Input-Stream der geänderten Standorte.

Parallel dazu fragt der Collector einen externen Wetteranbieter regelmäßig über seine REST-Schnittstelle an und lädt aktuelle Wettervorhersagen in den Datenhub. Diese Events bilden den Input-Stream der neuen Wettervorhersagen.

In beiden Fällen haben wir keine Delta-Events sondern jedes Event erhält die volle, aktuelle Information. Das gestaltet die Verarbeitung etwas einfacher, da wir uns nicht auf ältere Events beziehen müssen.

Ein Service liest nun die Standorte aus. Dabei ist es wichtig, im Stream nach User ID zu gruppieren um nur den aktuellsten Standort zu betrachten. Alte (z.B. älter als zehn Minuten) Standort-Events werden zudem herausgefiltert. Parallel dazu wird der Stream mit Wettervorhersagen gelesen. Alte Events werden ebenfalls gefiltert. Findet der Service nun einen Match, d.h. befindet sich ein Nutzer in einem Gebiet mit einer Wetterwarnung, wird ein UserEnteredForecastAreaEvent in einen weiteren abgeleiteten Stream geschrieben.

Zuletzt liest ein Service die Warn-Events, erzeugt daraus die Push-Notification und schickt sie an die App des Nutzers. Um den Nutzer nicht mit Push-Notifications zu überfrachten, wird in einer lokalen Datenbank der letzte Notification-Timestamp gespeichert.

Zusammenfassung

Wenn Ihnen dieses Kapitel gefallen hat und Sie entweder entscheiden müssen ob Sie eine Fast Data-Plattform benötigen oder sich fragen wie Sie eine Fast Data Plattform am besten aufbauen sollen, schauen Sie sich gerne mein Buch Fast Data in der Praxis an oder kontaktieren Sie mich für eine mögliche Zusammenarbeit.

Diesen Post teilen

RSS-Feed

Neue Posts direkt im Newsreader.

RSS-Feed abonnieren

Newsletter

Neue Posts sowie Neuigkeiten rund um Big Data, Spark, und Scala. Maximal eine E-Mail im Monat.