Tools und Workflows zur Datenspeicherung in der Cloud, Teil 2 Data-Lake-Strategie mit AWS Data Ingest umsetzen

Die grundlegenden Technologien und Produkte, die AWS zur Datenspeicherung anbietet, haben wir bereits kennengelernt. Nun wollen wir demonstrieren, wie Unternehmen mit den Mitteln von AWS eine Data-Lake-Strategie entwickeln können.

Anbieter zum Thema

PoINT Software & Systems GmbH

DataCore Software GmbH

Scality

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 eine von vielen Möglichkeiten 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 Informationen 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, das heißt 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 zum Beispiel 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 beispielsweise in einer verwalteten Spark-Umgebung implementieren kann.

Das klassische Data Warehouse hat aber durchaus noch seine Daseinsberechtigung. So sind sie für tägliche, wöchentliche und monatliche Reportings über transaktionale Daten sehr gut geeignet. Allerdings ist es mit Data Warehouses unter anderem 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 zum Beispiel 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 Frameworks aus dem Data Lake gelesen und mit einem Schema versehen. Man nutzt also nicht nur ein bestimmtes Werkzeug wie beispielsweise ein 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 Data Lake ab, kann man diese mit Tools wie Pig, Spark, Hive oder AWS Athena direkt aus diesem 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 Data Lake eigene Machine-Learning-Workflows zu implementieren. Da Storage und Compute bei einem Data Lake, beispielsweise auf Basis von AWS S3, voneinander getrennt sind, kann man die Daten problemlos mit AWS Machine Learning oder AWS Sagemaker lesen. Daraus lässt sich 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 der Datenverarbeitung dienen, "auf" ihrem Data Lake einsetzen. Dadurch ergeben sich unterschiedlichste Use-Cases, darunter Data Processing, Data Warehousing, Reporting, Realtime Processing und Predictive Analytics. Denn parallel zum Data Processing lassen sich problemlos auch Realtime-Anwendungsfälle abbilden, bei denen die Daten in Echtzeit verarbeitet werden.

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, 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 an Voraussetzungen zu erfüllen sind, 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 sollte 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, da niemand weiß, "welche" Daten hier stecken. Wie baut man also eine Data-Lake-Strategie so auf, dass sich das beschriebene Zeitverhältnis für das "undifferentiated heavy lifting and shifting" zu einer günstigeren Relation 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, sobald man sich die Eigenschaften und Anforderungen vor Augen führt, die ein Data Lake erfüllen muss.

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

Zunächst bedarf es einer automatisierten und zuverlässigen Datenaufnahme, auch "Data Ingest" genannt. Wie bekommt man also große Datenmengen sicher effizient und kostengünstig in die Cloud, beziehungsweise 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 zum Beispiel 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:

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 hochskalierbarer auf Verfügbarkeit (99,99999999) ausgelegter Objektspeicher 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.

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 zunehmendem "Alter" der Daten, nimmt üblicherweise die Zugriffsrate ab. Dies geht 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 gelingt das auch aus eigenen Anwendungen in den unterstützten SDKs. Konkret ist jede Amazon S3-Lebenszykluskonfiguration eine XML-Datei. 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:

Das Einrichten einer Lifecyle-Policy per CLI könnten dann zum Beispiel wie folgt aussehen:

wobei "lifecyle.josn" beispielsweise der oben angegebene File sein könnte.

In Python (Boto 3) könnte das Aktivieren der Versionierung samt Lifecycle-Management hingegen folgendermaßen aussehen (wobei in Python eine direkte Verarbeitung von "Malformed XML" möglich ist):

S3 ist also eine gute Basis für den Data Lake – unter anderem auch deshalb, weil zahlreiche Open-Source-Projekte heute native S3-Untersützung bieten und von S3 lesen, ohne dass Daten zuvor in HGFS übertragen werden müssen. Somit bildet AWS S3 die Schlüsseltechnologie, um die geforderte Trennung zwischen Storage und Compute umzusetzen.

Bei Hadoop/HGFS On-Premise müsste man ja zur Erweiterung stets einen vollständigen Knoten, also gleichzeitig Storage und Compute hinzufügen. Im nächsten Teil dieses Workshops werden wir uns ansehen, wie man das Problem des "dummen" Datenspeichers bei S3 mit einem intelligenten Datenkatalog löst. Außerdem zeigen wir, wie Daten in Form von ETL-Prozessen für die Analyse aufbereitet werden können, etwa in einem von AWS automatisiert bereitgestellten Spark-Cluster und der Programmiersprache Scala.

* Diesen Beitrag haben wir von unserem Schwesterportal Dev-Insider übernommen.

(ID:45687923)