Datapipelines volgden vroeger een strikte volgorde: data uit bronsystemen ophalen, transformeren naar een schone, gestructureerde indeling en vervolgens het voltooide product laden in een database. Die volgorde (extract, transform, load, oftewel ETL) was logisch toen opslag duur was en doelsystemen niet krachtig genoeg waren voor zware berekeningen.

Maar cloudwarehouses hebben dit allemaal veranderd en ELT (extract, load, transform) is het patroon geworden dat veel analyseteams nu standaard gebruiken. Hoewel traditionele ETL een marktaandeel van bijna 40% behoudt, verliest het snel terrein aan andere typen datapipelines, zoals ELT.

Hieronder bespreken we wat ELT is, hoe het werkt en waar het wel en niet geschikt voor is.

Hoogtepunten

• Een ELT-procedure (extract, load, transform) laadt eerst ruwe data in een cloudwarehouse en transformeert deze vervolgens. Dit geeft analisten snellere toegang tot data en meer flexibiliteit om modellen te verbeteren.

• Cloudwarehouses zijn zeer geschikt voor ELT omdat ze opslag en rekenkracht scheiden, elastisch groeien en analisten in staat stellen transformatielogica te schrijven in Structured Query Language (SQL).

• Werken met een betalingsprovider die direct naar het warehouse synchroniseert zonder routing via de infrastructuur van derden, vermindert de complexiteit van de pipeline en de blootstelling aan beveiligingsrisico's.

Wat is ELT en hoe werkt het?

ELT (extract, load, transform) is een data-integratiepatroon dat is opgebouwd rond drie stappen: data uit bronsystemen extraheren, deze ruw laden in een centrale bestemming en deze vervolgens transformeren in de bestemming voor analyses, rapportages of machine-learning.

Zo verloopt een typische ELT-workflow in de praktijk:

• Extract: Een connector of pipeline-job haalt records uit een bronsysteem (incrementeel, volgens een schema of getriggerd door gebeurtenissen) en schrijft ze naar de bestemming in hun oorspronkelijke structuur.

• Load: Ruwe tabellen landen in het warehouse, vaak in een specifiek schema, waarbij veldnamen, datatypen en relaties precies behouden blijven zoals ze in de bron bestonden.

• Transform: Transformatielogica draait binnen het warehouse, aangezien SQL-gebaseerde tools, zoals de data build tool (dbt), teams in staat stellen versies van die modellen te beheren, ze te testen en datasets te bouwen bovenop de ruwe laag.

Omdat ruwe data als eerste binnenkomt, kunnen analisten er onmiddellijk query's op uitvoeren en kunnen meerdere downstream-weergaven worden gebouwd vanuit een enkele bron zonder opnieuw te hoeven extraheren. Als een transformatiemodel onjuist is, herschrijf je het en voer je het opnieuw uit op de data die al in het warehouse staat.

Hoe verschilt ELT in de praktijk van ETL?

Het belangrijkste architectuurverschil tussen ETL en ELT is waar de transformatie plaatsvindt: buiten de bestemming in ETL, binnen de bestemming in ELT.

Dit zijn de grootste verschillen tussen ETL en ELT:

• Beschikbaarheid van data: In een ETL-pipeline kan data niet worden opgevraagd totdat deze is getransformeerd en geladen. Bij ELT wordt de ruwe data eerst opgeslagen, zodat analisten ermee kunnen werken terwijl transformatie-jobs afzonderlijk worden uitgevoerd.

• Verbeteringssnelheid: Het wijzigen van een transformatie in een ETL-pipeline betekent vaak het opnieuw opbouwen van de pipeline zelf. In ELT werk je een SQL-model bij en voer je het opnieuw uit op data die al in het warehouse staat.

• Waar de rekenkracht zich bevindt: ETL-transformaties draaien op de pipeline-infrastructuur (een afzonderlijke server of service die je daarvoor inricht). ELT-transformaties draaien op de rekenkracht van het datawarehouse, dat elastisch groeit en waarvoor al is betaald.

• Behoud van ruwe data: ETL verwijdert doorgaans tussenliggende statussen zodra de getransformeerde uitvoer is geproduceerd. ELT behoudt de ruwe laag standaard, wat betekent dat je historische data opnieuw kunt verwerken als de vereisten veranderen.

Waarom past ELT bij moderne cloud-datawarehouses?

De volgende eigenschappen maken ELT een logische keuze voor cloudwarehouses:

• Gescheiden opslag en rekenkracht: Bij platforms zoals Snowflake en BigQuery betaal je apart voor het opslaan van gegevens en het opvragen ervan. Je kunt zoveel ruwe gegevens opslaan als je wilt, en transformatietaken verbruiken alleen rekenkracht wanneer ze worden uitgevoerd.

• Elastisch schalen: Je kunt de benodigde rekenkracht creëren, de taak uitvoeren en deze weer verminderen. Het warehouse regelt de parallellisatie.

• Kolomgebaseerde opslag: Cloudwarehouses slaan gegevens op in kolomformaat, wat analytische query's (aggregaties, filters, joins over grote datasets) aanzienlijk sneller maakt dan rijgebaseerde opslag.

• SQL-native: De meeste analisten en analytics-engineers kennen SQL al. Het uitvoeren van transformaties binnen het warehouse betekent dat de mensen die de bedrijfslogica begrijpen, de transformatiemodellen rechtstreeks kunnen schrijven en beheren.

Wanneer is ELT een goede keuze?

ELT is niet de juiste oplossing voor elke datapipeline, maar het past bij een herkenbare reeks voorwaarden.

In deze gevallen werkt ELT doorgaans goed:

• Grote of snelgroeiende datasets: Als je miljoenen gebeurtenissen per dag synchroniseert, vereist het uitvoeren van transformaties vóór het laden een aanzienlijke pipeline-infrastructuur. Het opslaan van ruwe data en het transformeren in het warehouse is praktischer op grote schaal.

• Vaak veranderende transformatielogica: Als transformaties in het warehouse staan als SQL-modellen, vereist het bijwerken van analysevereisten niet het opnieuw implementeren van de pipeline-infrastructuur.

• Meerdere downstream-toepassingen: Ruwe data in het warehouse kan tegelijkertijd een business intelligence-dashboard, een machine-learning-kenmerkopslag en een operationeel rapport voeden. Je bouwt één pipeline en modelleert de data anders voor elke gebruiker.

• Teams met opties voor analytics-engineering: ELT verschuift het eigendom van transformatie naar de analyselaag. Teams die tools zoals dbt gebruiken, zijn hier bij uitstek geschikt voor.

ELT is in de volgende omstandigheden geen goede keuze:

• Regelgevingsbeperkingen op ruwe data: Sommige omgevingen voor gezondheidszorg en financiële data verbieden het opslaan van gevoelige data voordat deze wordt gemaskeerd of gefilterd. In die gevallen moeten transformaties upstream plaatsvinden.

• Rigide doelschema's: Als je bestemming geen ruwe of semigestructureerde data aankan, zorgt de load-first-benadering van ELT voor meer problemen dan het oplost.

• Kleine, stabiele datasets: Als een eenvoudige ETL-pipeline volstaat, is het toevoegen van transformatie-infrastructuur in een warehouse extra werk zonder veel voordeel.

Welke uitdagingen brengt ELT met zich mee?

Ruwe data opslaan in een warehouse is krachtig, maar kan governance- en kostenuitdagingen met zich meebrengen.

Houd rekening met deze mogelijke uitdagingen van ELT.

Toegangscontrole

Ruwe tabellen bevatten vaak data die niet breed toegankelijk mag zijn, zoals persoonsgegevens (PII), financiële gegevens of interne ID's. In ETL kunnen gevoelige velden worden gemaskeerd of verwijderd voordat data de bestemming bereikt. Maar in ELT wordt de data eerst opgeslagen. Zonder beveiliging op rijniveau, kolommaskering of strak afgebakende warehouse-rollen kunnen analisten query's uitvoeren op velden die ze niet zouden mogen zien.

Datakwaliteit

Slechte data van upstream-bronnen belandt in het warehouse voordat er controles worden uitgevoerd. Null-velden, dubbele records, schemawijzigingen en type-mismatches kunnen zich verspreiden naar downstream-modellen als je geen kwaliteitstests inbouwt in de transformatielaag met het testframework van dbt of de eigen datakwaliteitsfuncties van het warehouse.

Kostenbeheer

Transformatie-jobs draaien op de rekenkracht van het warehouse en slecht geschreven SQL (zoals onbegrensde scans, ontbrekende partitiefilters of overbodige vernieuwingen van de hele tabel) kunnen aanzienlijke kosten met zich meebrengen. Het instellen van limieten voor query-kosten, het gebruik van incrementele modellen waar mogelijk en het monitoren van het rekenkrachtgebruik zijn de moeite waard om vanaf het begin in de workflow in te bouwen.

Hoe verwerkt een ELT-workflow betalingsdata?

Veel teams bouwen een aangepaste integratie met de aanmeldformulier programming interface (API) van hun betalingsprovider of gebruiken een connector van derden. Maar aangepaste integraties vereisen doorlopend onderhoud naarmate de API verandert, en connectors van derden betekenen routing van gevoelige financiële data via de infrastructuur van een extra leverancier.

Stripe Data Pipeline is een native optie die rechtstreeks in het Stripe Dashboard is ingebouwd. Het synchroniseert Stripe-data en -rapporten naar Snowflake, Databricks, Amazon Redshift en meer met een paar klikken. Er is geen code, geen connectorconfiguratie en geen afzonderlijke inloggegevens om te beheren. De synchronisatie draait op de eigen infrastructuur van Stripe, dus er zijn geen systemen van derden die de financiële data tijdens de overdracht verwerken.

Een paar details die de moeite waard zijn om te weten:

• Historische dekking: Stripe Data Pipeline bevat historische data vanaf de start van het Stripe-account, in plaats van vanaf het moment dat je de synchronisatie inschakelt.

• Schema: Data landt in tabellen die het datamodel van Stripe weerspiegelen (bijv. charges, klanten, abonnementen), waardoor het eenvoudig is om er transformatiemodellen bovenop te bouwen zonder uitgebreide opschoning van de ruwe laag.

• Volledigheid van de data: Naast ruwe objectdata bevat Stripe Data Pipeline toegang tot vooraf opgestelde financiële rapporten en gecureerde datasets, wat de rapportage kan versnellen en het transformatiewerk kan verminderen voor veelvoorkomende gebruiksscenario's, zoals maandelijks terugkerende inkomsten (MRR) en fraude-analyse.