Entwicklung und Test von ETL-Pipelines für AWS lokal

Quellknoten: 997665

Entwicklung und Test von ETL-Pipelines für AWS lokal

Typischerweise erfolgt die Entwicklung und das Testen von ETL-Pipelines in realen Umgebungen/Clustern, was zeitaufwändig in der Einrichtung ist und Wartung erfordert. Dieser Artikel konzentriert sich auf die lokale Entwicklung und das Testen von ETL-Pipelines mit Hilfe von Docker und LocalStack. Die Lösung bietet die Flexibilität, in einer lokalen Umgebung zu testen, ohne Dienste in der Cloud einzurichten.


By Subhash Sreenivasachar, Software Engineer Technical Lead bei Epsilon

Einleitung

 
 
AWS spielt eine entscheidende Rolle dabei, Ingenieuren und Datenwissenschaftlern dabei zu helfen, sich auf die Entwicklung von Lösungen und Problemlösungen zu konzentrieren, ohne sich Gedanken über die Notwendigkeit der Einrichtung einer Infrastruktur machen zu müssen. Mit dem Serverless- und Pay-as-you-go-Ansatz für die Preisgestaltung ermöglicht AWS die einfache Erstellung von Services im laufenden Betrieb.

AWS Glue wird häufig von Dateningenieuren verwendet, um serverlose ETL-Pipelines zu erstellen. PySpark ist einer der am häufigsten für die Entwicklung verwendeten Tech-Stacks. Trotz der Verfügbarkeit von Diensten gibt es jedoch bestimmte Herausforderungen, die angegangen werden müssen.

Das Debuggen von Code in einer AWS-Umgebung, sei es für ETL-Skripte (PySpark) oder einen anderen Dienst, ist eine Herausforderung.

  • Um den Kostenfaktor unter Kontrolle zu halten, ist die kontinuierliche Überwachung der AWS-Servicenutzung von entscheidender Bedeutung
  • AWS bietet zwar Dev Endpoint mit allen installierten Spark-Bibliotheken an, aber angesichts des Preises ist es für große Entwicklungsteams nicht sinnvoll
  • Die Zugänglichkeit von AWS-Diensten kann sein begrenzt für bestimmte Benutzer

Lösung

 
 
Lösungen für AWS können in einer lokalen Umgebung entwickelt und getestet werden, ohne sich Gedanken über Zugänglichkeit oder Kostenfaktoren machen zu müssen. In diesem Artikel gehen wir auf zwei Probleme ein:

  1. Lokales Debuggen von PySpark-Code ohne Verwendung von AWS-Entwicklungsendpunkten.
  2. Lokale Interaktion mit AWS-Services

Beide Probleme können durch die Verwendung von Docker-Images gelöst werden.

  1. Erstens machen wir einen Server in einer AWS-Umgebung überflüssig und stattdessen fungiert ein auf dem Computer ausgeführtes Docker-Image als Umgebung zum Ausführen des Codes.

AWS stellt ein Sandbox-Image bereit, das für PySpark-Skripte verwendet werden kann. Das Docker-Image kann zur Ausführung von PySpark-Code eingerichtet werden. https://aws.amazon.com/blogs/big-data/developing-aws-glue-etl-jobs-locally-using-a-container/
 

  1. Da eine Docker-Maschine zur Ausführung des Codes verfügbar ist, besteht Bedarf an einem Dienst wie S3 zum Speichern (Lesen/Schreiben) von Dateien beim Erstellen einer ETL-Pipeline.

Interaktionen mit S3 können durch ersetzt werden LocalStack Dies bietet ein benutzerfreundliches Test-/Mocking-Framework für die Entwicklung von Cloud-Anwendungen. Es richtet auf Ihrem lokalen Computer eine Testumgebung ein, die dieselben Funktionen und APIs wie die echte AWS-Cloud-Umgebung bietet.

Kopfzeile

Bisher befasst sich der Artikel mit dem Aufbau einer ETL-Pipeline und der Nutzung verfügbarer Dienste. Ein ähnlicher Ansatz kann jedoch an jeden Anwendungsfall angepasst werden, während mit AWS-Diensten wie SNS, SQS, CloudFormation, Lambda-Funktionen usw. gearbeitet wird.

Ansatz

  • Verwenden Sie Docker-Container als Remote-Interpreter
  • Führen Sie eine PySpark-Sitzung für die Container aus
  • Starten Sie den S3-Dienst lokal mit LocalStack
  • Verwenden Sie PySpark-Code zum Lesen und Schreiben aus dem S3-Bucket, der auf LocalStack ausgeführt wird

Die Anforderungen:

 
Die folgenden Tools müssen auf Ihrer Maschine installiert sein

  • Docker
  • PyCharm Professional/VisualStudio-Code

Einrichtung

  • Docker-Images herunterladen oder abrufen (Docker Pull )
    • libs:glue_libs_1.0.0_image_01
    • localstack/localstack
  • Docker-Container können in der professionellen Version von PyCharm als Remote-Interpreter verwendet werden.

Sytemimplementierung

 
Nachdem Docker installiert und die Images auf Ihren lokalen Computer übertragen wurden, beginnen Sie mit der Einrichtung von PyCharm mit Konfigurationen zum Starten der Container.

  • Erstellen Sie eine docker-compose.yml-Datei

https://gist.github.com/subhash-sreenivasachar/526221a4ede6053b1d576e666db8ec87#file-docker-compose-yml

  • Erstellen Sie eine DockerFile

https://gist.github.com/subhash-sreenivasachar/526221a4ede6053b1d576e666db8ec87#file-dockerfile

  • Verwenden Sie die Anforderungsdatei mit den zu installierenden Paketen

https://gist.github.com/subhash-sreenivasachar/526221a4ede6053b1d576e666db8ec87#file-requirements-txt
 

  • Richten Sie den Python-Remote-Interpreter ein
    • Richten Sie den Python-Interpreter mithilfe der Docker-Compose-Datei ein.
    • Wählen Sie „glue-service“ in den PyCharm Docker Compose-Einstellungen.
    • Die Docker-Compose-Datei erstellt die Container für beide Images und führt sie aus
    • LocalStack wird standardmäßig auf Port 4566 ausgeführt und der S3-Dienst ist darauf aktiviert

Code

  • Erforderliche Bibliotheken, die importiert werden müssen

https://gist.github.com/subhash-sreenivasachar/526221a4ede6053b1d576e666db8ec87#file-imports

  • Fügen Sie eine Datei zum S3-Bucket hinzu, der auf LocalStack ausgeführt wird

https://gist.github.com/subhash-sreenivasachar/526221a4ede6053b1d576e666db8ec87#file-add_to_bucket
http://host.docker.internal:4566 ist der S3, der lokal im Docker-Container ausgeführt wird

  • Richten Sie eine PySpark-Sitzung zum Lesen aus S3 ein

https://gist.github.com/subhash-sreenivasachar/526221a4ede6053b1d576e666db8ec87#file-create_pyspark_session

  • Die PySpark-Sitzung stellt über bereitgestellte Schein-Anmeldeinformationen eine Verbindung zu S3 her
  • Sie können direkt aus S3 lesen, indem Sie die erstellte PySpark-Sitzung verwenden

https://gist.github.com/subhash-sreenivasachar/526221a4ede6053b1d576e666db8ec87#file-read_from_s3

  • Schließlich ist es möglich, in jedem bevorzugten Format in S3 zu schreiben

https://gist.github.com/subhash-sreenivasachar/526221a4ede6053b1d576e666db8ec87#file-write_to_s3

Sobald die oben genannten Schritte befolgt wurden, können wir eine Dummy-CSV-Datei mit Scheindaten zum Testen erstellen und Sie sollten damit fertig sein

  • Datei zu S3 hinzufügen (das auf LocalStack läuft)
  • Lesen Sie aus S3
  • Als Parkett an S3 zurückschreiben

Sie sollten in der Lage sein, die .py-Datei auszuführen und eine PySpark-Sitzung zu erstellen, die aus dem S3-Bucket lesen kann, der lokal mithilfe der LocalStack-API ausgeführt wird.

Darüber hinaus können Sie auch überprüfen, ob LocalStack mit ausgeführt wird http://localhost:4566/health

LocalStack bietet Ihnen auch die Möglichkeit, Befehle über AWS CLI auszuführen.

Zusammenfassung

 
 
Die Verwendung von Docker und Localstack bietet eine schnelle und einfache Möglichkeit, Pyspark-Code auszuführen, Container zu debuggen und in S3 zu schreiben, das lokal ausgeführt wird. Und das alles, ohne dass eine Verbindung zu einem AWS-Dienst hergestellt werden muss.

 
References:

 
Bio: Subhash Sreenivasachar ist Lead Software Engineer im Epsilon Digital Experience-Team und entwickelt technische Lösungen zur Lösung datenwissenschaftlicher Probleme, insbesondere der Personalisierung, und trägt dazu bei, den ROI für Kunden zu steigern.

Related:

Quelle: https://www.kdnuggets.com/2021/08/development-testing-etl-pipelines-aws-locally.html

Zeitstempel:

Mehr von KDnuggets