ETL vs ELT: când transformi înainte de load și când după

ETL (Extract, Transform, Load) și ELT (Extract, Load, Transform) descriu ordinea în care datele sunt procesate într-un pipeline: în ETL, transformările se aplică înainte ca datele să fie încărcate în destinație, iar în ELT datele ajung brute în warehouse și sunt transformate acolo cu SQL sau unelte dedicate precum dbt. Diferența de ordine pare minoră, dar schimbă fundamental cine suportă costul de compute, cât de ușor poți re-rula transformările și cât de repede se propagă o schimbare de schemă.

Confuzia apare pentru că ambele produc același rezultat final (date curate, gata de analiză), dar prin mecanisme diferite. ETL era norma când warehouse-urile aveau resurse limitate; ELT a câștigat teren cu apariția warehouse-urilor cu compute scalabil și cu maturizarea uneltelor de transformare SQL.

Care e diferența semantică dintre ETL și ELT?

Ambele au trei pași, dar ordinea ultimilor doi este inversată:

• ETL. Extragi datele din sursă, le transformi într-un motor separat (un job Python, Spark, un server de integrare dedicat), apoi încarci rezultatul curat în warehouse sau baza de date țintă. Datele brute nu ajung niciodată în sistemul de destinație.
• ELT. Extragi datele din sursă, le încarci imediat brute într-un data warehouse, apoi le transformi acolo cu SQL sau un layer de transformare (dbt, proceduri stocate, view-uri materializate). Warehouse-ul suportă costul de compute al transformărilor.

Consecința directă: în ETL, datele brute nu sunt disponibile după ce transformarea a rulat. Dacă logica de transformare era greșită, re-rulezi tot de la extragere. În ELT, datele brute rămân în warehouse, separate de straturile curate, și poți re-rula oricând transformările fără să re-extragi de la sursă. Aceasta este cea mai importantă diferență practică pentru echipele care lucrează cu surse volatile sau cu logică de transformare care evoluează frecvent.

De ce ELT a devenit standardul după 2020?

Trei schimbări de context au favorizat ELT față de ETL clasic:

• Compute scalabil în warehouse. Snowflake, BigQuery și Redshift pot scala compute independent de stocare. A face transformări SQL grele direct în warehouse a deveni rezonabil economic când plătești doar pentru ce folosești, nu pentru un cluster permanent.
• Maturizarea dbt. dbt (data build tool) a standardizat modul în care transformările SQL sunt versionare, testate și documentate. Faptul că modelele dbt rulează direct în warehouse face ca ELT să aibă o cale clară de la datele brute la tabele curate, fără a scrie pipeline-uri custom de transformare.
• Uneltele de ingestie ca serviciu. Fivetran, Airbyte și altele au automatizat etapa de extragere și load, reducând ELT la „configurezi conectori, datele brute ajung în warehouse, dbt le transformă". ETL clasic cere un job de transformare separat care crește în complexitate odată cu numărul de surse.

ETL rămâne relevant pentru scenarii cu cerințe stricte la nivel de sursă. Cel mai frecvent: PII filtering sau anonimizare care trebuie aplicate înainte ca datele să atingă orice sistem de stocare, inclusiv warehouse-ul. Al doilea scenariu: surse cu formate binare sau proprietare care nu pot fi ingerate brut. În ambele cazuri, transformarea trebuie să aibă loc în tranzit, nu în destinație, și ETL clasic este soluția.

Care sunt trade-off-urile concrete?

• Cost compute. ELT mută costul de compute în warehouse, unde poate fi scalat elastic dar și facturat per execuție. ETL clasic rulează transformările pe un server dedicat cu cost fix. Pentru volume mari de transformări repetitive, ETL poate fi mai predictibil ca buget; pentru transformări care evoluează frecvent sau rulează rar, ELT e mai eficient.
• Stocare brută. ELT necesită spațiu suplimentar pentru datele brute, care coexistă cu straturile transformate. Aceasta este prețul flexibilității: poți re-rula oricând, dar plătești stocarea.
• Debug și trasabilitate. ELT câștigă clar la debug: datele brute sunt vizibile oricând, poți compara inputul cu outputul transformărilor și identifica exact unde logica introduce erori. În ETL, dacă datele brute nu au fost arhivate separat, re-crearea unui scenariu de debug cere re-extragere.
• Latență. ETL poate produce date curate mai rapid dacă transformările sunt simple și rulează în paralel cu extragerea. ELT introduce un pas suplimentar: întâi load, apoi transformare. Pentru cazuri cu cerințe de latență mică (date operaționale aproape real-time), ETL cu transformări ușoare sau change data capture direct în pipeline poate fi mai potrivit.
• Schema drift necontrolat. Când sursa schimbă structura fără anunț (o coloană redenumită, un câmp eliminat), ELT propagă schimbarea imediat în tabelele brute, de unde ajunge rapid la modele, view-uri materializate și rapoarte. ETL poate absorbi schimbarea în stratul de transformare, dar fără validare explicită, eroarea apare tot abia în producție. Ambele abordări necesită detectare proactivă la ingestie.

Cum operăm pe PromoAzi (S10, data engineering)?

Pe PromoAzi, pipeline-ul de scraping capturează săptămânal 95,6% din promoțiile celor 14 lanțuri urmărite.¹ Datele intră brute, apoi sunt transformate în pași discreți (ELT-style) pentru ușurința de a re-rula transformările fără a re-extrage. Această separare între ingestia brută și straturile curate derivate este decisivă când un retailer schimbă structura paginilor între run-uri: re-rulăm transformările pe datele deja stocate, fără să reluăm extragerea de la zero.

Alegerea arhitecturală de a stoca datele brute este deliberată. Ingestia timpurie permite monitorizarea la nivel de pipeline (ce a intrat, ce volum, ce s-a schimbat față de run-ul anterior), separată de monitorizarea calității datelor transformate. Cele două straturi eșuează din motive diferite și cer remedieri diferite. Faptul că S10 acoperă atât ingestia cât și transformările și livrarea aval este ce permite un astfel de control end-to-end, conform principiului din A.01 că deținem tot stack-ul.

Care e capcana cea mai costisitoare: schema drift necontrolat?

Schema drift înseamnă că structura datelor la sursă se schimbă, iar pipeline-ul tău nu știe. Un câmp redenumit, un tip de date schimbat, o coloană eliminată. În ELT, datele brute cu schema nouă intră în warehouse fără probleme, dar modelele de transformare care referențiază câmpul vechi produc erori sau, mai grav, rezultate greșite tăcut. Descoperirea se face adesea abia când un raport aval arată numere incorecte.

Trei practici care limitează impactul:

• Validare la ingestie. Înainte să consideri un batch acceptat, verifică că structura corespunde schemei așteptate. Dacă nu corespunde, semnalează eroarea imediat și nu propaga datele în straturile curate. Aceasta e prima linie de apărare, indiferent dacă folosești ETL sau ELT. O soluție de observabilitate bine pusă la punct include alerte pe abaterile de volum și structură.
• Versionarea transformărilor. Transformările ar trebui gestionate ca și cod: versionare, testate pe date reprezentative, cu posibilitatea de a face rollback dacă un model nou produce rezultate neașteptate. Fie că sunt scripturi SQL, fie că folosești dbt sau proceduri stocate, versionarea este non-negociabilă în pipeline-uri de producție.
• Separarea clară a straturilor. Datele brute, datele în curs de transformare și datele curate ar trebui să fie vizibil separate în warehouse, nu îmbinate. Atunci când apare un incident de schema drift, știi exact în ce strat să cauți și câte modele downstream sunt afectate.

Schema drift necontrolat nu este o problemă de ETL sau ELT, ci o problemă de lipsă a unui contract de date între producătorul și consumatorul datelor. Indiferent de arhitectura aleasă, contractul acesta trebuie formalizat prin convenții de schema în warehouse sau prin instrumente de contract explicit la nivel de API.

1. PromoAzi a atins 95,6% rata de captură pentru promoțiile săptămânale, măsurată pe 14 lanțuri de retail în luna ianuarie 2026. [promoazi.offer_capture]