Aufbau einer flexiblen, stabilen und agilen Datenplattform

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.

Auswahl der Komponenten

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.

Orchestration

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.  

Endgültige Architektur

Unsere endgültige Architektur integriert alle oben genannten Tools und Dienstleistungen, um eine Villa für die Datenplattform zu bauen. Die verschiedenen Säulen

• Batch-Verarbeitung
  
  


• Echtzeitverarbeitung
  
  


• maschinelles Lernen und AI
  
  


• Grundanalytik und Self-Service BI
  

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.