Als je een datapijplijn bouwt om een business intelligence-tool te voeden of een machine-learningmodel te trainen, is een van de eerste beslissingen die je moet nemen waar de transformatie plaatsvindt: voordat de gegevens in jouw warehouse belanden of daarna. Dit betekent dat je moet kiezen tussen extract, transform, load- (ETL) en extract, load, transform-pijplijnen (ELT).

De keuze bepaalt hoe snel analisten toegang hebben tot ruwe gegevens, hoeveel rekenkracht je waar besteedt en hoe makkelijk je je kunt aanpassen wanneer jouw gegevensmodel verandert. De markt voor wereldwijde datapijplijntools is naar verwachting $ 48,33 miljard waard tegen 2030, en ETL verliest terrein aan ELT en andere soorten pijplijnen.

Hieronder bespreken we hoe elk model werkt, wanneer ETL of ELT zinvoller is, en hoe speciaal gebouwde connectors binnen beide benaderingen passen voor specifieke gegevensbronnen.

Hoogtepunten

• ETL transformeert gegevens voordat ze de bestemming bereiken. ELT laadt ruwe gegevens en transformeert ze in het warehouse met gebruik van de eigen rekenkracht.

• ELT is het standaardpatroon voor de meeste moderne datateams. ETL blijft populair voor beperkte bestemmingen, strikte governance-vereisten en legacy-pijplijnen.

• Speciaal gebouwde connectors voor specifieke gegevensbronnen kunnen het risico op problemen met de gegevenskwaliteit verminderen die generieke connectors soms veroorzaken.

ETL- vs. ELT-pijplijnen: het verschil

ETL staat voor 'extract, transform, load' (extraheren, transformeren, laden). In een ETL-model haal je data uit een bronsysteem, voer je dit door een transformatielaag die opschoont, hervormt en filtert, en vervolgens laad je het verwerkte resultaat naar een bestemming, zoals een datawarehouse of datamart.

Met ETL doet een afzonderlijke verwerkingsengine het zware werk voordat de data de bestemming bereikt. Het warehouse ontvangt gestructureerde data die gereed is voor een query, in plaats van de ruwe bronrecords. Opnieuw verwerken vanuit de bron betekent ofwel opnieuw extraheren of ergens anders een afzonderlijke ruwe kopie onderhouden.

ELT, wat staat voor 'extract, load, transform' (extraheren, laden, transformeren), draait de laatste twee stappen om. Ruwe data belandt eerst op de bestemming, en vervolgens worden de transformaties in het warehouse uitgevoerd met behulp van de eigen rekenkracht.

Die verschuiving werd praktisch toen cloud-datawarehouses het goedkoop en snel maakten om SQL-transformaties (Structured Query Language) over grote datasets uit te voeren. In plaats van een afzonderlijke transformatie-engine tussen de bron en bestemming, is je warehouse de transformatieomgeving.

Hoe ETL werkt

Een ETL-pijplijn draait in drie fasen, elk met een eigen verantwoordelijkheid.

Zo werkt ETL:

• Extraheren: Een connector of opnametaak haalt data uit de bron, zoals een database, een API (Application Programming Interface) voor betalingen, een SaaS-platform (Software-as-a-Service) of een flat file. Deze stap behandelt authenticatie, paginering, incrementele logica versus de logica voor volledig vernieuwen en frequentielimieten.

• Transformeren: De geëxtraheerde data verplaatst zich naar een verwerkingslaag waar het wordt opgeschoond (bijv. nulls verwerkt, typen geconverteerd), hervormd (bijv. joins, aggregaties, kolommen hernoemen), gefilterd en soms verrijkt met referentiedata uit andere bronnen.

• Laden: De verwerkte dataset laadt naar de bestemming als een volledige overschrijving, een upsert of een toevoeging, afhankelijk van hoe de pijplijn is geconfigureerd.

In deze specifieke situaties is het gebruik van ETL nog steeds zinvol:

• Beperkte bestemmingen: Oudere datawarehouses of systemen op locatie met beperkte rekenkracht kunnen grote transformaties niet efficiënt ter plekke uitvoeren, waardoor het laden van vooraf getransformeerde data de enige realistische optie is.

• Strikte vereisten voor beheer: Sommige organisaties moeten ervoor zorgen dat persoonsgegevens of gevoelige financiële data nooit in ruwe vorm in het warehouse belanden. Het stroomopwaarts transformeren en maskeren voldoet architectonisch aan die vereiste.

• Edge-omgevingen: IoT-systemen (Internet of Things) en ingebedde systemen die data naar de centrale infrastructuur pushen, kunnen vaak geen grote ruwe payloads verzenden. Dit maakt lokale transformatie vóór transmissie een praktische noodzaak.

• Technische schuld van legacy-pijplijnen: Veel volwassen organisaties hebben ETL-pijplijnen die al jarenlang betrouwbaar draaien. Het ombouwen hiervan naar ELT brengt een risico met zich mee dat mogelijk niet de moeite waard is.

Hoe ELT werkt

ELT-pijplijnen extraheren en laden ruwe of licht geformatteerde brondata direct naar de bestemming. Transformaties worden daarna uitgevoerd, geactiveerd volgens een schema of op aanvraag, met de eigen rekenkracht van het warehouse.

Een connector kan bijvoorbeeld data uit een bron extraheren en deze wegschrijven naar een ruw schema in je warehouse. Een analytics-engineer schrijft data build tools-modellen (dbt) die uit dat ruwe schema lezen, bedrijfslogica toepassen en opgeschoonde tabellen maken waarop business intelligence-tools (BI) een query kunnen uitvoeren. Wanneer de logica moet veranderen, werkt de engineer het model simpelweg bij en voert het opnieuw uit met de al aanwezige data.

ELT is om deze redenen een slimme keuze:

• Snellere toegang tot ruwe data: Data belandt snel in het warehouse, zodat teams kunnen beginnen met het verkennen en valideren ervan voordat de transformatielaag af is.

• Goedkopere verbeteringen: Een transformatie wijzigen in ETL betekent vaak het aanpassen van een pijplijn, opnieuw verwerken en opnieuw laden. Bij ELT werk je gewoon een SQL-model bij en voer je dit opnieuw uit met data die je al hebt.

• Rekenkracht op warehouseniveau: Cloudwarehouses zijn gebouwd om grote datasets snel te verwerken, wat betekent dat je serieuze rekenkracht toepast op de transformatie in plaats van onafhankelijk een afzonderlijke middlewarelaag te laten groeien.

• Volledige ruwe geschiedenis: Omdat de ruwe data altijd in het warehouse staat, kun je elke downstreamtabel helemaal opnieuw afleiden. Dit is belangrijk wanneer definities voor je onderneming veranderen of wanneer je een datakwaliteitsprobleem moet debuggen.

Hoe kies je tussen ETL en ELT?

Grote organisaties voeren beide gegevensverwerkingsmodellen doorgaans parallel uit voor verschillende bronnen. De behoeften van jouw organisatie helpen je bij de beslissing welke methode het meest geschikt is.

Hier moet je rekening mee houden.

Datavolume en -snelheid

Hoogfrequente data in grote volumes zijn doorgaans meer gebaat bij een ELT-datapijplijn. Cloudwarehouses kunnen dit goed aan, en de kosten van het stroomopwaarts uitvoeren van een zware transformatie-engine lopen snel op. Daar staat tegenover dat je computerrekening voor het warehouse stijgt bij zware transformaties en dat het opslaan van ruwe data kosten met zich meebrengt.

Pijplijnen met een kleiner volume met een stabiele, goed gedefinieerde transformatielogica kunnen zonder veel moeite op ETL blijven.

Transformatie-eigendom

Als jouw transformaties SQL-gebaseerd zijn en in handen zijn van analytics engineers die zich snel moeten aanpassen, is ELT met dbt of een vergelijkbare tool waarschijnlijk de beste keuze.

Als jouw transformaties in Python of Java zijn gecodeerd en in handen zijn van een data engineering-team, past ETL mogelijk van nature in jouw bestaande toolchain.

Toegang tot ruwe data

Als analisten toegang nodig hebben tot ruwe brondata (bijv. voor ad-hoc-verkenning, auditing of omdat de transformatielogica nog in ontwikkeling is), is ELT de betere standaardoptie. ETL-pijplijnen die geen ruwe data bewaren, maken het moeilijk om dergelijke toegang achteraf in te bouwen.

Governance en compliance

Als specifieke data gemaskeerd of geanonimiseerd moeten worden voordat ze een gedeelde bestemming bereiken, biedt ETL je architecturale handhaving van deze vereiste.

ELT kan aan veel van dezelfde vereisten voldoen door middel van beveiliging op kolomniveau en toegangscontroles op warehouseniveau, maar de implementatie verschilt en is de moeite waard om te toetsen aan jouw complianceverplichtingen.

Teamworkflow

Een team dat zeer bedreven is in SQL en gewend is aan versiebeheer rondom dbt, haalt meer waarde uit een ELT-opstelling dan uit het onderhouden van een aangepaste ETL-pijplijn die het niet zelf heeft gebouwd. De compatibiliteit met de manier waarop jouw team werkt, is een legitieme factor.

Hoe dataconnectors in ETL- en ELT-pijplijnen passen

Algemene ETL- en ELT-tools verwerken een breed scala aan bronnen via configureerbare connectors. Die breedte is handig, maar brengt compromissen met zich mee.

Payments-data is een goed voorbeeld. Het datamodel van Stripe dekt events, afschrijvingen, terugbetalingen, geschillen, saldotransacties, klanten, abonnementen en facturen. Een generieke connector die de API-versies van Stripe niet bijhoudt of die incrementele synchronisatielogica verkeerd verwerkt, kan fouten produceren die moeilijk op te sporen zijn totdat ze van invloed zijn op een dashboard of financiële reconciliatie.

Stripe Data Pipeline pakt dit direct aan:

• Gebouwd en onderhouden door Stripe: Omdat Stripe eigenaar is van de connector en de interne Stripe-infrastructuur direct weerspiegelt, kun je data continu en betrouwbaar synchroniseren en tegelijkertijd volledigheid en nauwkeurigheid garanderen – ongeacht de hoeveelheid data die je hebt en zonder API-frequentielimieten.

• Directe warehouse-synchronisatie: Data verplaatst zich naar Amazon Redshift, Snowflake, Databricks en meer, zonder routing via een externe connector, waardoor gevoelige financiële data buiten extra leveranciersinfrastructuur blijft.

• Complete Stripe-dataset: De synchronisatie dekt Stripe-objecten, vooraf gebouwde financiële rapporten en gecureerde datasets om analyse en rapportage te versnellen.

• Lichtgewicht configuratie: De verbinding is geconfigureerd in het Stripe-dashboard, er is geen code vereist. Als je al ELT-pijplijnen uitvoert voor andere bronnen, volgt de Stripe-data hetzelfde patroon.