Serverless Spark ETL Pipelines und Orchestrierung mit AWS Glue und Step Functions
Trotz steigender Beliebtheit von Cloud Data Warehouses und neuen Frameworks wie Apache Beam beherrschen seit 2014 Apache Spark Jobs noch viele Prozesse in vielen Unternehmen.
Auch in einem unserer Projekte für unseren Biotech-Kunden Centogene wurde nach einer leichtgewichtigen Lösung für Spark Jobs gesucht, um die zusätzliche Komplexität von Lösungen wie Google Dataproc oder AWS EMR sowie von manchen Orchestrierungstools, zu vermeiden. So fiel die Wahl auf AWS Glue und AWS Step Functions.
AWS Glue
AWS Glue ist ein Serverless ETL Service. Dies bedeutet, dass keine Server für unsere Jobs bereitgestellt werden müssen, der Service vollständig von AWS gemanagt wird, und wir AWS Glue nutzen können, um unsere Daten zu kategorisieren, zu bereinigen, anzureichern und natürlich von A nach B zu bewegen.
Use Cases für AWS Glue sind das Crawlen von Logdateien in S3 und spätere Abfragen mit Athena, das Verknüpfen und Transformieren von Daten aus verschiedenen Quellen sowie das anschließende Laden in Redshift. Auch als zentraler Datenkatalog mit einem Überblick und Verwaltung von verschiedenen Quellen und Nutzung über AWS Services hinweg lässt sich die Technologie einsetzen.
Die Vorteile von AWS Glue ergeben sich nicht nur über nette Features wie z.B. die Job-Bookmarks, sondern vor allem auch durch den fehlende Wartungsaufwand eines Spark Clusters.
Seit Einführung Ende 2017, wurden bei AWS Glue inzwischen nicht nur die Startup-Zeiten der Jobs deutlich reduziert oder die Spark History-Logs einfach zugänglich gemacht, mit AWS Glue Studio wurde zusätzlich die Entwicklungsumgebung deutlich verbessert.
Natürlich gibt es auch Nachteile. Während über den fehlenden internen Speicher gestritten werden kann, kann es durch das dynamische Pricing von AWS Glue schwierig sein, die anfallenden Kosten im Vornherein zu schätzen. Bei größeren Jobs ist es daher wichtig, die vorhandenen Cloudwatch Metriken im Blick zu behalten und die Anzahl der DPUs (Data Processing Units) auch für unsere jeweiligen Jobs anzupassen, um unnötige Kosten zu vermeiden. Im vorliegenden Projekt konnten hierdurch über 90% der bisher entstandenen Kosten eingespart werden.
Wer neben Spark noch auf Presto oder Hive setzt, muss auch weiterhin AWS EMR verwenden. Dies gilt auch für alle, die mehr Kontrolle und Flexibilität über z.B. Art und Größe der verwendeten Instanzen haben möchte.
AWS Step Functions
Workflow Management Tools wurden schon immer benötigt und genutzt. Während sich in den meisten Unternehmen Apache Airflow in den letzten Jahren etabliert hat, gibt es neben Airflow mit Dagster, Prefect oder auch Argo inzwischen weitere interessante Alternativen zur Orchestrierung.
Auch AWS bietet mit den AWS Step Functions einen einfachen und günstigen, sowie gemanagten Service für Workflows an, der durch die vielen Integrationen für AWS Services punkten kann. AWS Step Functions bieten uns einen visuellen Workflow Editor, vorrangig um Anwendungen zu bauen und Prozesse zu automatisieren, aber eben auch, um Daten- und ML Pipelines zu betreiben.
Neben der Einfachheit ist hervorzuheben, dass mit AWS Step Functions die Anwender:innen gezwungen werden, zwischen Orchestrator und Runtime zu unterscheiden. D.h. Tasks werden lediglich getriggert, die Exekution der Jobs übernimmt dann der jeweilige Service.
Wer schon einmal verschiedenste Workloads und Libraries auf Apache Airflow Workern balancieren musste, kennt die Kopfschmerzen, die dies mit sich bringt und weiß die erzwungene Trennung sofort zu schätzen.
Die Einfachheit im Aufsetzen bringt auch Limitationen mit sich. Backfills über vergangene Monate sind über den gleichen Workflow genauso wenig möglich, wie das erneute Starten von einzelnen Tasks. Mit Helfern, wie z.B. einem „GoToState“ Filter zu Beginn des Workflows, können diese Probleme jedoch gelindert werden.
Fazit
Sowohl AWS Glue, als auch die AWS Step Functions bieten sehr gute und einfache Lösungen, um ETL Pipelines in Apache Spark mit minimalem Overhead in AWS zu erstellen und zu verwalten.
Um nicht später den Überblick über viele Skripte zu verlieren, bietet sich das Bündeln der Spark Jobs in einer eigenen Python Library an. So kann Code nicht nur effizient wiederverwendet werden, auch die Jobs können einfach und einheitlich gestartet werden, unabhängig vom eingesetzten Workflow Tool als Orchestrator.
Markus Nutz
Data Scieneer