ETL vs. ELT
Voor het laden van data naar een Data Warehouse worden sinds jaar en dag zo genoemde ETL (Extract - Transform - Load) tools gebruikt. Sinds enige jaren wordt er ook gesproken over ELT (Extract - Load - Transform). Dit artikel gaat over de vraag: wat is het verschil tussen beide concepten en welke hiervan is beter?
Extract - Transform - Load
ETL tools bieden over het algemeen een visuele manier om laad processen te ontwikkelen. De tools hebben connectoren voor gangbare database en bestandsformaten. Daarnaast hebben deze tools bouwblokken om data transformaties uit te voeren, zoals: aggregaties, joins, calculaties, etc. Door brontabellen , doeltabellen en transformatieblokken op een canvas te slepen en te verbinden met elkaar, kunnen op een gebruiksvriendelijke manier laadprocessen worden ontwikkeld. Deze processen kunnen vervolgens worden uitgevoerd door de ETL engine. Een ETL proces doet in grote lijnen hetvolgende: brondata wordt uit 1 of meer bronsysteem geladen in het geheugen van de engine (Extract stap) vervolgens worden in diezelfde engine meerdere transformaties uitgevoerd (Transform stap), waarna het resultaat wordt weggeschreven naar 1 of meerdere doelsystemen (Load stap).
Extract - Load - Transform
Het ELT mechanisme gaat uit van een ander principe. Hierbij wordt brondata geladen vanuit de bron (Extract) 1 op 1 weggeschreven naar een doeldatabase (Load). Vervolgens vinden alle transformaties plaats binnen deze doel database. Dit zou bijvoorbeeld kunnen gebeuren middels SQL commando's. Dit alles heeft een aantal voordelen:
- Databases (en met name Data Warehouse databases) zijn heel goed in staat om data snel te transformeren.
- Het feit dat alle data zich al binnen de database bevindt zorgt voor extra snelheid
- Het feit dat zowel de ruwe brondata als het eindresultaat aanwezig is binnen de database, maken controles achteraf en bijvoorbeeld debuggen eenvoudiger.
Het verschil tussen ETL en ELT niet 100% eenduidig. Zo hebben ETL tools soms ook de optie om ELT code te genereren, middels een z.g. pushdown optie. Hierbij worden de transformaties door de ETL tool vertaald naar SQL code, welke volledig op de doeldatabase worden uitgevoerd. De ETL tool genereert in dat geval gewoon ELT code. De term ELT wordt ook gebruikt bij het laden van Data Lake of Data Lakehouse architecturen. Binnen deze architecturen, is er standaard al sprake tussen een scheiding tussen Storage en Compute. De ELT code wordt binnen deze architecturen bijvoorbeeld uitgevoerd door een Spark cluster, wat eigenlijk gewoon gezien kan worden als een ETL Engine. Binnen Moderne Data Warehouse databases in de cloud is tegenwoordig ook vaak een scheiding tussen Opslag en Compute, met het oog op schaalbaarheid. Het argument dat data al op de juiste plek aanwezig is bij ELT, gaat daarmee niet meer op.
Conclusie
De keuze tussen ETL en ELT gaat eigenlijk niet alleen over de plaats van de T (Transformatie) binnen de ETL/ELT datafow. Zoals eerder duidelijk werd is de plaats niet meer zo eenduidig door de komst van Moderne Datawarehouse architecturen. Er zijn wel andere aspecten die belangrijk zijn en enigszins samen hangen met de keuze tussen ETL en ELT. Deze worden hieronder beschreven.
Code vs. No-Code of Low-Code
De klassieke ETL tools maken meestal gebruik van een visuele design interface. Dit soort tools wordt tegenwoordig aangeduid als Low-Code of No-Code tools. Bij ELT wordt doorgaans code geprogrammeerd, bijvoorbeeld in SQL, Python of Scala. Programmeertalen bieden enderzijds meer mogelijkheden qua automatisering en hergebruik van code. Aan de andere kant vereist dit wel een bepaald kennisniveau van de personen die ontwikkelen en beheren. Visuele tools zijn makkelijker te begijpen door minder technische personen. Dit voordeel kan een nadeel worden omdat minder technische personen doorgaans minder efficiente en minder robuuste programmatuur ontwikkelen.
Open standaarden vs. Leverancier gebonden standaarden
Visuele ETL tools hebben doorgaans een eigen engine die een eigen formaat job definities verwerkt. Een ETL job die gebouwd is in de ene ETL tool kan niet zomaar worden omgezet naar een andere ETL tool. Het migreren van ETL naar een andere tool vereist dus een uitgebreid tijdrovend migratietraject met veel herdesign en herbouw activiteiten. ELT maakt veel gebruik van SQL of andere script talen. SQL is redelijk gestandaardiseerd en kan zonder al te veel moeite worden gemigreerd van het ene naar het andere database platform. Veel voor ELT gebruikte talen (zoals Python en Scala) kunnen draaien op allerlei data platforms. Door bij het bouwen van laadprocessen gebruik te make van open standaarden, worden dus allerlei Lock-in situaties voorkomen.
Kortom er zijn wat voordelen aan de laadmethodiek die als ELT bekend staat. Dit betreft met name de voordelen van open standaarden en de efficientie van programmeertalen. De Low-Code of No-Code aard van klassieke ETL tools is wellicht iets laagdrempeliger voor niet-technische ontwikkelaars.
Reacties