Ein klassisches Data Warehouse wird abgelöst – eine EDV-Lovestory.

on 07.09.2020 by Bernhard Janetzki

Let’s get this party started – Ein vielversprechender, erster Kontakt

Mitte März 2019 erreichte uns eine Nachricht von Christian Weber, dem COO von Freeletics, über das Kontaktformular unserer Firmenwebsite. Ein ehemaliger Kollege aus der Schweiz habe uns empfohlen, man benötige Unterstützung bei der Neukonzeption und Entwicklung einer Lösung in AWS, um das bestehende Data Warehouse ablösen zu können.

In love with Data – Ein leichtes Kribbeln

Mittlerweile bezeichne ich mich manchmal gerne als EDV-Opa. Seit mehr als 25 Jahren baue ich nun verschiedene Dinge im Netz. Am Anfang war es bei mir zuhause der Linux Router, der die Familie über das LAN mit Internet versorgte und mir dabei half, die grundlegenden Funktionsweisen des Internets und seiner Protokolle wie TCP, UDP oder HTTP zu verstehen. Heute unterstütze ich mit unserem Team unsere Kunden bei der Konzeption und Implementierung von Anwendungen im Internet.

Das bekannte Startup Freeletics dabei zu unterstützen, ihr DWH abzulösen und eine neue, zukunftssichere Architektur zu entwerfen, löste in mir sofort ein leichtes Kribbeln aus. Die zu verarbeitenden Datenmengen mussten immens sein!

Zwar hatten wir bis dahin bereits Projekte On-Premise und in der Azure-Cloud umgesetzt, darunter auch solche, die man heute gerne als „Big-Data“ Projekte bezeichnet, – mit AWS hatten wir zu diesem Zeitpunkt allerdings nur grundlegende Erfahrung sammeln können. Als Expert*innen wollten wir uns in diesem Bereich deshalb nicht bezeichnen. Mit genügend Respekt vor der Aufgabe ließen wir uns aber auf eine nähere Betrachtung ein.

It’s a match! – Ein rasches Anbahnen

Nach einem ersten Kennenlernen mit Christian und seinem Data Engineering Team war schnell klar, dass es zu einer Zusammenarbeit kommen würde.

Das Team wusste, worauf es ankommt: Ein tiefgreifendes Verständnis von Technologien und deren Zusammenspiel im Allgemeinen sowie Erfahrung bei der Konzeption und Implementierung von Anwendungen.

Understanding the past – Bestehendes verstehen

Um ein neues, zukunftssicheres System entwickeln zu können, mussten wir zunächst das Bestehende verstehen. Das Team half uns dabei, einen Einblick in das aktuelle System zu bekommen, das Freeletics bis dahin mit Daten versorgte:

  • Talend als ETL Werkzeug
  • Vorwiegend Batch basierte Datenverarbeitung
  • EC2 Linux Maschinen als ETL Hosts
  • Redshift Datenbanken als DWH
  • Datenquellen und deren Zielformate im DWH wurden erfasst

Durch den rasanten Zuwachs an Freeletics Nutzer*innen, auf aktuell mehr als 42 Millionen, und die damit entstehenden Datenmengen ist diese Lösung jedoch an ihre Grenzen geraten.

Building something new together – Neues konzipieren

Basierend auf den Erkenntnissen zum bestehenden DWH und dem prognostizierten Wachstum wurden folgende Anforderungen ermittelt:

What do you need? – Die Anforderungen

Nichtfunktionale Anforderungen

  • Events werden über HTTP bereitgestellt
  • Mehr als 100 Events pro Sekunde müssen verarbeitet werden können
  • Datenverarbeitung nahezu in Echtzeit
  • Eine zentrale Datenbank soll Freeletics-Nutzerdaten samt verschachtelter Attribute speichern
  • Events sollten mit den Nutzerattributen aus der Datenbank angereichert werden
  • Die Anwendung soll skalierbar, zuverlässig, erweiterbar und leicht zu warten sein
  • AWS als Cloudprovider
  • Der Betrieb der Infrastruktur soll vom Data Engineering Team weitgehend selbstständig durchgeführt werden
  • Die Datenhaltung soll in einem S3 DataLake erfolgen
  • Python als primäre Programmiersprache
  • PySpark zum Verarbeiten größerer Datenmengen

Funktionale Anforderungen

  • Das Data Analytics Team soll durch Zugriff auf Rohdaten komplexere Analysen mit Spark durchführen können
  • Teams aus Produktentwicklung bis hin zu Finanzen sollen die Möglichkeit bekommen generische, aber komplexe Analysen und einfache Visualisierungen selbstständig erstellen zu können

How do we get there? – Die neue Architektur

Datenhaltung der Nutzer*innendaten und deren Attribute

Aufgrund hoher Schreib- und Lesezugriffe sowie einer Vielzahl, auch verschachtelter, Attribute haben wir uns für eine DynamoDB als Datenspeicher der Freeletics-Nutzer*innen entschieden. Die schnelle Reaktionszeit und Skalierbarkeit von DynamoDB waren ebenfalls ausschlaggebend für diese Wahl.

Eventverarbeitung

Daten werden über ein APIGateway entgegengenommen und durch Lambda-Funktionen prozessiert. Prozessierung meint die Anreicherung der Events durch Nutzer*innen-Attribute (gespeichert in der DynamoDB) sowie GDPR-konforme Maskierung der sensiblen Daten wie IP Adressen, Emailadresse usw.

Ein allgemeines Problem bei der eventbasierten Verarbeitung ist das Fehlerhandling. Irgendetwas geht dabei meist schief, egal wie stabil die Systeme designt sind. 🙂

Sind Events fehlerhaft, hat unsere Software Fehler. Ist ein Zielsystem vorrübergehend nicht erreichbar, kann ein Event in diesem Moment nicht erfolgreich prozessiert werden. Für diese Probleme gibt es in AWS SQS dead-letter queues.

Quelle: https://de.wikipedia.org/wiki/Notfallspur_(Gef%C3%A4lle)#/media/Datei:HGG-Zirlerbergstra%C3%9Fe-Notweg.JPG

 

Tritt bei der Verarbeitung ein Fehler auf, werden fehlerhafte Events in eine SQS verschoben. Ein Monitoring der Queues mit anschließender Reprozessierungs-Funktion ermöglicht ein erneutes Verarbeiten fehlerhafter Events, ohne diese zu verlieren.

Datenhaltung der Events

Events werden partitioniert nach Event-Typ/YYYY/MM/DD in S3 gespeichert. Die Speicherung erfolgte in den zuvor erwähnten Lambda-Funktionen.

Ein nachgelagerter DataBricks Job sorgt dafür, dass einzelne Events in Parquet Files zusammengefasst werden. Dies ermöglicht einen schnelleren und kostengünstigeren Zugriff auf die Daten.

Weitere Daten

Ad Spend Daten wurden tagesaktuell über klassische Python Batch Jobs via API geladen, oder bei größeren Datenmengen, wie beispielsweise den CRM Daten, über Spark Jobs verarbeitet und ebenfalls im S3 DataLake bereitgestellt.

Zugriff auf Daten

Für das Data Analytics Team

Auf die einzelnen Events im DataLake oder auch die durch DataBricks aggregierten Events kann durch Spark zugegriffen werden, wodurch auch die effiziente Auswertung großer Datenmengen ermöglicht wird.

Für Teams aus Produktentwicklung bis hin zu Finanzen

Freeletics entschied sich für das Tool „Amplitude“, um Daten beispielsweise Produktmanager*innen zugänglich zu machen. Hierzu wurden Events durch eine Weiterleitung in eine „Export“-Lambda an Amplitude übergeben. Auswertungen können somit nahezu in Echtzeit durchgeführt werden. Durch Identifier zwischen den unterschiedlichen Event-Typen können komplexe Auswertungen für die Produktentwicklung und das Controlling durchgeführt werden.

Hand in hand for data – Gemeinsam implementieren

Gemeinsam mit dem Data Engineering Team von Freeletics haben wir das zuvor geplante System implementiert. Nach einer Entwicklungszeit von ca. 8 Monaten waren alle benötigten Funktionalitäten im neuen System implementiert und für die Anwender*innen verfügbar. Das alte DWH konnte abgeschaltet werden.

Danach übernahm das Data Engineering Team von Freeletics den Betrieb, die Wartung und Weiterentwicklung des Systems vollständig. FELD M unterstützt das Team bis heute dabei.

A bright future – Ein versöhnlicher Ausblick

Als Entwickler*innen sollten wir uns von dem, was einer meiner besten Freunde gerne als „Technologie-Geballer“ beschreibt, nicht abschrecken oder gar einschüchtern lassen. Weitreichende Erfahrung mit und ein tiefgreifendes Verständnis für Technologien lassen uns gute Anwendungen entwickeln – sei es in Azure, AWS, On-Premise oder in sonst einer Umgebung.

Denn am Ende basieren unsere Anwendungen noch immer auf den guten alten Protokollen wie TCP, UDP oder HTTP.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.