Grüne Wiese als Ausgangspunkt
Eine Datenplattform aus dem nichts aufzubauen, bietet viele Möglichkeiten, aber auch Herausforderungen. Hinsichtlich der Tools gab es keine Einschränkungen, wir wollten den Schwerpunkt auf Google Cloud Komponenten legen. Es gab jedoch bereits einen Prozess für die Bereitstellung von Produkten, an welchem wir uns orientiert haben.
Diese Ausgangssituation führte zu einer intensives Auseinandersetzung mit unseren Tools und Prozesse. In diesem Prozess ist Jenkins CI für die Bereitstellung von Code in Staging- und Produktionsumgebungen mit einigen anderen Einschränkungen festgelegt, wie z.B. die Verwendung einer Infrastruktur als Code-Ansatz für Deployments. Tooltechnisch haben wir uns zunächst mit den von Google bereitgestellten Tools wie Bigquery, Dataflow und Composer beschäftigt, auf denen wir dann das Rückgrat unserer Datenplattform aufgebaut haben.
Bigquery
Bigquery ist ein Data Warehouse System von Google. Durch seine serverlose und skalierbare Architektur in Kombination mit einem SQL-Dialekt, der mit dem SQL2011-Standard kompatibel ist, gelingt eine einfache Bereitstellung der API für unsere Daten. Bigquery lässt sich auch nahtlos in Google Cloud Storage integrieren, wo bereits ein großer Teil unserer Daten gespeichert wurde.
Dataflow
Dataflow als Datenverarbeitungsmaschine hat die Fähigkeit, sowohl Streaming- als auch Batch-Daten zu verarbeiten. Dies bietet uns den Komfort, ein einziges Framework für beide Arten der Datenverarbeitung zu verwenden. Da es vollständig verwaltet wird, reduziert sich auch der Aufwand für die Bereitstellung von Ressourcen und Servern.
Apache Beam
Beam ist ein einheitliches Programmiermodell für Batch- und Echtzeitverarbeitung, welches auf verschiedene Maschinen, wie Dataflow, Spark, Flink, etc. portierbar ist. Die Verwendung dieses Frameworks macht uns gegenüber dem zugrunde liegenden Systemunnabhängig, so dass wir mit geringem Aufwand in der Lage sind, wechseln zu können.
Composer
Composer ist eine gehostete Version von Apache Airflow. Diese ermöglicht die programmgesteuerte Planung und Verwaltung unserer Arbeitsabläufe mit einem DAG-basierten Tool. Airflow wird auch außerhalb von Google genutzt und entwickelt, so dass wir durch die Wahl dieser Option unabhängiger werden.
Apache Geode
Geode ist eine speicherinterne Datentabelle für den Echtzeit-Datenzugriff, die ergänzend zu einem Data Warehouse wie Bigquery verwendet werden kann. Es bietet eine sofort einsatzbereite REST-Api zum programmgesteuerten Abrufen von Ergebnissen in Datendiensten.
Google PubSub
Eine weitere Möglichkeit, Daten pünktlich zu liefern, besteht darin, sie in eine Nachrichtenwarteschlange zu verschieben. PubSub wurde von Google bereitgestellt. Mit dem Senden von Transformationsergebnissen, z.B. Vorhersagen, in eine Warteschlange können andere Dienste diese Ergebnisse in Echtzeit aufnehmen und zur Entscheidungsfindung verwenden.
Technischer Aufbau
Dies alles in der Form einer Datenplattform zusammenzuführen, war die größte Herausforderung bei der Konzeption und Implementierung dieses Systems. Hinsichtlich der Programmiersprache haben wir uns für Python entschieden. Denn außer Apache Geode können alle Tools damit programmiert werden. Als Infrastruktur nutzen wir den Kubernetes Cluster, der von der Composer-Umgebung gestartet wurde. Von der DAG aus kann Composer bzw. Airflow sowohl Docker-Container als auch Dataflow-Jobs starten. So laufen alle unsere Prozesse entweder im Dataflow / Apache Beam oder sind in einem Docker-Container definiert. Dies hat den Vorteil, dass jede Aufgabe eine eigene Abhängigkeitsumgebung hat und die Aufgaben somit unabhängig sind. Da Composer mit Python 2.7 von Google bereitgestellt wird, können wir auf diese Weise beispielsweise weiterhin Aufgaben mit Python 3 implementieren. Composer startet die Aufgabe als Pod im Composer-Cluster, während der Datenfluss völlig unabhängig von diesem Cluster läuft. Dies ermöglicht es uns, mehr Aufträge parallel auszuführen.
Einrichtung der Datenverwaltung
Nachdem wir die Prozessstruktur eingerichtet haben, mussten wir eine SQL-kompatible API für die Bereitstellung unserer Kundendaten entwickeln. Um Datenstrukturen in mehreren Systemen effizient zu handhaben, haben wir uns für Apache AVRO als Datenformat entschieden. AVRO stellt für jede Datei ein Schema zur Verfügung, welches mit den Daten gespeichert wird. Darüber hinaus wurden die Daten durch MapReduce aufteilbar und komprimierbar gemacht. Diese Attribute verwenden wir, indem wir externe Tabellen in BigQuery erstellen. Tabellendefinitionen werden direkt aus den Dateien gelesen, die Schema-Entwicklung wird von AVRO selbst vorgegeben und von BigQuery unterstützt. Datendefinitionen werden in unserer Schema-Registry verarbeitet und dienen dazu, die Definitionen an einem Ort zu speichern und überall im System programmierbar zu ändern, indem man einfach ein neues Schema implementiert. Um Daten in Echtzeit bereitzustellen, wird das auf BigQuery basierende analytische Setup durch Apache Geode und PubSub ergänzt.
Einsatz dieser Architektur
Wie bereits erwähnt wird die gesamte Architektur durch Jenkins CI bereitgestellt. Somit muss für jede Aufgabe eine Jenkinsdatei erstellt werden. Um diesen Einsatz stabil zu halten, verwenden wir gewisse Tests wie beispielsweise Unit-Tests, Integrationstests und Datenintegritätstests. Mit dieser Einrichtung können wir unsere Plattform in Umgebungen einsetzen, in denen der Zugriff nur auf Servicekonten gewährt wird, so dass keine manuelle Interaktion möglich ist.
Prototypen-Ansatz
Um sicherzustellen, dass alle Komponenten einwandfrei zusammenarbeiten, haben wir mit dem Aufbau eines Prototypen begonnen. Schritt für Schritt haben wir die Komponenten aufeinander abgestimmt und alle nötigten Funktionalitäten ergänzt. Dieser Ansatz half uns recht schnell herauszufinden, wo unsere erste Strategie mit den verschiedenen Daten erfolgreich war und wo wir einen anderen Weg finden mussten, um unsere Ziele zu erreichen. Während der Ausarbeitung haben wir gelernt, wie man mit einigen Cloud Services umgeht. Daher waren wir am Ende sehr zuversichtlich, dass unsere Strategie ohne größere Komplikationen funktionieren würde und die gefundene Architektur unsere Erwartungen erfüllt.
Unsere endgültige Architektur integriert alle oben genannten Tools und Dienstleistungen, um eine Villa für die Datenplattform zu bauen. Die verschiedenen Säulen
vervollständigen unsere Vision einer Plattform, die allen Datenbedürfnissen unserer Organisation gerecht wird. Unser Ziel ist es, die Daten den richtigen Personen, zur richtigen Zeit und im richtigen Format zur Verfügung zu stellen.
Öffnungszeiten unseres Shops:
Mo - Fr: 9.30 bis 18 Uhr
Sa: 10 bis 14 Uhr