Om du bygger en datapipeline för att mata ett business intelligence-verktyg eller träna en modell för maskininlärning är ett av de tidigaste besluten du måste fatta var transformeringen sker: innan datan landar i ditt datalager eller efter. Det innebär att du måste välja mellan extract, transform, load (ETL) och extract, load, transform (ELT).

Valet avgör hur snabbt analytiker kan få tillgång till rådata, hur mycket beräkningskraft du spenderar var, och hur enkelt du kan anpassa dig när din datamodell ändras. Marknaden för globala datapipelineverktyg beräknas vara värd $48.33 miljarder år 2030, och ETL tappar marknad till ELT och andra typer av pipelines.

Nedan går vi igenom hur varje modell fungerar, när ETL eller ELT är mest lämpligt och hur specialbyggda anslutningar passar in i båda tillvägagångssätten för specifika datakällor.

Viktiga punkter

• ETL transformerar data innan den når destinationen. ELT laddar rådata och transformerar den inuti datalagret med dess egen beräkningskraft.

• ELT är standardmönstret för de flesta moderna datateam. ETL förblir populärt för begränsade destinationer, strikta styrningskrav och äldre pipelines.

• Specialbyggda anslutningar för specifika datakällor kan minska risken för datakvalitetsproblem som generiska anslutningar ibland introducerar.

ETL- vs. ELT-pipelines: Vad är skillnaden?

ETL står för "extract, transform, load" (extrahera, transformera, ladda). I en ETL-modell drar du data från ett källsystem, kör den genom ett transformeringslager som rensar, omformar och filtrerar den, och laddar sedan det bearbetade resultatet till en destination, till exempel ett datalager eller ett data mart.

Med ETL gör en separat bearbetningsmotor det tunga jobbet innan data når destinationen. Datalagret tar emot strukturerad data som är redo att frågas mot, istället för de råa källposterna. Att bearbeta om från källan innebär antingen att man extraherar på nytt eller underhåller en separat råkopia någon annanstans.

ELT, som står för "extract, load, transform" (extrahera, ladda, transformera), vänder på de två sista stegen. Rådata landar först på destinationen, och sedan körs transformeringar inuti datalagret med dess egen beräkningskraft.

Detta skifte blev praktiskt genomförbart när molndatalager gjorde det billigt och snabbt att köra SQL-transformeringar (Structured Query Language) över stora dataset. Istället för att en separat transformeringsmotor sitter mellan källan och destinationen är ditt datalager transformeringsmiljön.

Hur fungerar ETL?

En ETL-pipeline körs i tre steg, vart och ett med ett distinkt ansvarsområde.

Så här fungerar ETL:

• Extrahera: En anslutning eller inläsningsjobb drar data från källan, till exempel en databas, ett API för betalningar, en SaaS-plattform eller en platt fil. Det här steget hanterar autentisering, sidnumrering, logik för inkrementell kontra fullständig uppdatering samt hastighetsgränser.

• Transformera: Den extraherade datan flyttas in i ett bearbetningslager där den rensas (t.ex. hantering av nollvärden, typkonvertering), omformas (t.ex. kopplingar, aggregeringar, omdöpning av kolumner), filtreras och ibland berikas med referensdata från andra källor.

• Ladda: Det bearbetade datasetet laddas till destinationen som en fullständig överskrivning, en upsert eller ett tillägg, beroende på hur pipelinen är konfigurerad.

ETL är fortfarande vettigt att använda i dessa specifika situationer:

• Begränsade destinationer: Äldre datalager eller lokala system med begränsad beräkningskraft kan inte effektivt köra stora transformeringar på plats, så att ladda förtransformerad data är det enda realistiska alternativet.

• Strikta styrningskrav: Vissa organisationer måste säkerställa att identifierbara personuppgifter eller känslig finansiell data aldrig landar i datalagret i råformat. Att transformera och maskera uppströms uppfyller det kravet arkitektoniskt.

• Kantmiljöer: IoT-system och inbyggda system som pushar data till en central infrastruktur kan ofta inte skicka stora rådatauppsättningar, vilket gör lokal transformering före överföring till en praktisk nödvändighet.

• Teknisk skuld i gamla pipelines: Många mogna organisationer har ETL-pipelines som har körts tillförlitligt i åratal. Att bygga om dem till ELT medför en risk som kanske inte är värd att ta.

Hur fungerar ELT?

ELT-pipelines extraherar och laddar rådata eller lätt formaterad källdata direkt till destinationen. Transformeringar körs efteråt, aktiverade enligt ett schema eller på begäran, med hjälp av datalagrets egen beräkningskraft.

Till exempel kan en anslutning extrahera data från en källa och skriva den till ett råschema i ditt datalager. En analys-tekniker skriver modeller för data build tools (dbt) som läser från det råschemat, tillämpar affärslogik och skapar rensade tabeller som verktyg för business intelligence (BI) kan fråga mot. När logiken behöver ändras uppdaterar de bara modellen och kör den igen mot data som redan finns där.

ELT är ett smart val av dessa anledningar:

• Snabbare tillgång till rådata: Data landar snabbt i datalagret, så teamen kan börja utforska och validera den innan transformeringslagret är klart.

• Billigare förbättringar: Att ändra en transformering i ETL innebär ofta att man måste modifiera en pipeline, bearbeta om och ladda om. I ELT uppdaterar du bara en SQL-modell och kör den igen mot data du redan har.

• Beräkning i datalagerskala: Molndatalager är byggda för att bearbeta stora dataset snabbt, vilket innebär att du tillämpar seriös beräkningskraft på transformering istället för att bygga ut ett separat middleware-lager oberoende av detta.

• Fullständig råhistorik: Eftersom rådatan alltid finns i datalagret kan du härleda vilken nedströms tabell som helst från grunden igen, vilket är viktigt när affärsdefinitioner ändras eller när du måste felsöka ett datakvalitetsproblem.

Hur väljer du mellan ETL och ELT?

Stora organisationer kör vanligtvis båda databehandlingsmodellerna parallellt för olika källor. Din organisations behov hjälper dig att avgöra vilken metod som passar bäst.

Här är vad du behöver tänka på.

Datavolym och hastighet

Data med hög volym och hög frekvens gynnar i allmänhet en ELT-datapipeline. Molndatalager hanterar det väl, och kostnaden för att köra en tung transformeringsmotor uppströms växer snabbt. Som en kompromiss ökar beräkningskostnaden för ditt lager när transformeringarna är tunga, och lagring av rådata medför kostnader.

Pipelines med lägre volym och stabil, väldefinierad transformeringslogik kan förmodligen stanna kvar på ETL utan större problem.

Ägarskap av transformering

Om dina transformeringar är SQL-baserade och ägs av analysingenjörer som behöver anpassa sig snabbt, är ELT med dbt eller ett liknande verktyg troligen det bästa valet.

Om dina transformeringar är kodade i Python eller Java och ägs av ett datateknikteam, kan ETL passa in naturligt i din befintliga verktygskedja.

Åtkomst till rådata

Om analytiker behöver åtkomst till källdata i råformat (t.ex. för ad hoc-utforskning, revision, eller för att transformeringslogiken fortfarande är under utveckling), är ELT det bättre standardvalet. ETL-pipelines som inte bevarar rådata gör den typen av åtkomst svår att bygga in i efterhand.

Styrning och efterlevnad

Om specifik data måste maskeras eller anonymiseras innan den når en gemensam destination, ger ETL dig ett arkitektoniskt säkerställande av det kravet.

ELT kan uppfylla många av samma krav genom säkerhet på kolumnnivå och åtkomstkontroller på lagernivå, men implementeringen skiljer sig åt och är värd att granska mot dina krav på efterlevnad.

Teamets arbetsflöde

Ett team med djup SQL-kunskap och versionshanteringsvanor kring dbt kommer att få ut mer värde från en ELT-konfiguration än från att underhålla en anpassad ETL-pipeline de inte har byggt själva. Kompatibilitet med hur ditt team arbetar är en legitim faktor.

Hur passar dataanslutningar in i ETL- och ELT-pipelines?

Generiska ETL- och ELT-verktyg hanterar ett brett utbud av källor genom konfigurerbara anslutningar. Den bredden är användbar, men den medför kompromisser.

Betalningsdata är ett bra exempel. Stripes datamodell täcker händelser, debiteringar, återbetalningar, tvister, saldotransaktioner, kunder, abonnemang och fakturor. En generisk anslutning som inte hänger med i Stripes API-versionering eller som hanterar inkrementell synkroniseringslogik felaktigt kan producera fel som är svåra att upptäcka förrän de påverkar en Dashboard eller en finansiell avstämning.

Stripe Data Pipeline hanterar detta direkt:

• Byggd och underhållen av Stripe: Eftersom Stripe äger anslutningen och speglar den interna Stripe-infrastrukturen direkt kan du synkronisera data tillförlitligt löpande och samtidigt säkerställa fullständighet och noggrannhet – oavsett hur mycket data du har och utan API-hastighetsgränser.

• Direkt synkronisering till datalager: Data flyttas till Amazon Redshift, Snowflake, Databricks och fler, utan routing via en tredjepartsanslutning, vilket håller känslig finansiell data borta från ytterligare leverantörsinfrastruktur.

• Komplett Stripe-dataset: Synkroniseringen täcker Stripe-objekt, förbyggda finansiella rapporter och kurerade dataset för att påskynda analys och rapportering.

• Lättviktig installation: Anslutningen konfigureras i Stripe Dashboard utan kod. Om du redan kör ELT-pipelines för andra källor, faller Stripe-data in i samma mönster.