Kommentar von Constantin Gonzalez und Ovidiu Hutuleac, AWS Aufbau einer Lake-House-Architektur mit Apache Airflow auf AWS – ein Beispiel

Autor / Redakteur: Constantin Gonzalez und Ovidiu Hutuleac * / Nico Litzel

Eine Big-Data-Plattform ist eine Architektur für Business-Analysen, die alle Komponenten zur Unterstützung von Data Warehousing, Dateneingabe und -verarbeitung in Echtzeit, maschinellem Lernen (ML) und Entwicklung von Künstlicher Intelligenz (KI) umfasst.

Firmen zum Thema

Im Artikel wird aufgezeigt, wie Amazon Managed Workflows für Apache Airflow (AWS MWAA) die Bewegung und Transformation von Daten in einer Lake-House-Architektur auf AWS ermöglicht.
Im Artikel wird aufgezeigt, wie Amazon Managed Workflows für Apache Airflow (AWS MWAA) die Bewegung und Transformation von Daten in einer Lake-House-Architektur auf AWS ermöglicht.
(Bild: © Nmedia - stock.adobe.com)

Hierzu bauen Unternehmen häufig sog. Data Lakes auf, die Daten aus verschiedenen Quellen im Unternehmen zusammenfließen lassen, um diese besser zu sichten, zu verwalten und allen Abteilungen zugänglich zu machen.

Mit einer Lake-House-Architektur auf AWS können Unternehmen Daten in einem Data Lake speichern und speziell entwickelte Datenservices um den Lake herum nutzen. Damit lassen sich Entscheidungen schnell und flexibel in einem Umfang sowie zu einem Preis-Leistungs-Verhältnis treffen, die auf dem Markt unübertroffen sind.

Dieser Artikel zeigt auf, wie Amazon Managed Workflows für Apache Airflow (AWS MWAA) die Bewegung und Transformation von Daten in einer Lake-House-Architektur auf AWS ermöglicht. Im Projektbeispiel wird ein öffentlich verfügbarer GDELT-Datensatz (Global Dataset of Events, Location, and Tone) verwendet, um eingehende Daten aufzunehmen, umzuwandeln und zu analysieren.

Vorteile des Lake-House-Ansatzes

Eine Lake-House-Architektur berücksichtigt die Tatsache, dass ein einheitlicher Ansatz für Analysen letztlich zu Kompromissen führt. Es geht nicht einfach darum, einen Data Lake mit einem Data Warehouse zu integrieren. Vielmehr werden der Data Lake, das Data Warehouse und zweckgebundene Speicher integriert und auf diese Weise eine einheitliche Governance und einfache Datenbewegung ermöglicht. Mithilfe von Amazon MWAA lassen sich Daten in einem Data Lake auf einfache, skalierbare und kostengünstige Weise transformieren und verschieben.

Weitere Informationen zu Lake-House-Architekturen auf AWS finden Sie in den Beiträgen: „Build a Lake House Architecture on AWS“ und „Harness the power of your data with AWS Analytics“.

Es geht nicht einfach darum, einen Data Lake mit einem Data Warehouse zu integrieren. Vielmehr werden der Data Lake, das Data Warehouse und zweckgebundene Speicher integriert und auf diese Weise eine einheitliche Governance und einfache Datenbewegung ermöglicht.
Es geht nicht einfach darum, einen Data Lake mit einem Data Warehouse zu integrieren. Vielmehr werden der Data Lake, das Data Warehouse und zweckgebundene Speicher integriert und auf diese Weise eine einheitliche Governance und einfache Datenbewegung ermöglicht.
(Bild: AWS)

Komplexe Workflows erstellen

Moderne Big-Data-Plattformen benötigen oft komplizierte Daten-Pipelines, die viele interne und externe Dienste miteinander verbinden. Um diese Daten nutzen zu können, lässt sich zunächst ein Workflow erstellen, der eine Reihe von aufeinanderfolgenden Aufgaben zur Vorbereitung und Verarbeitung der Daten definiert. Managed Workflows führen diese Abläufe nach einem Zeitplan oder bei Bedarf aus. Sie lassen sich dabei über eine Web-Benutzeroberfläche oder zentral überwachen.

ETL-Jobs koordinieren (Extrahieren, Transformieren und Laden)

Managed Workflows können als Open-Source-Alternative dienen, um mehrere ETL-Aufträge zu orchestrieren, an denen verschiedene Technologien in einem beliebig komplexen ETL-Workflow beteiligt sind. Sollen beispielsweise die Korrelationen zwischen dem Engagement von Online-Benutzern und den prognostizierten Umsatzerlösen und Verkaufschancen untersucht werden, lassen sich mithilfe von Managed Workflows mehrere AWS Glue-, AWS Batch- und Amazon EMR-Aufträge koordinieren, um die Daten zu kombinieren und für die Analyse vorzubereiten.

Vorbereiten von Daten für maschinelles Lernen

Für das maschinelle Lernen müssen Quelldaten gesammelt, verarbeitet und normalisiert werden, damit ML-Werkzeuge wie der vollständig verwaltete Service Amazon SageMaker auf diesen Daten trainieren können. Managed Workflows lösen dieses Problem, da sich damit die Schritte zur Automatisierung der ML-Pipeline leichter zusammenfügen lassen.

Daten-Pipeline-Beispiel

Im folgenden Beispiel wird die GDELT-Ereignisdatenbank mit Amazon Athena und Amazon Redshift analysiert – siehe Diagramm:

Beispiel: Die GDELT-Ereignisdatenbank wird mit Amazon Athena und Amazon Redshift analysiert.
Beispiel: Die GDELT-Ereignisdatenbank wird mit Amazon Athena und Amazon Redshift analysiert.
(Bild: AWS)

GDELT nutzt eine Reihe hochentwickelter Tools, um Artikel aus der globalen Nachrichtenlandschaft in nahe Echtzeit per Web-Scraping zu extrahieren und die berichteten Ereignisse und ihre Orte zusammen mit einer Fülle anderer Informationen zu kombinieren. Diese Daten werden alle 15 Minuten einem API-Endpunkt zur Verfügung gestellt, von dem sie sich in ihren Data Lake laden lassen. In diesem Beispiel wird AWS MWAA verwendet, um einen Workflow zu erstellen, bei dem die Dateien alle 15 Minuten heruntergeladen und in einem Amazon S3 Bucket im CSV-Format gespeichert werden. Sollte das Abrufen der Dateien fehlschlagen, lässt sich die Workflow-Instanz für die fehlenden Dateien jederzeit erneut ausführen.

MWAA lässt sich sehr gut mit anderen AWS-Diensten integrieren – beispielsweise mit AWS Secrets Manager und AWS Systems Manager Parameter Store. Auf diese Weise werden verschiedene Informationen wie API-Endpunkte, vertrauliche Informationen, Amazon S3-Bucket-Namen und Umgebungsdetails gespeichert. Der DAG-Code (Directed Acyclic Graph) bleibt sauber und lässt sich in mehreren Umgebungen und Projekten über verschiedene Teams hinweg wiederverwenden.

Gleichzeitig wird eine benutzerdefinierte Metrik mit der Anzahl der heruntergeladenen Ereignisse an Amazon CloudWatch gesendet. Diese lässt sich später verwenden, um zu analysieren, wie sich die Anzahl der Ereignisse im Laufe der Zeit entwickelt hat.

Hier ein Bildschirm des Workflows in der Airflow-DAG-Ansichtsseite:

Workflow in der Airflow-DAG-Ansichtsseite
Workflow in der Airflow-DAG-Ansichtsseite
(Bild: AWS)

Sobald die Daten als CSV-Datei in S3 verfügbar sind, beginnt die Konvertierung der Dateien in ein spaltenbasiertes Format – in diesem Beispiel Parquet. Dadurch lässt sich die Leistung beim Lesen mit Amazon Athena und Amazon Redshift Spectrum erhöhen. Nach dem Umwandlungsschritt erfolgt die Vorbereitung der Tabellen für Athena und das Laden in den Redshift Cluster, da diese Aufgaben unabhängig voneinander ausgeführt werden können.

Mit Amazon Athena lassen sich Ad-hoc-Abfragen über die verfügbaren Daten ausführen und Erkenntnisse fast in Echtzeit gewinnen. Mit Redshift werden komplexere Abfragen erstellt und Daten auf mehreren Dimensionen korreliert. So lässt sich beispielsweise abfragen, ob interne Daten oder Tweets zur Verfügung stehen, die zu den Artikeln passen. Zudem lässt sich herausfinden, wie sich Nachrichten und Ereignisse auf die Aufrufe der Website auswirken.

Ein praktisches Beispiel für die Verwendung von Athena zur Abfrage der GDELT-Datenbank findet sich im AWS Serverless DataLake Day Hands-on Lab, das für die Implementierung im Selbststudium verfügbar ist. Die Architektur ermöglicht eine skalierbare Datenanalyse. Jede Komponente im Datenfluss ist in der Lage, mehr Ressourcen hinzuzufügen, wenn die Nachfrage steigt. Auch die Kosten der Architektur sind gut kalkulierbar: Je nach Bedarf lassen sich weitere Ausführungsknoten hinzufügen oder mehr Daten abfragen. Gezahlt wird nur für das, was auch genutzt wird. Die Daten sind langlebig, da sie in S3 gespeichert werden. Bei Bedarf lässt sich zusätzlich eine Replikation des S3-Buckets in einen sekundären Bucket für eine andere Region hinzufügen. Da Amazon MWAA mit vielen Services in AWS integriert ist, lässt sich die Umgebung z. B. mit nativen Sicherheitskontrollen wie Identity Access Management (IAM) und Virtual Private Cloud (VPC) einfach absichern.

Best Practices

Bei der Verwendung von Amazon MWAA zum Aufbau skalierbarer und sicherer Daten-Pipelines haben sich folgende Praktiken und Ressourcen für noch mehr Effizienz bewährt:

  • Verwenden Sie die offizielle Dokumentation zu Apache Airflow Best Practices, um zu erfahren, wie Sie Aufgaben, Variablen und Unit-Tests für Airflow-DAGs (Directed Acyclic Graph) einrichten.
  • In den Security Best Practices for Amazon MWAA erfahren Sie, wie Sie Daten im Ruhezustand und bei der Übertragung schützen, Berechtigungen verwalten und eine mandantenfähige Umgebung überwachen und überprüfen können.
  • Der Troubleshooting Guide enthält häufige Probleme und Fehler, die bei der Verwendung von Amazon MWAA auftreten können, sowie empfohlene Schritte zur Behebung dieser Fehler.
  • Um die Produktivität von Entwicklern zu erhöhen, können Kunden Amazon MWAA lokal ausführen, um eine schnellere Entwicklung und kürzere Testzeiten zu nutzen.
  • Die Airflow-FAQ-Seite bietet viele Antworten auf häufig gestellte Fragen.
  • Im Dezember 2020 hat Apache Airflow eine neue Hauptversion 2.0 veröffentlicht, siehe den Abschnitt „Neue Funktionen“ für Details. Amazon MWAA unterstützt ebenfalls die Version 2.0 seit Mai 2021. Upstream-Kompatibilität ist ein Kernpunkt von Amazon MWAA. Code-Änderungen von AWS an der Airflow-Plattform werden wieder als Open Source freigegeben.

Wie geht es weiter?

Wenn Sie mit Amazon MWAA beginnen möchten, sehen Sie sich den Abschnitt Beispielcode in der Dokumentation an. Bei Amazon MWAA zahlen Sie auf der Grundlage der Umgebungsklasse und der von Ihnen verwendeten Worker. Weitere Informationen finden Sie in der Preisübersicht.

Darüber hinaus können Sie sich an Diskussionen in der Community beteiligen, wiederverwendbare Komponenten auf Github erstellen und AWS Feedback geben, wie Amazon Managed Workflows for Apache Airflow in Ihrem Anwendungsfall funktioniert hat.

* Constantin Gonzalez ist Principal Solutions Architect bei Amazon Web Services (AWS) und Ovidiu Hutuleac ist Solutions Architect bei AWS.

(ID:47697551)