Vom on-premise Data Lake zu AWS

Hintergrund

Der Kunde, ein deutscher Hersteller von Nutzfahrzeugen, betreibt eine IT-Landschaft, die über zahlreiche Abteilungen verstreut ist. Daten werden in einer Vielzahl von – oftmals älteren – Applikationen, Datenbanken und Systemen produziert und gesammelt. Die Daten reichen teilweise über 30 Jahre zurück und liegen in vielen unterschiedlichen Formaten vor. Um die Reporting- und Data-Science-Initiativen zu bündeln, beauftragte der Kunde im Jahr 2016 Data Reply mit der Entwicklung eines On-Premise-Data-Lake, den die Berater aufgebaut haben und seitdem betrieben. Der Data Lake basierte auf Cloudera Hadoop und Apache Kafka und erwies sich bald als deutlich weniger skalierbar und flexibel als das schnell wachsende Angebot der großen Cloud-Provider. Deshalb startete der Kunde kürzlich ein Cloud-Migrationsprojekt, für das er erneut auf die Expertise von Data Reply vertraute.

Migration zu AWS

Data Reply erhielt den Auftrag, in der Cloud von Amazon Web Services (AWS) einen Data Lake einzurichten. Zunächst baute das Team eine zentralisierte Datenspeicherungs- und Management-Lösung auf, die auf dem Amazon Simple Storage Service (S3) beruht. Dorthin wurden anschließend Daten migriert, die on-premise in Apache Hadoop Distributed File System (HDFS) gespeichert waren. Basierend auf Data-Lake-Best-Practices werden die Daten in der Cloud in Layern organisiert. So wurden die Daten zunächst – hauptsächlich mittels Kinesis und Apache NiFi – in ein Landing-Layer geschrieben, meist in den Dateiformaten der einzelnen Quellsysteme. ETL-Pipelines verarbeiten die Daten anschließend und speichern sie in einer kleineren Zahl ausgewählter Dateiformate. Die Pipelines maskieren dabei sensible Informationen und reichern die Daten zusätzlich an – in einer Lösung, die von Data Reply entwickelt wurde. Das Ergebnis wird in einem finalen Layer namens Datahub gespeichert. Letztendlich erhalten verschiedene AWS-Accounts Zugriff auf einzelne Datenpakete, die für individuelle Anwendungsfälle benötigt werden. Die Trennung in verschiedene Accounts erlaubt es, anfallende Kosten den jeweiligen Anwendungsfällen zuzuordnen.

Welche Services kommen zum Einsatz?

Auf expliziten Kundenwunsch setzt Data Reply in diesem Projekt – abhängig von den Gegebenheiten – auf Serverless-Lösungen: Für die Speicherung von Daten kommt AWS S3 zum Einsatz und AWS Glue für Spark-basierte ETL-Pipelines, die in Glue Workflows zusammengefasst sind. Als SQL-Interface findet Athena Anwendung und seit kurzem können BI-Analysten auch Quicksight für SQL-Abfragen und das Erstellen von Reports nutzen. Data Scientists werden eigene EMR-Cluster und bei Bedarf weitere Tools zur Verfügung gestellt.

Die Infrastruktur wird mittels AWS CloudFormation und Sceptre verwaltet. Für die Konfiguration der Glue Workflows und Jobs kommt ein eigens entwickelter Service zum Einsatz. Dieser wird beim Hochladen von Daten in den S3 Data Lake automatisch gestartet. Mit Hilfe von Basis-Konfigurationen im AWS Systems Manager berechnet der Service die optimale Zahl von Data Processing Units (DPUs), die für die Verarbeitung der zugrundeliegenden Daten notwendig sind. Dies verhindert, dass zu viele Cloud-Ressourcen angefragt werden und die Kosten aus dem Ruder laufen.

Außerdem verwendet Data Reply die Managed Services von AWS für Redis und Elasticsearch. Diese Systeme werden für Data Replys Masking-Lösung und die funktionelle Überwachung der ETL-Pipelines verwendet.

Organisation der Accounts

Kernstück des Data Lake ist der zentrale AWS-Account, wo die Daten entsprechend ihres Quellsystems auf mehrere S3-Buckets verteilt sind. In diesem Account laufen auch die AWS Glue ETL-Pipelines, die Datenpakete für eine Vielzahl von Anwendungsfällen vorbereiten. Der wichtigste Vorbereitungsschritt ist dabei das Maskieren von sensiblen Informationen, zum Beispiel auf Basis der DSGVO. Indem diese Schritte im Hauptaccount ausgeführt werden, können Vertraulichkeitsprobleme verhindert werden. Gleichzeitig erlaubt ein zusätzlicher Service anderen Accounts, die Daten wieder in Klartext zu überführen, sofern ein legitimer Grund und die entsprechende Berechtigung vorliegen.

Neben dem Hauptaccount gibt es noch eine Reihe von Accounts, die für spezifische Anwendungsfälle eingerichtet sind. Im Einklang mit Best Practices für AWS Cross-Account Access können Leserechte für benötigte Daten vergeben werden. Entwickler von datenverarbeitenden Applikationen können ihre bevorzugten Technologien einsetzen, ohne die Infrastruktur des Hauptaccounts unnötig unübersichtlich zu gestalten. Dadurch werden im Betriebsteam Kapazitäten frei, die sonst für die Bereitstellung und Wartung solcher Applikationen benötigt würden.

Vorteile der neuen Lösung

"By Design" skalierbar. Wie oben beschrieben greift Data Reply wo immer möglich auf Serverless-Lösungen zurück und nutzt damit die zentralen Vorteile der AWS Cloud.
Zentrale Datenspeicherung und -verarbeitung. Data Reply hat alle gesammelten Daten im Blick und kann den Zugriff sehr granular verwalten. So können sich Endnutzer im Unternehmen darauf konzentrieren, geschäftlichen Mehrwert zu schaffen, statt mühselig Daten aus einer Vielzahl von Systemen und in einer Vielzahl von Dateiformaten zu sammeln.
Flexibilität. Obwohl Data Reply Vorlagen und weitere Unterstützung für Data Scientists und Analysten anbietet, kann letztendlich jeder Nutzer selbst entscheiden, welche Technologien er für seinen Anwendungsfall verwenden möchte. Data Reply stellt die Daten in modernen, verbreiteten Formaten wie Parquet oder Avro zur Verfügung.
Sicherheit. Sensible Informationen werden automatisch geschützt.

DATA REPLY

Data Reply unterstützt als Teil der Reply-Gruppe Kunden darin, datengetrieben zu arbeiten. Data Reply ist in verschiedenen Branchen und Geschäftsbereichen tätig und arbeitet intensiv mit Kunden zusammen, damit diese durch die effektive Nutzung von Daten aussagekräftige Ergebnisse erzielen können. Hierfür konzentriert sich Data Reply auf die Entwicklung von Data-Analytics-Plattformen, Machine-Learning-Lösungen und Streaming-Anwendungen – automatisiert, effizient und skalierbar – ohne Abstriche in der IT-Security zu machen.