Tech Talk: Is ETL in de cloud mogelijk zonder codering (deel 3)?
In dit laatste deel van mijn Tech Talk(deel 1 en deel 2 hier), wil ik de AWS-ervaring beschrijven met een ETL-project voor een klant in de digitale marketingindustrie. De behoefte aan een Data Warehouse kwam voort uit het groeiende datavolume en de toenemende complexiteit. Aanvankelijk vond ik dat het samenvoegen van gegevens uit verschillende bronnen in Tableau (blenden) resulteerde in zeer traag reagerende dashboards. We hadden een andere oplossing nodig.
Er waren twee gegevensbronnen voor de use cases waaraan we werkten: een PostgreSQL-database gehost in de AWS-cloud en Google BigQuery met analysegegevens. De klant heeft ervaring met de cloud en is bedreven in een aantal goede DevOps-praktijken zoals Infrastructure as Code (IaC). Toen de leverancier geselecteerd was, hoefden we alleen nog maar een beslissing te nemen over de ETL-tool. De twee opties die we overwogen waren: AWS Glue of Lambda functies geschreven in Python getriggerd door Step. Verleid door de functionaliteit van de datacatalogus kozen we voor Glue.
Extractie (ETL)
Glue is in essentie een beheerd Spark cluster. Volgens de AWS terminologie is het 'serverloos' omdat je geen andere details hoeft in te stellen dan het aantal nodes. Met Glue Studio kun je no-code ETL flows maken, maar daar zal ik verder op ingaan. Zoals beschreven in de vorige artikelen, is de eerste stap in ETL extractie. Dit deel is waar de eerste problemen opdoken en Glue heeft helaas bewezen dat het nog in de kinderschoenen staat.
In de Glue-omgeving zijn er zogenaamde crawlers die databases kunnen scannen om een lijst te maken van alle tabellen en de bijbehorende metadata. Vervolgens kun je de gewenste tabellen extraheren. Helaas kunnen de crawlers alleen tabellen herkennen en geen materialized views, die bepaalde filters bevatten en veel voorkomen in de PostgreSQL setup van de klant. Het was geen groot probleem; we konden werken met de ruwe tabellen.
Het tweede probleem was met de BigQuery verbinding. Deze connector is standaard niet beschikbaar. Je moet hem downloaden van Amazon's marktplaats. Dit heeft twee gevolgen. Ten eerste kun je geen databases van Google crawlen, dus je moet de tabelnamen en databaseschema's kennen. We hebben het opgelost door de gewenste tabellen naar S3 buckets te kopiëren en de crawler erover te laten lopen. Ten tweede kun je deze connector niet opnieuw maken met IaC-tools, zoals Terraform. Dit betekent dat een volledig geautomatiseerde implementatie van de infrastructuur onmogelijk is. Er is een menselijke operator nodig.
Transformatie (ETL)
Glue gebruikt een PySpark-dialect. In plaats van dataframes heb je dynamische frames die kolomtypes accepteren als een lijst. In theorie is er ook een UI ontworpen om ETL uit te voeren zonder code. Uit mijn ervaring blijkt dat het aantal transformaties dat AWS biedt minimaal is. Je hebt joins, basisaggregaties, select en een beperkt filter. Er is bijvoorbeeld geen mogelijkheid om berekende velden te maken. Je hebt een custom code block, maar het gebruik ervan is erg omslachtig omdat je je data niet kunt debuggen/bekijken in (dynamische) frames. Ik was een paar dagen kwijt voordat ik me realiseerde dat ik niets kon ontwikkelen met deze tool.
Hoe doe je dat? 100% code! Eerst moet je zogenaamde development endpoints maken. Het is een activiteit in 2 stappen die elke keer zo'n 20 minuten in beslag neemt. Ze brengen zelfs de tijd in rekening tijdens het lanceren! Op basis van dev eindpunten maak je een Sagemaker notebook (vergelijkbaar met Jupyter Notebooks of Google Colab), en alleen daar kun je iets productiefs doen. Een uitstekende manier is om wat boilerplate code te genereren met alle imports en het aanmaken van Glue en Spark contexten. Het notitieboek is gebruiksvriendelijk en stelt je in staat om je code te debuggen door variabelen en dataframes te bekijken. Als je met Databricks hebt gewerkt, weet je wat ik bedoel.
Belasting (ETL)
De derde en laatste stap is Laden. Net als de vorige keer was het de taak om verschillende dimensie- en feitentabellen opgeslagen in het parketformaat in het datawarehouse te plaatsen, een andere PostgreSQL database. Net als bij de Azure-oplossing kunnen we geen belangrijke opties voor het laden definiëren, zoals truncating/dropping/overwriting van tabellen. Hierdoor moesten we de Pyspark-scripts voor het laden met een JDBC-driver handmatig toepassen.
Samenvatting
Zowel Azure Data Factory als AWS Glue bleken beperkte oplossingen te zijn die geen ETL-tools in code bieden. Misschien wordt het ooit mogelijk, maar vanaf begin 2022 is het geen optie. In de ETL wereld zul je je handen vuil moeten maken met coderen!
