Tech talk: kan ETL in de cloud zonder programmeren? (deel 3)
In dit laatste deel van mijn Tech Talk (hier deel 1 en deel 2) beschrijf ik onze AWS-ervaring met een ETL-project voor een klant in digitale marketing. De behoefte aan een datawarehouse ontstond door groeiende datavolumes en complexiteit. Aanvankelijk merkte ik dat data uit verschillende bronnen in Tableau samenvoegen (blending) zeer traag reagerende dashboards opleverde. We hadden een andere oplossing nodig.
Voor onze toepassingen waren er twee databronnen: een PostgreSQL-database in de AWS-cloud en Google BigQuery met analyticsdata. De klant heeft cloudervaring en beheerst goede DevOps-praktijken zoals Infrastructure as Code (IaC). De leverancier lag vast. Wij moesten alleen nog de ETL-tool kiezen. We overwogen AWS Glue of in Python geschreven Lambda-functies, aangestuurd door Step. De datacatalogus trok ons over de streep voor Glue.
Bron: https://medium.com/nerd-for-tech/export-oracle-database-to-postgresql-using-aws-glue-551860965c58
Extractie (ETL)
Glue is in wezen een beheerd Spark-cluster. Volgens AWS is het ‘serverless’, omdat u behalve het aantal nodes geen details instelt. Met Glue Studio kunt u ETL-stromen zonder code bouwen, maar daar kom ik op terug. Zoals in de vorige artikelen beschreven, is extractie de eerste ETL-stap. Daar doken de eerste problemen op en bleek Glue helaas nog in de kinderschoenen te staan.
In Glue zijn er crawlers die databases scannen en alle tabellen met hun metadata oplijsten. Daarna kunt u de gewenste tabellen extraheren. Helaas herkennen crawlers alleen tabellen, geen gematerialiseerde views. Die bevatten bepaalde filters en kwamen veel voor in de PostgreSQL-inrichting van de klant. Dat was geen groot probleem: we konden met de ruwe tabellen werken.
Het tweede probleem betrof de BigQuery-verbinding. Die connector is niet standaard beschikbaar: u moet hem downloaden via Amazons marketplace. Dat heeft twee gevolgen. Ten eerste kunt u Google-databases niet crawlen en moet u dus tabelnamen en databaseschema's kennen. We losten dat op door de gewenste tabellen naar S3-buckets te kopiëren en daarop de crawler te draaien. Ten tweede kunt u deze connector niet opnieuw aanmaken met IaC-tools zoals Terraform. Volledig automatische uitrol van de infrastructuur is dus onmogelijk. Er is een menselijke tussenkomst nodig.
Transformatie (ETL)
Glue gebruikt een PySpark-dialect. In plaats van dataframes krijgt u dynamic frames die kolomtypes als lijst aanvaarden. In theorie is er ook een interface voor ETL zonder code. Volgens mijn ervaring biedt AWS echter heel weinig transformaties: joins, basisaggregaties, select en een beperkte filter. Berekende velden maken kan bijvoorbeeld niet. Er is een blok voor eigen code, maar dat is omslachtig omdat u de (dynamic) dataframes niet kunt debuggen of vooraf bekijken. Ik verloor een paar dagen voordat ik besefte dat ik met deze tool niets kon ontwikkelen.
Hoe dan wel? Met 100% code! Eerst maakt u development endpoints aan. Dat vraagt twee stappen en telkens zo'n 20 minuten. Zelfs de opstarttijd wordt aangerekend! Op basis daarvan maakt u een SageMaker-notebook aan, vergelijkbaar met Jupyter Notebooks of Google Colab. Pas daar kunt u productief werken. Een goede aanpak is basiscode genereren met alle imports en het aanmaken van Glue- en Spark-contexten. De notebook is gebruiksvriendelijk: u kunt code debuggen en variabelen en dataframes bekijken. Wie met Databricks werkte, begrijpt wat ik bedoel.
Laden (ETL)
De derde en laatste stap is laden. Net als vorige keer moesten we verschillende dimensie- en feitentabellen in Parquet-formaat in het datawarehouse laden, een andere PostgreSQL-database. Net als bij Azure konden we belangrijke laadopties niet instellen, zoals tabellen leegmaken, verwijderen of overschrijven. Daarom voerden we de PySpark-laadscripts met een JDBC-driver handmatig uit.
Samenvatting
Zowel Azure Data Factory als AWS Glue bleken beperkt als ETL-oplossingen zonder code. Misschien kan het ooit, maar begin 2022 was het geen optie. In de ETL-wereld moet u zelf programmeren!