Moderne Unternehmen stehen immer mehr Daten zur Verfügung. Der Trick dabei ist, die Daten zu filtern, anzureichern und schließlich rückblickend zu analysieren, doch vor allem auch, über das zukünftige Vorgehen zu entscheiden. Eine gut durchdachte Datenstrategie und eine flexibel gestaltete Datenstruktur sind unerlässlich. Im Webinar „felyx: Clearing the road for Sustainable DataOps driven Architectures“ berichten Daan Stroosnier und Mees Strooker darüber, wie der E-Roller-Verleih Felyx seine Datenstrategie und infrastruktur neu ausgerichtet hat.
felyx ist ein schnell wachsendes niederländisches Start-up (2017), das Elektro-Roller vermietet. Kunden melden sich einfach in der App an und sehen dann, wo der nächste freie E-Roller geparkt ist. felyx ist mittlerweile in zwölf Städten in den Niederlanden, Deutschland und Belgien aktiv und hat ca. 6 000 Leih-E-Roller. Die monatlich gut 100 000 aktiven Nutzer haben bislang insgesamt 15 Millionen Kilometer zurückgelegt. Das Unternehmen erhebt auf unterschiedliche Weise Daten, die felyx nutzt, um seine Kunden besser zu bedienen und um strategische Entscheidungen zu treffen. Doch wie hat felyx seine Datenstrategie festgelegt und wie ist die Daten¬infra¬struktur aufgebaut?
Mehrere Datenquellen
Einen wichtigen Teil der Daten liefert die felyx-App. „Das sind hauptsächlich Kundendaten wie die Nutzung der App und der E-Roller“, so Daan Stroosnier, Global Head of Data Analytics. „Angereichert mit Dingen wie Referral-Aktionen, Rabatten usw.“ Eine weitere Datenquelle sind die E-Roller selbst: im Prinzip IoT-Geräte, die kontinuierlich Informationen an felyx übermitteln. „Allein der Akku der Roller ist ein IoT Device für sich“, so Stroosnier. „Er sendet uns Informationen zu Kapazität und Zustand, damit wir wissen, wann wir ihn austauschen müssen.“
Firmeneigene Techniker und Flottenmanager, die das „Servicepersonal“ von felyx sind, nutzen als operatives System ein eigenes Frontend. Dort befinden sich beispielsweise auch die Service-Tickets, in denen der Wartungszustand von E-Roller und Akku erfasst werden.
Zuletzt nennt Stroosnier die externen Datenquellen. „Informationen zum Wetter sind für uns natürlich wichtig. Denn bei schlechtem Wetter werden weniger Kilometer gemacht. Auch Marktdaten zur Konkurrenz werden in der Datenbank erfasst. Unsere Aufgabe als Datenbank¬ingenieure ist es, all diese Daten zugänglich zu machen und dafür zu sorgen, dass möglichst wenig menschliches Zutun nötig ist und Vieles automatisiert abläuft. Dazu ist es erforderlich, alle diese Daten zu erheben und vor allem für eine gute Daten¬infra-struktur zu sorgen.“
Von überaltert zu topmodern
Die ursprüngliche Daten¬infra¬struktur ist hauptsächlich organisch gewachsen. „Vor meiner Zeit bei felyx gab es einen Studenten, der das komplette Data Warehouse allein aufgebaut hat“, erzählt Dateningenieur Mees Strooker. „Er hat Fantastisches geleistet, doch am Ende war die Struktur nicht mehr zu halten und mussten wir praktisch wieder bei Null anfangen.“ Für jedes strategische und operative Erfordernis kam eine eigene Anwendung, was letztlich zu einem riesigen Wirrwarr an Anwendungen geführt hat. Als eines der größten Probleme erwies sich schließlich die Skalierbarkeit der PostgreSQL-Datenbank, was sich vor allem in Form von geringeren Leistungen äußerte. „Das hieß viel Zeitverlust und Wartungsbedarf, und auch, dass die analytischen Queries begannen, langsamer zu werden.“
Überalterung
In der alten Situation gab es ETL-Prozesse mit drei unterschiedlichen Möglichkeiten der Daten¬verarbeitung:
•Über Drittanbieter-APIs
•Über OLTP-Snapshots
•Über die Ereigniswarteschlange
Die ETL-Prozesse wurden auf Heroku gehostet, das mit isolierten Containern (sog. Dynos) arbeitet, die nur sehr umständlich zu skalieren sind. Horizontal stellt an sich kein Problem dar, denn es können problemlos weitere Container hinzugefügt werden. Bei vertikaler Skalierung kann es jedoch vorkommen, dass, wenn für einen bestimmten Dyno mehr Ressourcen erforderlich sind, eine gesamte Gruppe gleichzeitig skaliert werden muss, und dies verursacht höhere Kosten, als eigentlich erforderlich sind. Des Weiteren kam es zu Problemen mit der Ereignis¬warteschlange, wenn eine Änderung des Ereignisschemas vorlag.
Debugging und Fault Trapping waren schlecht dokumentiert und jede Anpassung wurde direkt mit den Live-Daten durchgeführt. Die Konsequenz war, dass eine Änderung bei Problemen nicht zurück¬genommen werden konnte, da die Quelldaten nicht mehr vorhanden waren. Auch eine Validierung der Daten, die zur Analyse übermittelt wurden, fand nicht statt.
Neue Situation
felyx entschied sich dafür, die gesamte Datenstruktur zu erneuern, und definierte dafür mehrere relevante Ausgangspunkte:
•Skalierbarkeit und Elastizität
•Veränderung als einzige Konstante
•Unix-Philosophie
•Verbesserte Debugging-Möglichkeiten
•Von ETL zu ELT
„In der Praxis bedeutet das, dass wir uns bei jedem Tool, das wir einsetzen möchten, fragen: ‚Können wir bei Bedarf wieder zurück?‘“, so Strooker. „Und in Sachen Unix-Philosophie haben wir für jedes Modul mit einem Wirksamkeitsnachweis oder einem Minimum Viable Product (MVP) gearbeitet, sodass wir am Ende noch zwei oder drei Optionen zur Auswahl hatten.“ Die Bilanz ist, dass unterschiedliche Technologien zusammenarbeiten, wobei wir insbesondere durch die bessere Dokumentation viel Zeit sparen, wenn irgendwo ein Problem auftritt.
Was bedeutet das in der Praxis? Die Rohdaten werden in verschiedenen Cloud Buckets gespeichert:
•Streaming Event Data im Avro-Format
•OLTP Datenbank-Snapshots als CSV
•Drittanbieter API-Calls in JSON
Die Ereignisdaten (Event Data) werden in einem kontinuierlichen Kubernetes-Pod verarbeitet und die Snapshots und Drittanbieter API-Calls über Airflow.
Am Ende landen die Daten im Snowflake Warehouse, wo sie von Apache Beam validiert werden. Das Schema wird von Liquibase verwaltet.
„Mit Apache Beam können wir große Datenmengen verarbeiten und validieren. Liquibase ermöglicht uns, Schemata inkrementell zu ändern, ohne dass in den Daten etwas verloren geht.“
Datenmodell
Das Datenmodell von felyx ist vielschichtig. Nicht nur, um die Qualität der Daten zu gewährleisten, sondern auch, um die Daten so zu formatieren, dass Datenanalysten und wissenschaftler mühelos damit arbeiten können. „Sie können selbst relationale Tabellen erstellen“, so Strooker. „Für unser Warehouse haben wir uns verschiedene Optionen angeschaut. Eine davon war ein Data Vault, doch das war technisch betrachtet ein Overkill.“
Am Ende entschieden sich die Dateningenieure für 3rd Normal Form with History. „Das ermöglicht uns die Erstellung angereicherter Schichten über den normalisierten Tabellen.“ Strooker betont, dass jede Entscheidung ein Kompromiss ist. „Und wir sind nie sicher, ob wir die richtige Entscheidung getroffen haben. Doch am wichtigsten ist die Möglichkeit, wenn wir switchen, die gesamte Datenstruktur neu aufzubauen, da wir über das richtige Tooling verfügen.“
Datenverarbeitung
Für die letztliche Umsetzung der Daten in verwertbare Informationen nutzt felyx das Data Build Tool (DTB) für die Verwaltung angereicherter Datenmodellen und das Aktualisieren von Data Marts. Dadurch wird es möglich, dass Datenanalysten mühelos einen Teil der Aufgaben von Dateningenieuren übernehmen, da sie dabei mit einfachen SQL-Anweisungen arbeiten können. Versionskontrolle, Testing und wiederverwendbarer Code in Form von Makros fallen damit in den Aufgabenbereich der Analysten.
„Was hinter DBT passiert, ist genauso wichtig“, so Strooker. „Mithilfe einfacher SQL-Anweisungen lässt sich für die Daten eine Trans¬formations¬pipeline erstellen. Aus diesem SQL-Code kann direkt eine Dokumentation erstellt werden, sodass jeder versteht, wofür der Code gut ist.“ Darüber hinaus bietet DBT verschiedene Materialisierungs¬strategien, einschließlich Tabellen, Ansichten und ephemeren Daten in Form von CTEs. „Auch inkremental ist möglich, wobei mit Hilfe von DBT geprüft wird, ob neue Daten vorhanden sind, welche die Query erfüllen, ohne dass der gesamte Datenbestand neu aufgebaut werden muss.“
Endnutzer
Wo landen all die standardisierten und angereicherten Daten am Ende? Die Endnutzer lassen sich – aus Sicht der Dateningenieure – in drei Gruppen unterteilen:
•Analytics Translators – sie verwenden Metabase für deskriptive und diagnostische Analysen
•Analytics Engineers – benutzerdefinierte Dashboards in RShiny und Dash, sowohl für deskriptive als auch diagnostische Analysen
•Data Scientists – sie verwenden ML-Modelle für prädiktive und präskriptive Analysen
Das Endergebnis
Im Zuge der gesamten Operation hat die Datenlandschaft von felyx ein ganz neues Gesicht erhalten. „Unser wichtigstes Ziel war Flexibilität“, so Strooker, „und die haben wir erreicht.“ Die jetzigen Tools ermöglichen sowohl Change Management als auch das Hinzufügen und Einladen neuer Datendomänen. „Das Geheimnis ist der intensive Einsatz von Templates wie Apache Airflow DAGs, DBT-Modellen und Helm Charts.“ Dies ermöglicht den flexiblen Wechsel zwischen mehreren Umgebungen und den dynamischen Einsatz von Scripts.
Die Schema¬verwaltung übernimmt Liquibase. Hierdurch kann das gesamte Datenmodell wenn erforderlich ohne Gefahr angepasst werden. Zu guter Letzt verwendet felyx noch Snowflake Zero Copy Cloning. Dadurch sind Tests mit einer Klonversion der Datenbank möglich, die später einfach gelöscht werden kann – – für die CI/CD-Pipeline sehr effektiv.
