Ein modernes Datennetz aufbauen

Neben einem auf Oracle-Technologien basierenden klassischen Data-Warehouse-System gab es bereits seit mehreren Jahren ein On-Premises-Hadoop-System, das Hunderte Terabyte an Unternehmensdaten beherbergte. Im Laufe der Zeit implementierte die zentrale IT auf diesem System immer mehr analytische Use-Cases und der Datenbedarf für die Beantwortung fachlicher Fragestellungen wuchs rasant.

Das hatte zur Folge, dass die Ladestrukturen bald nicht mehr zu den wachsenden Anforderungen passten, was wiederum die Analysemöglichkeiten einschränkte und damit die Arbeit der Data Engineers und Data Scientists blockierte. Auch die Skalierbarkeit des Systems stellte die ITAbteilung vor immer größere Herausforderungen.

Zum Beispiel war es den dezentralen nationalen IT-Abteilungen und einigen Fachabteilungen wichtig, eigenverantwortlich an Analytics-Use-Cases arbeiten zu können, die nicht durch die zentrale IT betreut werden.

Dank des vorhandenen Hadoop-Systems waren dem Team bereits einige Use-Cases bekannt. Teile davon waren bereits implementiert und bereit für die neue Plattform. Allerdings gab es viele Anforderungen, die noch offen waren – teils aus technischen, teils aus Kapazitätsgründen.

Um einen detaillierten Überblick zu bekommen, teilte das Team die Anforderungsaufnahme in zwei Teilprojekte: ein Teilprojekt für die Erhebung der fachlichen Anforderungen, ein Teilprojekt für die eher technisch orientierten Anforderungen der zentralen und nationalen Data- Science- und Data-Engineering-Teams. Das erste Zwischenergebnis wurde harmonisiert. So entstand eine Liste an Epics für das Product Backlog.

Nach der Anforderungsaufnahme wurde das Bild klarer. Zwei Anforderungen waren besonders deutlich:

• Die Datenplattform soll eine Vielzahl an unabhängigen Data-Analytics-Umgebungen bereitstellen, die neben individualisierbaren Konfigurationen auch unterschiedliche technische Anforderungen erfüllen.
• Es sollen Daten von hoher Qualität, aktuell und vollständig zur Verfügung stehen, die bei Bedarf durch spezifische Daten eines Use-Case angereichert werden.

Nachdem die groben Anforderungen nun bekannt waren, ging es an die Technologieauswahl. In die engere Auswahl kamen Alternativen, die eine Plattform schnell und in alle Richtungen skalieren lassen, ohne dabei an Flexibilität einzubüßen. Hier lohnte sich ein Blick in Richtung Cloud. Schließlich sind es Eigenschaften wie Skalierbarkeit, Verfügbarkeit und Flexibilität, mit denen die großen Cloud- Unternehmen für ihre Services werben. Da sich das Unternehmen im Rahmen seiner IT-Strategie bereits für die Microsoft Azure Cloud entschieden hatte, war die Richtung hier klar und wir konnten früh den Kontakt zu Microsoft aufnehmen, um kritische Fragen zu klären, wie:

• Wie lassen sich die Zugriffe auf Azure-Storage- Accounts steuern?
• Welche Dinge sind in Bezug auf das Netzwerk zu beachten?
• Wo könnte es zu Performance-Einschränkungen kommen?

So kam heraus, dass bei vergleichbar großen Datenmengen die Schreib- und Lesegeschwindigkeit einzelner Storage-Accounts ebenso wie die Netzwerkbandbreite zum Flaschenhals werden konnten. Eine Aufteilung in verschiedene Container würde hier nicht ausreichen. Stattdessen wurde geraten, die Daten auf verschiedene Storage-Accounts zu verteilen.

Alle Daten aus dem Hadoop-System wurden benötigt. Dabei gab es zwei Dinge, die etwas knifflig waren: Erstens mussten Hunderte Terabyte an Daten aus dem Unternehmensrechenzentrum in die Cloud transferiert werden. Und zweitens mussten die Ladestränge migriert werden, um die Daten auch in der Cloud weiterhin zur Verfügung zu haben.

Darüber hinaus ergab sich aus den Anforderungen, dass künftig viele verschiedene SAP-Systeme, Datenbanken und Dateien angebunden werden würden, aber auch nationale oder Use-Case-bezogene Daten einzelner Data-Sciences-Teams.

Eine wichtige Frage, denn ein Szenario wie beim aktuellen Hadoop-System, bei dem die Anzahl der potenziellen Use-Cases schon zu Beginn im hohen zweistelligen Bereich lag – Tendenz steigend –, musste verhindert werden, wobei ein Data-Analytics- Projekt von mehreren Monaten als ein Use- Case galt.

Reicht bei dieser Fülle an unterschiedlichen Anforderungen eine einzelne Datenplattform noch aus? Es gibt Konzepte, diesolche Abhängigkeiten teilweise auflösen: durch eine zentral verwaltete Referenzumgebung, bei der Use-Casebezogene Umgebungen wie Satelliten um ihren Referenzplaneten kreisen.

Die Referenzumgebung stellt dann alle zentral verwalteten Daten bereit und kümmert sich um die Aufbereitung und Qualitätssicherung. Sie diente also zunächst als Umgebung für die Migration der Hadoop-Umgebung und ist auch inhaltlich Bestandteil der zentralen IT.

Die Use-Case-Satelliten können lesend auf den Referenzdatenbestand zugreifen und die Daten konsumieren. Außerdem können sie eigene spezifische Daten in ihre Satelliten laden. Für deren Verfügbarkeit, Qualität und Aktualität sind sie dann selbst verantwortlich.

Dieser Ansatz hat zwei Vorteile: 

• Zum einen sind die Use-Case-Satelliten sehr flexibel, da sie nahezu unabhängig voneinander agieren können.
• Auf der anderen Seite werden Redundanzen bei der Datenhaltung vermieden.

Jede Umgebung und jeder Satellit bekam eine eigene Azure Subscription, was die Flexibilität erhöhte. Außerdem konnten die Kosten, die jeder Use-Case für die Datenplattform verursacht, zielgerichtet zugewiesen und vergeben werden.

Die Bereitstellung der Azure Subscriptions übernahm das im Unternehmen bereits vorhandene Cloud-Infrastruktur-Team. Neben der Subscription und einem zugehörigen Service Principal kümmerte es sich um allgemeine Netzwerkkomponenten, zum Beispiel um ein eigenes, gepeertes virtuelles Netzwerk pro Umgebung, das Zugriffe auf das Unternehmensnetzwerk ermöglicht.

Wie in der Cloud üblich, wurden die Bereiche Storage und Compute getrennt voneinander betrachtet. Auch wegen der großen Datenmengen setzte das Team für die Datenspeicherung auf Azure-Storage- Accounts. Die sind in vier Schichten aufgeteilt:

1. Im Raw Layer befinden sich die unveränderten Daten aus den Quellsystemen.
2. Diese werden im Stage Layer in das einheitliche Datenformat Apache Parquet überführt.
3. Im Business Storage werden sie systemübergreifend miteinander verknüpft.
4. In der letzten Schicht, dem Serve Layer, werden Teile der Daten Use-Case-spezifisch aufbereitet.

Für jede Schicht wurde ein eigener Data Lifecycle definiert, der beschreibt, wann Daten in den unterschiedlichen Access Tiers verfügbar sind. Das ist wichtig, um die Speicherkosten zu minimieren. Im Raw Layer werden Daten beispielsweise nach 90 Tagen ohne Zugriff vom Hot Tier in den Cold Tier überführt und weitere 30 Tage später in den Archive Tier.

Mit einem weiteren Broker Storage in der Referenzumgebung lassen sich in einzelnen Satelliten-Umgebungen eigene, externe Daten bereitstellen.

Mit Hilfe des Azure Storage Explorers oder des Azure Storage Browsers können Daten dort abgelegt und später in die entsprechenden Satelliten-Umgebungen transferiert werden. Um die Abhängigkeiten zwischen einzelnen Satelliten-Umgebungen zu minimieren, wurde im Broker Storage für jeden Satelliten ein eigener Container angelegt.

Warum werden externe Daten nicht direkt in den Raw Storage eines Satelliten geladen, fragen Sie sich jetzt vielleicht. Die Antwort lautet: Aus Sicherheitsgründen. Der Broker Storage ist das einzige Eingangstor für externe Daten, und das kann zentral überwacht werden.

Die Auswahl der passenden Compute-Services gestaltete sich etwas schwieriger.

Aus den technischen Anforderungen ergaben sich bestimmte Notwendigkeiten: Es brauchte ein grafisches ETL-Tool und eine ganzheitliche Data- Science-Oberfläche. Die Oberfläche sollte sich möglichst für alle Disziplinen in Data Engineering und Data Science eignen. Dafür waren zwei Gründe maßgeblich:

• Einzelne Entwicklerteams benötigten eine einheitliche Umgebung mit einem zentralen Einstieg.
• Aus Security-Gründen sollte der direkte Zugriff auf das Azure-Portal vermieden werden.

Als grafisches ETL-Tool wählte das Team die Azure Data Factory aus. Dafür sprachen vor allem die gute Integration in die Microsoft-Azure-Cloud-Welt sowie die große Auswahl an Konnektoren [Mic22- 2]. Bei der ganzheitlichen Data-Science-Oberfläche schwankte das Team zunächst zwischen Azure Synapse und Databricks.

Azure Synapse punktete mit der Möglichkeit, verschiedene Azure-Services wie Pipelines, Machine Learning Workbench, Azure Functions etc. miteinander zu verbinden. Diese starke Integration in die Azure-Cloud ist aber gleichzeitig auch eines der Gegenargumente: Dadurch entstünde eine hohe Abhängigkeit von Microsoft. Das würde die Migration zu einem anderen Cloud-Anbieter in der Zukunft nahezu unmöglich machen.