Narcis Miclaus

9 min de citit

Arhitectura datelor și a sistemelor, de la zero Lecția 33 / 80

ETL vs ELT: unde trăiește transformarea

Ordinea operațiilor s-a schimbat când warehouse-urile au devenit ieftine. De ce ELT (extract, load, transform) a înlocuit ETL pentru majoritatea stack-urilor de date moderne.

Bun venit la Modulul 5. Modulul 4 ne-a lăsat cu un set de baze de date bine replicate, bine partiționate, bine sharded, și cu un case study Discord care arată cum arată acele abstracții la scară. Storage-ul e podeaua. Acum trebuie să vorbim despre ce curge prin el.

Modulul 5 acoperă batch processing: familia de job-uri care citesc o intrare finită (și de obicei mare), fac muncă asupra ei și scriu o ieșire finită, fără așteptarea de a se termina în milisecunde. Job-ul rulează, se termină și se oprește. Agregate orare, rapoarte zilnice, date de antrenare pentru machine learning, coloanele pe care le citește dashboard-ul BI la 7 dimineața: toate sunt batch. Dualul batch-ului e stream processing-ul, pe care-l acoperă Modulul 6. Pentru moment, datele sunt în repaus, iar job-ul are timp să gândească.

Începem cu întrebarea care organizează orice pipeline batch scris vreodată: unde trăiește pasul de transformare? În 1995 răspunsul era diferit de cel din 2026, iar tranziția între cele două răspunsuri e cea mai curată cale de a vedea de ce stack-ul de date modern arată cum arată.

Cele două ordini de litere

Un pipeline batch care mută date dintr-un sistem sursă într-un store analitic are trei pași. Extragi înregistrări din sursă (o bază de date tranzacțională, un API SaaS, un CSV care aterizează într-un folder FTP, un stream de loguri arhivat pe disc). Le transformi: cureți null-uri, deduplici, parsezi date, faci join cu date de referință, calculezi coloane derivate, conformezi la o schemă țintă. Și încarci rezultatul în destinația analitică, care e aproape întotdeauna un data warehouse.

Cele două ordini de litere care numesc pipeline-uri sunt despre unde se întâmplă transformarea.

ETL vine de la extract, transform, load. Pasul de transformare rulează într-un strat de calcul separat între sursă și warehouse: un server ETL dedicat, un cluster Spark, o flotă de workeri Python. Datele pleacă de la sursă, sunt remodelate din zbor, și sosesc la warehouse deja în forma lor analitică. Warehouse-ul stochează doar ieșirea curățată, conformată, gata pentru query.

ELT vine de la extract, load, transform. Pasul de transformare rulează în interiorul warehouse-ului, pe date care au aterizat deja acolo în ceva apropiat de forma lor brută. Datele pleacă de la sursă, sunt aruncate în warehouse cu procesare minimă, iar transformarea se întâmplă ca o secvență de instrucțiuni SQL care citesc tabele brute și scriu tabele derivate.

Pipeline-urile arată aproape identic de la distanță. Aceleași trei cutii, aceleași trei săgeți. Poziția unei cutii e întreaga poveste a motivului pentru care stack-ul de date s-a reconstruit între 2015 și 2025.

flowchart LR
    subgraph ETL[ETL]
      S1[(Source)] --> T1[Transform layer<br/>Informatica, Talend, Spark]
      T1 --> W1[(Warehouse<br/>cleaned only)]
    end
    subgraph ELT[ELT]
      S2[(Source)] --> W2[(Warehouse<br/>raw + derived)]
      W2 --> T2[Transform in-warehouse<br/>dbt, SQL]
      T2 --> W2
    end

Era ETL

Prin anii ‘90 și 2000, ETL nu era o alegere. Era singura arhitectură care avea sens economic, și motivul era warehouse-ul.

Warehouse-urile dominante ale acelei ere erau Teradata, Oracle și edițiile data-warehouse ale SQL Server, cu IBM Db2 în unele organizații. Erau vândute ca appliance-uri sau ca software licențiat scump, dimensionate pentru un workload fix, cu storage-ul și calculul cuplate într-o singură cutie. Adăugarea de capacitate însemna cumpărarea unui appliance mai mare, ceea ce însemna un ciclu de procurement măsurat în trimestre. Calculul de warehouse era resursa cea mai rară din clădire, și era rezervat pentru query-urile pe care business-ul chiar le rula.

Încărcarea datelor brute în acel warehouse și apoi rularea de query-uri de curățare împotriva lui ar fi fost un act de vandalism. Query-urile de curățare ar fi concurat cu query-urile analiștilor pentru aceleași core-uri scumpe, datele brute ar fi mâncat aceleași discuri scumpe pe care business-ul se aștepta să țină modele dimensionale, iar appliance-ul ar fi fost dimensionat pentru workload-ul greșit într-un an. Așa că curățai datele altundeva.

Acel altundeva era stratul ETL. Informatica PowerCenter (încă cel mai mare vendor ETL după venit când a redevenit privat în 2023), IBM DataStage, Microsoft SSIS și Talend au definit categoria. Sub GUI, un job ETL era un graf de operatori, fiecare citind rânduri din amonte, făcând ceva muncă, și împingând rânduri în aval, cu operatorul final scriind în warehouse. Multe organizații ocoleau vendorii cu totul și scriau job-urile ETL ca scripturi Python sau shell rulate de cron, care trăgeau de la surse, transformau în pandas sau PL/SQL, și inserau rezultatul.

Proprietatea arhitecturală a erei ETL e că warehouse-ul vede doar date curate vreodată. Rândurile brute din sistemul sursă nu aterizează niciodată în el. Dacă o regulă de transformare era greșită, fixai regula în stratul ETL și rulai din nou job-ul, ceea ce însemna re-extragere din sursă. Nu exista un strat „brut” la care să te întorci.

Ce s-a schimbat

Warehouse-urile cloud au schimbat economia, iar ordinea operațiilor a urmat.

Snowflake (general availability 2014), BigQuery (public 2012) și Redshift (2013) au mutat warehouse-urile la un model de separare-a-storage-ului-și-calculului care rulează pe object storage și calcul on-demand. Storage-ul a devenit ieftin (cenți pe gigabyte pe lună, pe object stores commodity sub capotă). Calculul a devenit elastic (pornești un warehouse pentru un query, îl oprești când e idle). Adăugarea de capacitate a încetat să fie un ciclu de procurement și a început să fie o setare într-un fișier de config. Databricks SQL (2021) a adus același model în partea lakehouse a lumii.

Odată ce calculul de warehouse a devenit ieftin și elastic, argumentul pentru a ține datele brute afară s-a evaporat. Puteai să aterizezi totul, să stochezi pentru totdeauna pe un ban, și să rulezi query-urile de curățare pe același motor care rula query-urile BI. Transformarea a încetat să fie un pas extern de pre-procesare și a devenit o secvență de instrucțiuni SQL care trăia lângă restul codului analitic.

Tooling-ul s-a reorganizat în jurul noii forme. Stack-ul ELT modern are trei straturi.

Extract și load. Fivetran, Airbyte, Stitch și Meltano domină business-ul de conectori gestionați. Ei se ocupă de partea urâtă a integrării: ciudățeniile API-urilor SaaS, schema drift-ul, logica de pull incremental, rotația credențialelor. Output-ul e tabele brute în warehouse care arată cât mai mult ca sursa pe cât de rezonabil e. Multe echipe suplimentează conectorii gestionați cu ingestie Python custom pentru long tail-ul de sisteme interne, care aterizează în același strat brut.

Warehouse. Snowflake, BigQuery, Redshift, Databricks SQL. Același motor stochează datele brute, rulează transformările și servește unealta BI. Nu există un strat de calcul separat pentru transformări.

Transform. dbt e unealta dominantă a stack-ului de date modern în 2026. Un proiect dbt e un director de fișiere SQL. Fiecare fișier e o instrucțiune select care definește un model. dbt compilează proiectul într-un graf de dependențe și rulează modelele în ordine, materializând fiecare ca un tabel sau o vedere în warehouse. Versionat în git, testat cu aserțiuni, documentat automat, executat de CI. Logica de transformare încetează să fie o cutie neagră în interiorul unei unelte ETL și devine un repository de cod pe care echipa de date îl deține în același fel în care echipa de aplicație își deține serviciile.

De ce câștigă ELT pentru majoritatea cazurilor

Câteva motive se compun.

Stratul brut e păstrat. Odată ce datele aterizează în warehouse într-o formă apropiată de cea a sursei, poți re-deriva orice în aval. O nouă definiție de metrică nu necesită o re-extragere; scrii un nou model SQL. Un bug într-o transformare istorică poate fi fixat și modelele afectate reconstruite fără a te întoarce la sursă. Stratul brut e singura sursă de adevăr, iar sistemul sursă nu mai e în buclă pentru întrebările analitice.

Transformările trăiesc în SQL. Oamenii care știu întrebările de business sunt de obicei analiștii, iar analiștii știu SQL. ELT pune codul de transformare în limba pe care oamenii cei mai apropiați de date deja o vorbesc, în loc să-l rute printr-o unealtă ETL separată care necesită un set de skill-uri separat.

Același warehouse servește dashboard-ul și transformarea. Operațional, ai un sistem de scalat, un sistem de monitorizat, un sistem de făcut backup. Transformările și query-urile BI împart un workload manager și un model de access-control. Uneltele de lineage (docs-urile dbt, plus intrările mai noi precum Atlan, OpenMetadata și Datafold) pot urmări o coloană pe un dashboard înapoi prin fiecare model care a produs-o, pentru că totul e query-uri împotriva aceluiași motor.

Costul e în mare parte storage, care e ieftin. Intuiția economică s-a inversat: păstrarea datelor brute e aproape gratuită, iar transformările rulează doar când ceva trebuie reîmprospătat. Calculul e plătit la secundă pe query-urile care chiar rulează, nu de un appliance static care stă idle trei nopți pe săptămână.

Când ETL e încă potrivit

ELT e default-ul în 2026, dar cazurile în care transformarea aparține în amonte sunt reale.

Datele sursă sunt sensibile. Dacă input-ul conține date personale pe care warehouse-ul nu are voie să le țină (anumite câmpuri din înregistrări medicale, numere de plată brute, anumiți identificatori sub scopurile GDPR, HIPAA sau PCI), nu poți ateriza datele brute și apoi să le cureți. Datele trebuie filtrate, anonimizate sau tokenizate înainte de a părăsi mediul sursă. Ăla e un pipeline ETL prin necesitate, chiar dacă restul stack-ului e ELT.

Volumul e atât de mare încât calculul de warehouse e prea scump. Warehouse-urile cloud sunt ieftine per query, dar ingestia la scară de petabytes cu procesare grea per rând poate costa mai mult în credite de warehouse decât rularea aceleiași transformări pe un cluster Spark împotriva object storage-ului brut. Pattern-ul lakehouse (Modulul 5 lecția 37) adresează asta mutând transformările pe calcul ieftin împotriva formatelor de tabele deschise, dar principiul e același: când calculul de warehouse e bottleneck-ul, fă munca grea în altă parte.

Transformarea necesită ceva ce warehouse-ul nu poate face. Procesare de imagini, transcripție audio, inferență ML, apeluri către API-uri externe pentru a îmbogăți rândurile: motoarele SQL de warehouse nu rulează asta bine, dacă rulează deloc. Transformarea trăiește într-un strat Spark sau Python în amonte, și doar rezultatul aterizează în warehouse.

Sursa nu-și permite să trimită date brute. O flotă IoT care generează terabytes de citiri de senzori pe oră de obicei nu-și permite lățimea de bandă pentru a transmite brut în cloud. Agregarea la edge reduce volumul înainte ca acesta să părăsească dispozitivul, ceea ce e ETL sub un alt nume.

Hibridul e realitatea comună. Bulk-ul pipeline-urilor sunt ELT în warehouse; cazurile speciale (filtrare PII, îmbogățire ML, agregare la edge) sunt pre-procesare cu aromă ETL care aterizează o versiune ușor gătită a stratului brut.

Cu ce rămânem

Trecerea de la ETL la ELT n-a fost o schimbare de modă. A urmărit o schimbare reală în curbele de cost ale storage-ului și calculului de warehouse, și a tras pasul de transformare dintr-o unealtă închisă într-un repository SQL pe care echipa de date îl poate revizui, testa și versiona ca pe orice alt cod.

Podeaua arhitecturală sub ELT-ul modern e motorul warehouse-or-lakehouse care rulează query-urile de transformare. Acel motor are propria istorie. Descendenții MapReduce, procesoarele batch distribuite open-source din care warehouse-urile cloud au copiat părți intern, sunt subiectul lecției 34. Înainte ca Snowflake să facă batch-ul invizibil în spatele unui prompt SQL, cineva a trebuit să inventeze ideea că o mie de mașini ieftine puteau înlocui una scumpă. Acel cineva a fost Google, iar comunitatea open-source a petrecut deceniul următor recuperând.

Citări și lecturi suplimentare

  • dbt Labs, „What is dbt?”, https://docs.getdbt.com/docs/introduction (consultat 2026-05-01). Referința pentru pattern-ul modern de transformare în warehouse.
  • Snowflake, „Key Concepts and Architecture”, https://docs.snowflake.com/en/user-guide/intro-key-concepts (consultat 2026-05-01). Separarea storage-ului și calculului care a făcut ELT-ul economic la scară.
  • Google Cloud, „BigQuery overview”, https://cloud.google.com/bigquery/docs/introduction (consultat 2026-05-01).
  • Fivetran, „ETL vs. ELT”, https://www.fivetran.com/learn/etl-vs-elt (consultat 2026-05-01). Sumar din perspectiva vendor, util pentru cronologia istorică.
  • „Fundamentals of Data Engineering” (Joe Reis și Matt Housley, O’Reilly, 2022), capitolele despre ingestie și transformare. Referința standard contemporană pentru stack-ul de date modern.
Caută