Um möglichen Missverständnissen gleich von Beginn an vorzubeugen: AWS bietet keinen Data-Lake-Service oder ähnliches an. Allerdings lassen sich mit den verschiedenen Datenspeicher- und Datenbank-Diensten in AWS Data-Lake-Strategien auf vielfältige Weise implementieren.

Die von uns vorgeschlagene Strategie ist einen von vielen Möglichen und bietet zahlreiche Ansatzpunkte zur Erweiterung. Das Data-Lake-Konzept ist auch keine Erfindung von AWS und kann auch im eigenen Rechenzentrum eine nützliche Idee sein. Allerdings erschließt sich der Nutzen von Data Lakes primär in der Public Cloud, da es letztendlich um das Speichern und Verarbeiten sehr großer Datenmengen etwa zur Analyse geht.

Was ist ein Data Lake?

Ein Data Lake ist ein zentraler Speicher für große Mengen strukturierter UND unstrukturierter Daten, der es Organisationen erlaubt, alle anfallenden Daten an zentraler Stelle speichern, verarbeiten und analysieren zu können. Die Hauptidee dabei ist, dass sich Unternehmen direkt mit der Analyse der Daten und nicht mit dem Aufbau und Betrieb eine Speicherinfrastruktur befassen sollen.

Das Data-Lake-Konzept sieht dazu vor, Daten aus verschiedensten Quellen „schnell“ in den Data Lake abzuleiten, um sie von dort aus direkt mit verschiedenen Tools weiterverarbeiten zu können – etwa zur Analyse, wobei die Analyseergebnisse dem Data Lake wieder zugeführt werden können. Wer jetzt meint, dass dies im Grunde das gleiche sei wie ein Data Warehouse, der irrt.

Beim Data Lake bleibt die Grundstruktur der Daten immer erhalten, d. h. man speichert die Rohdaten so wie sie sind im Data Lake. So geht keinerlei Information verloren und man kann auch nachträglich neue Analysen gegen die unveränderten Rohdaten fahren und damit neue Geschäftsfelder erschließen.

Data Lake und Data Warehouse

Aber es gibt noch weitere deutliche Unterschiede zum Data Warehouse, das man mit Recht ebenfalls als zentralen Datenspeicher im Unternehmen betrachten kann. Sollen Daten in einem Data Warehouse gespeichert werden, müssen diese zuvor in ein vorgegebenes Schema gebracht werden, etwa durch Vorschalten eines „Extract, Transform, Load“- also ETL-Prozesses, der die Daten so transformiert, dass sie im Data Warehouse gespeichert werden können.

Beim Data Lake hingegen wird das Schema erst dann auf die Daten angewendet, wenn die Daten gelesen werden. Dies erlaubt es, nicht nur strukturierte Daten im Data Lake abzulegen, sondern die Daten in ihrer Rohform einfließen zu lassen. Erst bei der Analyse wendet man das gewünschte Schema darauf an.

So kann man beim Befüllen des Data Lakes auf aufwendige ETL-Prozesse verzichten und sehr schnell Daten aus verschiedenen heterogenen Quellen im Data Lake ablegen. Das heißt nicht, dass für die spätere Aufbereitung – wie z. B. eine Analyse der Daten – keine ETL-Prozesse benötigt werden. Wir demonstrieren aber im nächsten Teil dieses Workshops, wie man auch ETL-Prozesse mit AWS Glue schnell und einfach z. B. in einer verwalteten Spark-Umgebung implementieren kann.

Das klassische Data Warehouse hat aber durchaus noch seine Daseinsberechtigung. Data Warehouses sind z. B. sehr gut geeignet für tägliche, wöchentliche und monatliche Reportings über transaktionale Daten. Allerdings ist es mit Data Warehouses z. B. schwierig, Use Cases wie Machine Learning zu unterstützen, weil dazu die passende Schnittstelle fehlt. Ein Data Lake ist also nicht dazu gedacht, ein Data Warehouse zu ersetzen, sondern primär um neue Cases zur Verfügung stellen.

Zudem sind in klassischen DB-Architekturen Berechnung (Computing) und (Speicherung) Storage eng miteinander verbunden. Das Data Lake hingegen ist in der Lage, Compute und Storage voneinander zu trennen. Wer also sein Data Lake z. B. auf Basis von AWS S3 baut, kann es tatsächlich nur zum Speichern der Daten verwenden. Denn S3 ist zunächst einmal ein relativ „dummer“ Speicher – wenn auch schnell, hoch skalierbar und hochverfügbar.

Erst wenn die Daten in S3 analysiert werden sollen, werden sie von den entsprechenden Tools und Framework aus dem Data Lake gelesen und mit einem Schema versehen. Man nutzt also nicht nur ein bestimmtes Werkzeug wie z. B. eine Data Warehouse zur Analyse, sondern wählt unter einer Vielzahl von AWS-Services jeweils den Passenden aus, ist also extrem flexibel und nicht auf das Verwenden eines einzigen Frameworks angewiesen.

Data-Lake-basierte Use Cases

Legt man beispielsweise wenig strukturierte Daten im Datenlake ab, kann man diese mit Tools wie Pig, Spark, Hive oder AWS Athena direkt aus dem Data Lake lesen und weiterverarbeiten. Das geht sogar so weit, dass man mit Hive oder Athena SQL-Anfragen stellen kann, ohne die Daten vorher einem ETL-Prozess zu unterziehen und ohne dass man dazu eine geeignete Infrastruktur betreiben muss.

Zusätzlich ist es falls gewünscht möglich, auf Basis der Daten im Dakelake eigene Machine-Learning-Workflow zu implementieren. Da Storage und Compute bei einem Data Lake, z. B. auf Basis von AWS S3, voneinander getrennt sind, kann man die Daten problemlos mit AWS Machinelearning oder AWS Sagemaker lesen, daraus ein Modell generieren, dass Vorhersagen auf Basis dieser Daten trifft, wobei auch hier die initialen Rohdaten immer im Data Lake gespeichert bleiben.

Unter dem Strich können Nutzer das gesamte Portfolio von AWS-Tools, die sich mit Dataprocessing befassen „auf“ ihr Data Lake einsetzen, wodurch sich unterschiedlichste Use-Cases ergeben, wie z. B. Data Processing, Data Warehousing, Reporting, Realtime Processing und Predictive Analytics; denn parallel zum Data Processing lassen sich problemlos auch Realtime-Usecases abbilden, die die Daten in Echtzeit verarbeiten.

Warum Data Lake mit AWS?

In der Praxis ist der Zeitanteil, den Unternehmen tatsächlich mit der Analyse von Daten verbringen und damit einen echten geschäftlichen Mehrwert für das Unternehmen schaffen, allerdings meist relativ gering – im Vergleich zu den Tätigkeiten, die erfolgen müssen, bevor es mit der Analyse losgehen kann. Das liegt daran, dass eine Vielzahl von Dingen geschehen muss, bevor man die Daten überhaupt analysieren kann.

Zunächst benötigt man einen Speicherort, der den Anforderungen eine Data-Lake-Strategie gerecht wird, wobei man das kontinuierliche Wachstum der Daten mit einkalkulieren muss. Außerdem muss man sich Gedanken um Zugriffsberechtigungen und Sicherheit machen, etwa mittels Verschlüsselung.

Eine Technik zum Indizieren und Auffinden der Daten (Labeling) ist darüber hinaus zusätzlich vonnöten. Legt man die Daten nämlich einfach nur in einem „dummen“ Data Lake ab, nutzt es dem Unternehmen gar nichts, wenn niemand weiß, „welche“ Daten im Data Lake stecken. Wie baut man also eine Data-Lake-Strategie so auf, dass sich das beschriebene Zeit-Verhältnis für das „undifferentiated heavy lifting and shifting“ zu einem günstigeren Verhältnis verschiebt?

Das Geheimnis liegt in der Auswahl der zu diesen Zweck am besten passenden AWS-Services. Im Kern wird dies – um das Ergebnis vorweg zu nehmen – der Datenspeicher AWS S3 sein, ergänzt um weitere AWS-Tools. Welche das sind wird klar, führt man sich die Eigenschaften und Anforderungen vor Augen, die ein Data Lake erfüllen muss.

AWS S3 erfüllt alle Anforderungen an einen persistenten Primärspeicher

Zunächst bedarf es einer automatisierten und zuverlässigen Datenaufnahme auch https://docs.aws.amazon.com/de_de/aws-technical-content/latest/building-data-lakes/data-ingestion-methods.html „Data Ingest“ genannt. Wie bekommt man also große Datenmengen sicher effizient und kostengünstig in die Cloud, bzw. konkret in S3? Der sichere Upload über die HTTPS-API ist nur bei überschaubaren Datenmengen vertretbar.

Zusätzlich bietet AWS zahlreiche erprobte Lösungen zu diesem Zweck an, wie z. B. den Database Migration Service , AWS Direct Connect, AWS Snowball oder auch Snow Mobile. Zudem kann man mit AWS Kinesis ein Echtzeit-Streaming betreiben. Darüber hinaus unterstützt Amazon S3 standardmäßig DistCP, einen Standard-Apache-Hadoop-Datenübertragungsmechanismus. Auf diese Weise können Nutzer DistCP-Jobs ausführen, um Daten von einem lokalen Hadoop-Cluster an einen S3-Bucket zu übertragen. Der Befehl zum Übertragen von Daten sieht normalerweise wie folgt aus:

hadoop distcp hdfs://source-folder s3a://destination-bucket

In jedem Fall bleiben die ursprünglichen Daten erhalten und werden nicht verändert. AWS S3 eignet sich hierfür auch deshalb besonders gut, weil S3 ein hochverfügbarer, hochskalierbarer Object-Store, der auf eine sehr hohe Haltbarkeit (99,99999999) ausgelegt ist, ohne dass der Kunde für die Datenspeicherung Server oder Speicher-Arrays bereitstellen muss.

Der Dienst repliziert die Daten automatisch in seiner Region und ist über eine RESTful- oder SOAP-API über das Internet ansprechbar. Das gelingt auch programmatisch über die unterstützten SDKs wie in unserer Workshop-Reihe zur Python-SDK Boto 3 gezeigt.

Zudem unterstützt S3 Lifecycle-Policies, denn Daten haben in Praxis unterschiedliche Zugriffsmuster. Mit dem S3-Lifecycle-Management lassen sich automatische Übergänge zwischen den Speicherklassen in S3 wie Standard, IA oder Glacier einrichten, denn mit zunehmenden „Alter“ der Daten, nimmt üblicherweise die Zugriffsrate ab bis hin zur reinen Langfrist-Aufbewahrung im Archive-Dienst Glacier, was letztendlich Kosten spart. Auch S3 und Glacier sind über Lifecycle-Policies eng miteinander integriert.

Zur Verwaltung der Lebenszyklus-Konfigurationen kann der Nutzer die AWS CLI-Befehle „put-bucket-lifecycle-configuration“, „get-bucket-lifecycle-configuration“ und „delete-bucket-lifecycle“ etwa im Rahmen von Bash- oder Powershell-Skripten verwenden. Alternativ lassen gelingt das auch aus eigenen Anwendungen in den unterstützten SDKs. Konkret ist jede Amazon S3-Lebenszykluskonfiguration eine XML-Datei ist. Allerdings lässt sich bei Verwendung der CLI der XML-Code nicht direkt verwenden, sondern muss stattdessen in ein JSON-File verpackt werden, etwa so:

Hier weiterlesen