ETL vs ELT: diferències, exemples i quan utilitzar cada enfocament

La comparació entre ETL i ELT sovint es presenta com una qüestió terminològica, però en realitat descriu dues maneres diferents de dissenyar un sistema de moviment i preparació de dades. La diferència no és només l’ordre de tres sigles. Canvia el punt en què s’apliquen les transformacions, el tipus d’infraestructura necessària, la manera d’escalar el processament i, sobretot, la forma com una organització conserva i explota les seves dades.

Per entendre bé aquesta diferència, convé situar primer el problema tècnic. Una empresa genera dades en múltiples sistemes: aplicacions transaccionals, APIs, fitxers, logs, eines SaaS o bases de dades relacionals. Aquestes dades no solen arribar preparades per analitzar-se. Normalment contenen formats inconsistents, duplicats, valors nuls, regles de negoci no aplicades o estructures incompatibles entre si. Per això apareix la necessitat d’una pipeline de dades: un flux controlat que extreu la informació dels seus orígens, la prepara i la deixa disponible per a anàlisi, reporting o consum per part d’altres sistemes.

En aquest context, ETL i ELT són dues estratègies per resoldre el mateix problema. Totes dues extreuen dades d’una font i les porten a un sistema de destinació. La diferència és quan i on es transforma la informació. Aquest matís, que sembla petit sobre el paper, té conseqüències arquitectòniques importants.

Què fa realment una pipeline de dades?

Una pipeline de dades és una seqüència de processos que transporta dades des d’un o diversos sistemes d’origen cap a un sistema de destinació on es poden consultar, creuar o reutilitzar. En un entorn modern, aquesta destinació sol ser un data warehouse o un data lake. Un data warehouse és un sistema d’emmagatzematge optimitzat per a consulta analítica. Un data lake prioritza l’emmagatzematge massiu de dades en brut o semiestructurades.

La pipeline no es limita a copiar informació d’un lloc a un altre. La seva funció real és convertir dades operacionals en dades utilitzables. Això implica, com a mínim, quatre capes de treball:

1. Extracció. Obtenir dades des de bases de dades, serveis externs, aplicacions internes o arxius.
2. Càrrega. Moure aquestes dades a un entorn centralitzat.
3. Transformació. Netejar, tipar, enriquir, deduplicar o modelar les dades.
4. Exposició. Deixar el resultat preparat per a quadres de comandament, anàlisi, models predictius o consum per altres aplicacions.

La discussió ETL vs ELT afecta sobretot la tercera capa. No discuteix si cal transformar les dades, sinó en quin moment del flux convé fer-ho i quin sistema ha d’assumir aquesta càrrega de treball.

Què és ETL i com està estructurat

ETL significa Extract, Transform, Load: extreure, transformar i carregar.

En aquest enfocament, les dades s’extreuen des dels sistemes d’origen, es processen en un entorn intermedi i només després es carreguen al sistema de destinació. La idea és que l’emmagatzematge final rebi ja un conjunt de dades net, validat i estructurat segons les regles definides.

L’estructura lògica d’un sistema ETL sol incloure aquests components:

• Fonts de dades: bases de dades relacionals, APIs, arxius CSV, ERP, CRM o aplicacions SaaS.
• Motor de transformació: scripts, jobs programats o eines específiques que apliquen regles de neteja i normalització.
• Entorn de staging: una àrea temporal on les dades es preparen abans de la càrrega final.
• Sistema de destinació: normalment un data warehouse amb taules ja modelades per a anàlisi.

Des d’un punt de vista tècnic, ETL respon bé a entorns on el sistema final no ha de rebre dades crues o on la validació prèvia és obligatòria. És habitual en arquitectures tradicionals de BI, en sistemes on-premise i en contextos on el control sobre la qualitat de la dada s’aplica abans de persistir-la.

En la pràctica, aquest enfocament té una lògica clara: si sé exactament quina estructura necessito i vull assegurar-me que només arribi informació depurada al sistema analític, transformo primer i carrego després.

Un exemple simplificat es pot veure en un petit procés ETL construït amb Python i pandas. Primer s’extreuen les dades, després es netegen i es transformen, i finalment es carreguen al sistema de destinació:

import pandas as pd
from sqlalchemy import create_engine

# connexió a base de dades origen i destinació
source_engine = create_engine("postgresql://source_db")
target_engine = create_engine("postgresql://warehouse")

# Extract
orders = pd.read_sql("SELECT order_id, amount, country FROM orders", source_engine)

# Transform
orders = orders.dropna(subset=["order_id"])
orders["amount_eur"] = orders["amount"] * 0.93
summary = orders.groupby("country", as_index=False)["amount_eur"].sum()

# Load
summary.to_sql("sales_by_country", target_engine, if_exists="replace", index=False)

En aquest flux, la base de dades analítica només rep el resultat final ja transformat. Tota la lògica de neteja, agregació i càlcul passa abans de la càrrega.

Què és ELT i per què canvia l’arquitectura

ELT significa Extract, Load, Transform: extreure, carregar i transformar.

Aquí l’ordre operatiu s’inverteix. Les dades s’extreuen des de les fonts i es carreguen primer al sistema de destinació, normalment un data warehouse cloud. Les transformacions s’executen després, dins d’aquest mateix sistema, aprofitant-ne la capacitat de còmput.

L’aparició d’ELT no respon a una preferència teòrica, sinó a un canvi en la infraestructura disponible. Plataformes com Snowflake, BigQuery o Redshift permeten emmagatzemar grans volums d’informació i executar transformacions analítiques directament sobre el motor de destinació. Això redueix la necessitat d’un sistema extern dedicat exclusivament a preparar les dades abans de carregar-les.

L’estructura d’un sistema ELT sol recolzar-se en aquests elements:

• Connectors o processos d’ingestió per extreure dades des de les fonts.
• Zona raw o capa d’aterratge dins del warehouse, on es conserven les dades tal com arriben.
• Capa de transformació implementada normalment amb SQL, models analítics o eines com dbt.
• Capa de consum amb taules ja modelades per a negoci, reporting o ciència de dades.

La conseqüència tècnica més rellevant és que ELT permet conservar tant la dada original com les seves derivacions transformades. Això dona més flexibilitat per refer models, depurar problemes o reutilitzar informació amb finalitats diferents sense haver de repetir l’extracció des de l’origen.

Un exemple típic en una arquitectura ELT seria carregar primer les dades sense processar al warehouse i aplicar les transformacions posteriorment amb SQL:

-- Les dades arriben primer a una taula raw
SELECT *
FROM raw.orders;

Després es creen models transformats dins del mateix warehouse:

CREATE OR REPLACE TABLE analytics.sales_by_country AS
SELECT
    country,
    SUM(amount * 0.93) AS amount_eur
FROM raw.orders
WHERE order_id IS NOT NULL
GROUP BY country;

Aquí el warehouse actua tant com a repositori de dades com a motor de transformació. La dada original roman disponible a la capa raw, mentre que les taules analítiques es generen com a derivacions posteriors.

La diferència real entre ETL i ELT

A nivell superficial, la diferència entre ETL i ELT és l’ordre de les lletres. A nivell d’arquitectura, la diferència real és aquesta: quin sistema assumeix el cost de transformar les dades i en quina fase del pipeline es perd o es conserva la dada bruta.

En ETL, la transformació passa abans de la càrrega. El sistema d’emmagatzematge final rep dades ja processades. Això simplifica el model final, però limita la capacitat de revisar la dada original si no s’ha conservat en un altre lloc.

En ELT, la càrrega passa abans de la transformació. El sistema de destinació actua com a repositori de dades crues i com a motor de transformació. Això ofereix més flexibilitat analítica, però exigeix disciplina en el modelatge, el versionat i el control de costos de còmput.

Dit d’una altra manera, ETL prioritza el control previ. ELT prioritza la capacitat de processar i reinterpretar les dades un cop emmagatzemades.

Comparativa tècnica: ETL vs ELT

Aquesta taula resumeix les diferències operatives, però convé no interpretar-la com una jerarquia. ELT no substitueix automàticament ETL en tots els casos. El que és correcte és analitzar el context tècnic del sistema.

Quan té sentit utilitzar ETL

ETL continua sent una elecció raonable quan la transformació prèvia no és opcional, sinó part del control del sistema. Això passa, per exemple, en diversos escenaris.

El primer és aquell en què la destinació no ha d’emmagatzemar dades sense validar. Si una organització necessita assegurar que tota la informació carregada compleix regles estrictes abans de persistir-se, ETL permet filtrar i normalitzar des de l’inici.

El segon és el d’infraestructures on el sistema de destinació no està pensat per assumir transformacions complexes. Això continua sent freqüent en entorns legacy o en arquitectures on-premise amb recursos limitats.

El tercer apareix quan el volum de dades és moderat i el model està ben definit per endavant. En aquest cas, un flux ETL pot resultar més senzill de governar i més previsible.

En la meva experiència, aquest enfocament apareix de manera natural en pipelines construïdes amb Python i pandas quan l’objectiu és consolidar diverses fonts relacionals, aplicar regles clares de neteja i entregar un dataset ja preparat per al consum. En aquests casos, ETL no només és vàlid, sinó que sol ser l’opció més directa.

Quan té sentit utilitzar ELT

ELT encaixa millor quan el sistema de destinació disposa de prou capacitat de còmput i quan interessa conservar la màxima quantitat possible d’informació abans de decidir com modelar-la.

Això és especialment rellevant en arquitectures modernes basades en Snowflake, BigQuery o plataformes similars. En aquests entorns, carregar primer i transformar després permet desacoblar la ingestió del modelatge. Aquesta separació simplifica l’evolució del sistema: les dades arriben a una capa raw, després s’estructuren per etapes i finalment es publiquen en models preparats per a negoci.

ELT també té avantatge quan les regles de transformació canvien amb freqüència. Si la dada bruta ja està emmagatzemada, refer un model és més senzill que tornar a extreure i reconstruir tot el pipeline des de l’origen.

En el meu cas, aquest patró té força sentit quan el warehouse és Snowflake i la major part de les transformacions es poden expressar en SQL o en capes analítiques posteriors. El punt important no és només que el sistema escali millor, sinó que l’arquitectura guanya traçabilitat: és més fàcil veure què va arribar, què es va transformar i quin resultat va produir cada pas.

Com encaixen tots dos enfocaments en una pipeline moderna

Una pipeline moderna rarament és una sola peça. Normalment està composta per diverses capes amb responsabilitats diferents: ingestió, emmagatzematge brut, transformació intermèdia, modelatge final i exposició.

En aquest context, ETL i ELT no s’han d’entendre com etiquetes tancades, sinó com estratègies dominants dins del flux. Un sistema pot ser principalment ELT i, tot i així, incorporar petites transformacions prèvies abans de la càrrega. De la mateixa manera, un procés ETL pot recolzar-se en el warehouse per a algunes derivacions posteriors.

La qüestió important és identificar on passa la lògica principal del sistema. Si la major part de les regles de negoci, tipat, joins i modelatge s’executen al warehouse, som davant d’una arquitectura orientada a ELT. Si tot això passa abans de carregar la dada final, la lògica dominant és ETL.

Des d’una perspectiva de disseny, convé pensar la pipeline com una cadena amb tres decisions separades:

1. Com ingereixo les dades.
2. On les persisteixo inicialment.
3. On i com aplico les transformacions.

ETL i ELT afecten sobretot la tercera, però condicionen també les altres dues.

Com s’estructuren moltes pipelines modernes (raw, staging, marts)

En arquitectures modernes de dades, especialment quan s’adopta un enfocament ELT, és habitual organitzar el warehouse en diverses capes lògiques. Aquest patró ajuda a separar responsabilitats i facilita entendre què passa amb les dades en cada etapa del procés.

Una manera comuna d’estructurar aquestes capes és la següent:

1. Capa raw (o landing)

Aquí s’emmagatzemen les dades tal com arriben des de les fonts. No s’apliquen transformacions complexes; l’objectiu principal és conservar una còpia fidel de la dada original.

Per exemple:

• taules replicades des de bases de dades operacionals
• dades ingerides des d’APIs
• esdeveniments o logs

Aquesta capa permet auditar quines dades van arribar realment al sistema i tornar a processar-les si canvia el model analític.

2. Capa staging

En aquesta capa comencen les primeres transformacions sistemàtiques. L’objectiu encara no és produir models finals, sinó preparar les dades perquè es puguin combinar amb altres fonts.

Aquí solen aplicar-se tasques com:

• tipat de columnes
• normalització de formats
• eliminació de duplicats
• estandardització de noms

En molts equips aquestes transformacions s’implementen amb SQL o eines de modelatge analític com dbt, que permeten versionar la lògica de transformació com si fos codi.

3. Capa marts o analytics

L’última capa conté els models orientats a negoci. Aquí apareixen les taules que realment utilitzen els analistes, dashboards o models de machine learning.

Exemples típics:

• sales_by_country
• daily_active_users
• customer_lifetime_value

Aquestes taules solen construir-se combinant diverses fonts ja preparades en staging i aplicant regles de negoci més complexes.

Aquest enfocament per capes no pertany exclusivament a ELT, però hi encaixa especialment bé. En carregar primer les dades crues al warehouse, és possible construir progressivament aquestes capes sense necessitat de repetir l’extracció des de l’origen.

Des del punt de vista d’enginyeria, aquesta separació aporta diversos avantatges:

• traçabilitat: és fàcil seguir el camí de la dada des de l’origen fins al model final
• reproduïbilitat: els models poden reconstruir-se des de la capa raw
• mantenibilitat: cada capa té responsabilitats clares

Per això moltes pipelines modernes no es descriuen només com ETL o ELT, sinó també per l’estructura de capes que utilitzen dins del sistema analític.

Errors habituals en comparar ETL i ELT

Un dels errors més comuns és presentar ELT com una evolució que torna obsolet ETL. Aquesta idea és incompleta. ELT ha guanyat pes perquè la infraestructura cloud ha canviat el cost relatiu de l’emmagatzematge i del còmput, però això no elimina els casos on transformar abans continua sent la decisió correcta.

Un altre error freqüent és reduir la comparació a una taula de pros i contres sense explicar el tipus de dades, la mida del sistema ni la destinació analítica. Sense aquest context, la comparació es torna abstracta i acaba sent poc útil.

També és habitual barrejar discussió tècnica amb discussió d’eines. Eines com Airflow, dbt, Fivetran o Talend participen en diferents parts del flux, però no defineixen per si mateixes si una arquitectura és ETL o ELT. El que ho defineix és on es produeix la transformació principal.

He vist, a més, una fallada recurrent en pipelines petites que creixen de pressa: començar amb scripts simples en pandas, assumir que aquest patró escalarà sense canvis i acabar concentrant massa lògica en un punt únic del procés. Mentre el volum és baix, pot funcionar. Quan augmenten les fonts, les dependències i els temps d’execució, convé revisar si l’arquitectura continua tenint sentit o si és millor desplaçar part de la lògica al warehouse.

Quin enfocament triar

La decisió entre ETL i ELT no s’hauria de prendre per tendència, sinó per ajust tècnic.

Si treballes amb fonts relativament controlades, volum moderat, regles estables i necessitat de validar abans de persistir, ETL continua sent una opció sòlida.

Si treballes amb un data warehouse cloud potent, necessites conservar dada bruta, vols refer transformacions amb freqüència o prefereixes desacoblar ingestió i modelatge, ELT sol oferir una arquitectura més flexible.

La pregunta útil no és quin és millor en abstracte, sinó aquesta: on té més sentit aplicar la transformació principal de les meves dades, tenint en compte els meus sistemes, el meu volum i la meva manera d’explotar la informació.

Aquesta pregunta obliga a mirar l’arquitectura real, no només les sigles.

Conclusió

ETL i ELT descriuen dues maneres d’organitzar una pipeline de dades. Totes dues extreuen informació des de fonts diverses i la deixen preparada per a anàlisi, però ho fan desplaçant la transformació a llocs diferents del sistema.

ETL concentra la preparació abans de la càrrega i afavoreix un control previ més gran sobre el que entra al repositori analític. ELT trasllada aquesta lògica al data warehouse i aprofita la capacitat de còmput de la destinació per transformar després d’emmagatzemar.

En termes pràctics, l’elecció depèn de tres variables: el tipus d’infraestructura disponible, el nivell de control que necessites abans de persistir les dades i la flexibilitat que vols conservar per remodelar la informació més endavant.

Per això, per entendre ETL vs ELT de veritat, no n’hi ha prou amb memoritzar les sigles. Cal llegir-les com una decisió d’arquitectura.

FAQ

ETL està obsolet?

No. Ha perdut protagonisme en alguns entorns cloud, però continua sent útil quan la validació prèvia és obligatòria, quan la destinació no ha d’emmagatzemar dades crues o quan la infraestructura final no està pensada per transformar grans volums.

ELT és sempre millor a Snowflake o BigQuery?

No sempre, tot i que sol encaixar millor. Aquestes plataformes faciliten l’enfocament ELT perquè permeten carregar dades ràpidament i transformar-les després amb bon rendiment. Tot i així, pot haver-hi transformacions prèvies necessàries per qualitat, seguretat o compatibilitat.

La diferència entre ETL i ELT és només l’ordre de les fases?

Formalment sí, però tècnicament no. Aquest canvi d’ordre redefineix on viu la lògica del sistema, quines dades es conserven, quin component suporta el còmput i com evoluciona la pipeline amb el temps.

Puc barrejar ETL i ELT en la mateixa arquitectura?

Sí. De fet, és força comú. Moltes arquitectures modernes carreguen la dada bruta al warehouse, però apliquen algunes transformacions prèvies en origen o en una capa intermèdia quan hi ha restriccions específiques.

Quines eines solen aparèixer en aquest tipus de pipelines?

Depèn del sistema. És habitual veure orquestradors com Airflow, connectors d’ingestió com Fivetran o Stitch, motors de transformació com dbt i processament programàtic amb Python, pandas o SQL. L’eina no defineix per si sola l’enfocament; el defineix el lloc on es transforma la dada.