Anlässlich der Data & AI World Tour (DAIWT) baten wir Marco Lohaus, Head of Business Intelligence der Firma flaschenpost SE, über die Zusammenarbeit mit Databricks zu sprechen.

 

Herr Lohaus, können Sie uns ihr Unternehmen kurz vorstellen?

Die flaschenpost startete im Jahr 2016 als erster Onlineshop für die Sofortlieferung von Getränken innerhalb von 120 Minuten bis zur Haustür. In den Folgejahren erweiterte das Unternehmen sein Sortiment um ein vollständiges Supermarktangebot und expandierte in nur fünf Jahren auf ein Liefergebiet von mehr als 200 Städten bundesweit. Mittlerweile beschäftigt das Unternehmen rund 20.000 Mitarbeiter, etwa 750 davon an den Verwaltungsstandorten Münster, Köln und Berlin. Mit der rasanten Expansion des datengetriebenen Unternehmens wuchs auch die Komplexität der IT-Infrastruktur, sowohl in Bezug auf die Datenmengen als auch auf die Anforderungen an das bestehende System.

 

Wie kam es zur Zusammenarbeit mit Databricks?

Vor etwa zwei Jahren gab es erste Berührungspunkte. Damals ging es vor allem um die Auswertung von Google-Daten, wie Web-Tracking über die Website. Angesichts des dynamischen Wachstums des Unternehmens haben wir schon bald festgestellt, dass wir mit unserer bestehenden Infrastruktur an die Grenzen stoßen. Die monatliche Datenbasis entwickelte sich von ursprünglich 30 Gigabyte auf mehr als 40 Terabyte pro Monat innerhalb kürzester Zeit.

Zunächst verfolgten wir einen Monolithen-Datenbank-Ansatz mit einem selbst entwickelten ERP-System. Diesen haben wir durch einen Event-Driven-Ansatz abgelöst, der in der Azure-Welt mit Service- und Event-Hubs verankert ist. Entsprechend sehen wir uns mit wesentlich mehr Daten konfrontiert und stehen vor Big-Data-Herausforderungen, wie Single Source of Truth, Data Governance, Near Real Time oder Ressource Allocation. In Summe sind das zu viele Daten, um sie auf einem gewöhnlichen SQL-Server zu speichern, geschweige denn, sie dort auswerten zu können. Aus diesem Grund haben wir uns verschiedene Lösungen am Markt angeschaut und Ende 2022 einen Proof of Concept (POC) ausgeschrieben.

Unser Ziel war es, alle vorhandenen Daten in Verbindung setzen zu können. Dafür haben wir einen dezentralen Ansatz vorangetrieben. Das ermöglicht unseren Analysten, das Maximum aus den Daten herauszuholen, und dies war einer der entscheidenden Punkte für Databricks. Als datengetriebenes Unternehmen war es uns wichtig, Compute und Storage getrennt betreiben zu können, sodass wir die Daten nicht mehr kopieren müssen.

Zuvor nutzten wir dafür eine SQL-Datenbank, auf die alle Analysten zugegriffen haben. Dies hatte Nachteile, denn wir hatten viele Prozesse mit unterschiedlichen Prioritäten. Einerseits gab es Anfragen, die in fünf Minuten erledigt sein müssen, anderseits jedoch auch viele mit niedrigerer Priorität. Allerdings griffen alle gleichzeitig auf die Rechenleistung zu. Diese Vorgehensweise führte zu hohen Fixkosten. Darüber hinaus mussten die Daten in diesem klassischen Data-Warehouse-Konzept synchronisiert werden.

Heute liegen alle Daten gesammelt im Azure Data Lake, und über die Virtualisierung lassen sich die Zugänge verwalten. Wir verfolgen einen Data-Mesh-Ansatz, wobei uns der Unity-Katalog von Databricks hilft. Zusätzlich unterhalten wir dezentrale Umgebungen, um neue Datenprodukte erstellen zu können, die in dem Verantwortungsbereich der jeweiligen Fachabteilung liegen.

 

Heißt das, Sie haben auch die Prozesse weg von der BI-Abteilung hin zu spezialisierten Teams verlagert?

Das ist richtig. Statt klassisch alles über die Business-Intelligence-Abteilung laufen zu lassen, in der es Verantwortliche für Controlling, SCM oder Marketing gibt, verlagern wir die Zuständigkeit in die Teams selbst. Das erhöht die interne Geschwindigkeit aller Prozesse enorm. Unsere Aufgabe als BI-Abteilung ist es nun, eine funktionale Plattform zu entwickeln, um die Rechenleistung zu verwalten, die Kosten zu handhaben und Daten entsprechend bedarfsgerecht anzureichern. Möchte also eine Fachabteilung irgendwelche Daten aus einem Data Warehouse nutzen, um beispielsweise eine CSV damit anzureichern, bieten wir den Kollegen passende Lösungen als Komponenten auf der Plattform an, damit das Arbeiten möglichst einfach und intuitiv wird. Wir haben den Aufbau einer Managed-Self-Service-Plattform im Sinn. Alle Daten liegen auf dieser Plattform, und die Funktionen stehen den Teams individuell zur Verfügung. Sie können dann ihre eigenen Analysen, wie Wochen- und Monatsberichte, sowie Handlungsempfehlungen ableiten.

 

In der Vergangenheit hat Flaschenpost somit sehr viel mit Datenbanken gearbeitet und dann kam der Punkt, als es so nicht mehr handhabbar war. Das hatte doch sicherlich auch mit unstrukturierten Daten, halbstrukturierten Daten und strukturierten Daten zu tun. Wie hat die Databricks-Lösung hierbei geholfen?

Entscheidend ist, dass wir im Data Lake alles im Delta-Format ablegen können. So bleiben wir maximal flexibel. Wir haben den Bronze-Silber-Gold-Layer-Ansatz gewählt. Bronze-Layer meint: Alle Daten unverändert aus der Quelle, also Daten, die nicht angereichert oder bearbeitet wurden. Beim Silber-Layer werden die Daten schon verfeinert: Anomalien werden gefixt, wodurch wir ein Format erhalten, mit dem Analysten arbeiten können. Der Gold-Layer ist die Veredelung der Daten. Diese Aufgabe liegt in den Fachabteilungen, die mit den jeweiligen Daten arbeiten müssen.

Zusätzlich unterhalten wir aber noch ein Data Warehouse. Dessen Verwaltung liegt in der Verantwortung der Business Intelligence als Abteilung. Dort können wir auf dem Silber-Layer die Aggregation der Daten vornehmen, um eine Business-Logik zu bauen. So entstand ein hybrider Ansatz aus Data Mesh und Data Warehouse für interne Zielsetzungen, wie Data Governance und Reporting.

 

Sie sagten, dass flaschenpost vor zwei Jahren den Kontakt zu Databricks aufgenommen hat: Wann ging es richtig los?

Im Dezember 2022 ging der POC erfolgreich für Databricks aus, und Anfang 2023 starteten wir. Mit Vollgas wurde die Plattform aufgebaut, und Go-Live war schon im August 2023. Es dauerte also nur 8 Monate, bis wir die ersten Funktionen auf der Plattform aktivieren konnten. Das ist sehr schnell gegangen, oft spricht man hier ja von Jahren.

 

Das ist wirklich ungewöhnlich schnell! Nun: Bislang klang das nach einem sehr einfachen Ablauf. War das durchweg so, oder gab es einen Moment, als man stark ins Stocken geriet?

Wir haben einige Zeit gebraucht, um die Stärken auszuloten, da wir Databricks anfangs zu stark als ETL-ELT-Tool eingestuft haben. Wir hatten ursprünglich nicht damit gerechnet, dass Databricks sogar die gesamte Plattform sein könnte. Und wir haben Erfahrungen sammeln müssen, wie man im Data Lake alles formatiert, verwaltet und die Übersicht behält, damit die Data-Lake-Kosten überschaubar bleiben.

Anfangs haben wir die JSON-Dateien glatt gespeichert, wie sie vom Service-Bus kamen. Dadurch hatten wir sehr viele kleine Dateien, was die Kosten in die Höhe trieb und viel Rechenleistung verschwendete. Wir haben dies geändert, indem wir die Datensätze als größere Parquet-Files im Data Lake ablegten. Das erforderte zur Einführung zwar viele Prozesse, erhöhte jedoch die Geschwindigkeit. Genau hier liegt die Stärke der Plattform. Wenn wir einmal oder zweimal am Tag ein großes Paket abholen, ist das besser als mehrmals täglich viele einzelne kleine Dateien abzurufen. Damit umgehen wir den althergebrachten Ansatz, die JSON-Dateien ständig zu kopieren, erst in den Bronze-Layer, dann in den Silber-Layer und so weiter. Das ist für die flaschenpost besonders wichtig, denn bei uns fallen etwa zwei Terabyte am Tag an.

 

Sprechen wir über künftige Herausforderungen: Das sind doch sicherlich die viel größeren Datenvolumina, die es zu beherrschen gilt?

Korrekt: Aktuell besteht die Herausforderung darin, große Datenmengen effizient zu verarbeiten. Bald wird es darum gehen, die wichtigen von den unwichtigen Daten zu trennen. Die zentrale Frage wird sein, was man aus den Daten wirklich an Erkenntnissen herausziehen kann und wieviel mehr Erkenntnis aus einem höheren Datenaufkommen wirklich entsteht. Das muss als Prozess transparent werden.

Hier kommt eine weitere Neuerung durch Databricks ins Spiel: Jedes Team hat seine eigene Umgebung, die eigenständig abgerechnet wird. Dadurch sind wir in der Lage, zu sehen, was der einzelne Use Case kostet oder kosten würde. Diese Möglichkeit bestand vorher nicht. Wir können jetzt direkt bewerten, ob sich ein Use Case wirklich lohnt, oder ob die bloße Aufbereitung der Daten schon zu kostenaufwendig wäre. Das wird sicherlich unsere Arbeitsweise verändern.

 

Das ist auch für unsere Leserschaft ein wichtiger Aspekt, der ROI und TOC als Gedanke: Was kostet mich etwas und wann habe ich die Kosten eingespielt? Wenn wir das somit richtig verstanden haben, dann war Ihre Zusammenarbeit mit Databricks nicht nur eine technische Entscheidung, sondern ebenso eine betriebswirtschaftliche?

Zu Beginn fokussierten wir uns auf die Technologie, wir haben aber schnell gemerkt, dass wir die Arbeitsweise des gesamten Unternehmens verändern können. Ursprünglich dachten wir, Databricks wäre eine Lösung für die Intensivnutzer, die mehr Rechenleistung benötigen, aber dann haben wir verstanden, dass wir eine Plattform mit Policies aufbauen können, die allen zur Verfügung steht.

 

Somit war die Entscheidung für Databricks gut, wichtig und schlicht notwendig, richtig?

So ist es. Wir mussten uns aufgrund einer Herausforderung auf die Suche nach neuen Produkten machen, die wir mit den bestehenden Lösungen nicht meistern konnten. Während dieser Suche haben wir gemerkt, dass wir hier keine Nische beleuchten, sondern ein neues Feld betreten.

Herr Lohaus wir danken für das Gespräch!