Suchen

Wie Zalando einen Data Lake mit Amazon S3 aufgebaut hat Ein langer Weg – der sich gelohnt hat

| Autor / Redakteur: Max Schultze* / Dr. Jürgen Ehneß

Mit mehr als 32 Millionen aktiven Kunden ist Zalando Europas führende Online-Plattform für Mode. Vor fünf Jahren hat das Unternehmen eine skalierbare Cloud- Dateninfrastruktur auf Basis des Amazon Simple Storage Service (Amazon S3) eingeführt. Ein technologischer Meilenstein und eine wichtige Voraussetzung für das Wachstum und den Erfolg des Online-Händlers.

Firma zum Thema

Oberste Priorität beim Aufbau des Zalando-Data-Lakes hatte die Integration der wichtigsten Datenquellen des Unternehmens.
Oberste Priorität beim Aufbau des Zalando-Data-Lakes hatte die Integration der wichtigsten Datenquellen des Unternehmens.
(Bild: ©rolffimages - stock.adobe.com)

In den ersten Jahren nach der Firmengründung war Zalandos IT-Umgebung ein stationärer Monolith. Große Teile der Infrastruktur, auf transaktionaler wie auch auf analytischer Seite, waren direkt integriert und voneinander abhängig. Mit der Zeit nahm nicht nur die Komplexität der Systeme zu, sondern auch die Anzahl der Teams, die sie nutzen mussten. Als 2015 der Wandel vom reinen Online-Händler zu einer umfassenden Modeplattform beschlossen wurde, stand fest: Zalando brauchte eine skalierbare Lösung, um den geschäftlichen Anforderungen auch in Zukunft gerecht werden zu können. Der Umstieg auf die Cloud war daher nur eine logische Konsequenz.

Nach der Evaluation mehrerer Cloud-Anbieter fiel die Wahl auf Amazon Web Services (AWS). Entscheidende Kriterien waren dabei die Zukunftsfähigkeit, die Verfügbarkeit und die Skalierbarkeit der Cloud-Lösung sowie das umfassende Ökosystem an Diensten. Im Zuge der Migration auf die Cloud wurde die monolithische Infrastruktur von Zalando auf Microservices heruntergebrochen. Dadurch erhielten die Entwicklerteams die volle Verantwortung – von der Entwicklung bis hin zum operativen Betrieb – für ihren Bereich der Technologieumgebung.

Die Data-Lake-Architektur von Zalando.
Die Data-Lake-Architektur von Zalando.
(Bild: Zalando)

Die neue technische Infrastruktur wirkte sich unmittelbar auf die Datenlandschaft des Unternehmens aus. Aus zentralen Datenbanken, auf die vorher eine Vielzahl von Komponenten direkt zugegriffen hatten, wurden dezentrale Backends, die sich über REST-Schnittstellen austauschen. Das Data Warehouse, das bislang direkt mit den transaktionalen Datenspeichern verbunden war, musste nun darauf umgestellt werden, mit Daten aus dezentralen Quellen ohne direkten Zugang zu arbeiten. Um diese Herausforderungen zu bewältigen, wurde ein dediziertes Team damit beauftragt, einen so genannten Data Lake aufzubauen (siehe Abbildung 1). Damit konnte einerseits ein zentrales Datenarchiv für die neue, verteilte Systemlandschaft geschaffen und andererseits eine verteilte Compute-Umgebung für das Unternehmen konzipiert werden.

Nach Aufhebung der durch relationale Datenbanken vorgegebenen Größenbeschränkungen stellte sich heraus, dass Zalando bereits große Mengen an potenziell wertvollen Daten produzierte. Um auch künftig mit dem wachsenden Datenvolumen umgehen zu können, suchte das Unternehmen nach einem Datenspeicher, der skalierbar, zuverlässig und kostengünstig war. Amazon S3 erwies sich hierfür als perfekter Dienst.

Oberste Priorität beim Aufbau des Data Lakes hatte die Integration der wichtigsten Datenquellen des Unternehmens. Für die Kommunikation zwischen den verteilten Microservices wurde ein zentraler Event-Bus eingerichtet. Außerdem wurde eine Archivierungskomponente hinzugefügt, um alle veröffentlichten Nachrichten im Data Lake als Kopien zu speichern. Die wichtigen Geschäftsprozesse tauschten sich bereits über den Event-Bus aus, wodurch dessen Inhalte besonders wertvoll für Datenanalysen waren. Grundlegende Anforderungen wie das Umformatieren und das Re-Partitionieren wurden mit einer serverlosen Datenpipeline umgesetzt.

Das 5-minütige Video „This is my Achitecture“ zeigt, wie Zalando die serverlose Datenpipeline zur Verarbeitung von Ereignisdaten konzipiert hat, um die Informationen in den Data Lake zu übertragen.

Während der Umstellung auf die Cloud wurden bei Zalando weiterhin viele wertvolle Datensätze im ursprünglichen Data Warehouse im Rechenzentrum produziert und gespeichert, darunter auch die zentrale Verkaufslogik des Unternehmens. Um diese Informationen ebenfalls im Data Lake verfügbar zu machen, wurde eine zweite zentrale Pipeline konstruiert. Der dritte und letzte Teil des Puzzles waren die Web-Tracking-Daten. Diese umfangreichen Rohdaten sind vor allem in Kombination mit den bereits vorhandenen Datensätzen interessant. Mit den insgesamt drei Pipelines war eine initiale Datenversorgung des Data Lakes sichergestellt.

Die S3-Optionen im Detail

Durch das permanente Wachstum der Datenmenge im Data Lake von Zalando ergaben sich verschiedene Herausforderungen, die dank der vielfältigen Funktionen von S3 aber leicht zu bewältigen waren:

Datenaustausch und -zugriff

Es ergibt keinen Sinn, große Datenmengen zu speichern, die keiner nutzt. Die erste große Herausforderung bestand daher darin, die Daten den Teams verfügbar zu machen, die daraus wertvolle Informationen ableiten können. Bei Zalando haben viele Teams eigene AWS-Konten, so dass es sofort nötig war, Anforderungen für den Datenaustausch über Konten hinweg zu definieren. Am einfachsten erfolgt dies über Bucket Policies. Damit lassen sich S3-Buckets mit Definitionen versehen, die es erlauben, bestimmten Entitäten (wie zum Beispiel Rollen) Zugriffsberechtigungen für klar definierte Aktivitäten zuzuweisen. Ein Beispiel für eine solche Aktivität ist „GetObject“ für eine bestimmte Ressource, etwa ein spezifisches Präfix in einem Bucket. Dies ist ein sehr bequemer Einstieg, der bei einer geringen Anzahl von Verbindungen zu anderen Konten gut funktioniert. Wenn aber immer mehr Anwender Zugriff auf die Daten benötigen, wird die Verwaltung einer Bucket-Richtlinie schnell unübersichtlich, außerdem gibt es eine Größenbeschränkung für diese Richtlinien.

Zalando brauchte daher einen isolierteren und skalierbareren Ansatz und begann mit der Verwendung von IAM-Rollen. IAM-Rollen funktionieren in diesem speziellen Fall ähnlich wie Bucket-Richtlinien: Durch das Hinzufügen einer Inline-Policy lassen sich auch hier erlaubte Aktivitäten für bestimmte Ressourcen spezifizieren. Der einzige Unterschied besteht darin, dass für eine IAM-Rolle zuerst eine Vertrauensbeziehung mit dem Ziel-Account etabliert wird: Der Anwender gibt die Account-Nummer an, der er vertraut, und weist dem Berechtigten eine Rolle zu, unter deren Verwendung er auf die Daten zugreifen kann.

Backups und Wiederherstellung von Daten

Bei einem großen Data Lake, den sich viele Anwender für verschiedene Produktionsanwendungen teilen, müssen sich die Daten sichern und auch wiederherstellen lassen – etwa nach einem Störfall. Am einfachsten funktioniert dies über eine Versionierung der Buckets in der Produktivumgebung. Damit kann der Anwender frühere Objektversionen nutzen, zum Beispiel, wenn er auf eine ältere oder gelöschte Version zugreifen will, die nicht über Standard-S3-API-Aufrufe sichtbar ist. Jedes Präfix wird dabei zu einem Stapel von Objekten, von denen standardmäßig nur das jeweils letzte zugänglich ist.

Die Versionierung ist praktisch, wenn etwa die Datenpipeline einen Fehler enthält, der ein Zurücksetzen erfordert. Noch wichtiger ist, dass die Versionierung auch beim Löschen von Daten funktioniert: Anstatt Objekte tatsächlich zu löschen, wird eine Löschmarkierung erstellt. Die Daten sind damit nicht mehr sichtbar, aber bei Bedarf immer noch zugänglich. 2017 erwies sich diese Funktion für Zalando als Retter in der Not. Jeder kennt den Vorfall des Neulings, der versehentlich eine Produktionsdatenbank zurücksetzte. Bei Zalando wurde dadurch die gesamte Historie der Web-Tracking-Daten gelöscht, ganze Terabytes an Objekten. Dank aktivierter Versionierung konnte der Internethändler jedoch alle Daten innerhalb von einem Tag wiederherstellen – einfach durch das Entfernen der Löschmarkierungen.

Weitere Möglichkeiten zur Datensicherung bietet die S3 Cross-Region Replication (CRR). Zalando nutzt diese Funktion bereits seit einiger Zeit, um Kopien von Daten in einer anderen AWS-Region zu speichern. Sie lässt sich einfach implementieren, indem man die Buckets in die jeweilige Region repliziert und dann sofort die Inhalte des Ziel-Buckets in Amazon S3 Glacier archiviert.

Optimierung der Speicherkosten

Im Terabyte-Bereich sind die Speicherkosten noch überschaubar. Bei Datenvolumina von mehreren Petabytes kommt man aber trotz des hervorragenden Preismodells von Amazon S3 nicht daran vorbei, die Kosten der Cloud zu optimieren.

Wichtig ist zunächst, sich einen Überblick über die tatsächlichen Datenbestände zu verschaffen. Bei Zalando arbeiten derzeit fast 400 Teams mit insgesamt mehr als 8.000 S3-Buckets. Es ist unmöglich, dieses Speichervolumen allein anhand von Anwendereingaben nachzuvollziehen. Abhilfe schafft die Funktion S3 Inventory, die Basisinformationen über jedes Objekt in den konfigurierten Buckets liefert. Einfache Angaben – etwa zur Objektgröße oder zuletzt geänderte Zeitstempel – geben Aufschluss über das Alter der Daten sowie über ihre Auswirkungen auf die Kosten. Wenn die Versionierung aktiviert ist, sieht man außerdem, wie viele Objekte nicht in der neuesten Version vorliegen und ob eine Datenbereinigung sinnvoll ist.

Voll zum Tragen kommt S3 Inventory in Kombination mit S3 Access Logs. Wenn feststeht, wie sich die gespeicherten Daten auf die Kosten auswirken, lässt sich mit dieser Funktion zwischen heißen und kalten Daten unterscheiden, sprich: hochwertigen Datensätzen, auf die ständig zugegriffen wird, sowie Datensätzen, die sehr umfangreich sind, die aber niemand liest. Werden letztere bereinigt, kann das zu deutlichen Kosteneinsparungen beitragen.

Amazon S3 bietet verschiedene Speicherungsklassen für unterschiedliche Anforderungen und Zugriffsmuster an: Voreingestellt ist die Klasse S3 Standard, die höchste Verfügbarkeit bei niedrigen Kosten für die Datenabfrage bietet. Für das reine Speichern von Daten gibt es jedoch kostengünstigere Optionen. So ist die Funktion S3 Standard-Infrequent Access (S3 Standard-IA) perfekt, um Objekte zu speichern, die über einen längeren Zeitraum nicht angefasst werden, aber verfügbar bleiben sollen – beispielsweise historische Daten. Die Speicherkosten sind um etwa 40 Prozent niedriger als bei S3 Standard, dafür kosten Abfragen etwa das Doppelte. Noch kosteneffizienter sind die Speicherklassen S3 Glacier und S3 Glacier Deep Archive. Unter der Inkaufnahme von höheren Abrufzeiten eignen sie sich für sehr große Datenmengen, auf die selten zugegriffen wird.

Speicherklassen bringen deutliche Einsparungen, wenn die Daten und Anwendungsfälle bekannt sind. Der manuelle Umgang damit ist jedoch recht aufwändig. Abhilfe schafft die S3-Intelligent-Tiering-Funktion, mit der Daten auf Basis vordefinierter Kriterien automatisch in andere Speicherklassen übertragen werden. So werden bei Zalando Objekte, auf die innerhalb von 30 Tagen kein Zugriff erfolgt ist, mithilfe des S3 Intelligent-Tiering automatisch in die Speicherklasse S3 Standard-IA verschoben. Erst wenn auf solche Objekte wieder ein Zugriff erfolgt, landen sie wieder in der Speicherklasse S3-Standard. Auf diese Weise spart Zalando 37 Prozent seiner jährlichen Speicherkosten ein.

Viele Datensätze verlieren mit der Zeit an Wert. Auch wenn man sich mit dem S3 Intelligent-Tiering Speicherkosten einspart, sollte man bestimmte Daten nach einiger Zeit vollständig bereinigen. Wichtig sind dabei gut gewählte Aufbewahrungszeiten, die sich über Lifecycle Policies definieren lassen. Lifecycle Policies bieten aber noch weitere Funktionalitäten. Zum Beispiel lassen sich damit Datenübertragungen zwischen Speicherklassen festlegen oder bestimmte Objekte für die spätere spezielle Verwendung kennzeichnen. Zalando nutzt die Lebenszyklusrichtlinien vor allem, um Datensätze zu bereinigen, die aufgrund gesetzlicher Vorgaben nur für eine gewisse Zeit gespeichert werden dürfen.

Fazit

Zalandos Migration in die Cloud war ein langer Weg, aber er hat sich gelohnt. Der Aufbau eines Data Lakes mit Amazon S3 erlaubt es den Mitarbeitern im gesamten Unternehmen, mit Daten zu arbeiten, auf die sie zuvor keinen Zugriff gehabt hätten. Mittlerweile gibt es viele Datenpipelines, die von internen Nutzern betrieben und verwaltet werden. Durch die Nutzung verschiedener Amazon-S3-Features konnte Zalando zudem die Speicherkosten senken: Mithilfe von S3 Intelligent-Tiering und Lifecycle Policies spart das Unternehmen jährlich bis zu 40 Prozent seiner Kosten ein. Schließlich können die internen Nutzer Informationen aus den gespeicherten Daten schnell und einfach extrahieren und analysieren, um damit das Kundenerlebnis beim Einkauf über die Zalando-Website oder mobile Anwendungen zu verbessern.

Wer einen Data Lake auf Basis von Amazon S3 einrichtet, hat eine Vielzahl von Optionen für das Datenlayout und die Organisation mittels Buckets und entsprechender Präfixe. Letztlich geht es aber nicht nur darum, einen Plan für gute Bezeichnungen zu finden und die Daten vernünftig zu organisieren, sondern auch darum, sich außerdem nach dem Plan zu richten. Denn bei einer Größenordnung von mehreren Tausend Buckets ist es sehr aufwändig, die Daten zu bereinigen und zu speichern und so ihre globale Verwaltbarkeit zu gewährleisten.

Seit Zalando den ersten Amazon-S3-basierten Data Lake eingerichtet hat, hat sich nicht nur die Dateninfrastruktur des Unternehmens, sondern auch S3 stark verändert. Zalando hatte in den vergangenen Jahren die Gelegenheit, viele bereits verfügbare Funktionen zu nutzen.

Max Schultze, Lead Data Engineer bei Zalando.
Max Schultze, Lead Data Engineer bei Zalando.
(Bild: Zalando)

Seit Anfang des Jahres wird eine Strategie der Speicherdezentralisierung umgesetzt, wobei die Teams ihre eigenen Buckets nutzen, um Datensätze über einen zentralen Governance- und Datenverwaltungsansatz zu speichern und zu teilen. Mit einem täglichen Datenwachstum von mehreren Terabytes und einem Speichervolumen von 15 Petabyte und mehr evaluiert das Unternehmen aber auch permanent neue Cloud-Speicherfunktionen und arbeitet an innovativen Technologien rund um die Datenverwaltung.

*Der Autor: Max Schultze, Lead Data Engineer bei Zalando

(ID:46724717)