ETL vs ELT: diferenças no processamento de dados

Numa review de arquitetura, alguém perguntou por que o pipeline de dados estava carregando arquivos brutos direto no warehouse antes de transformar. A resposta foi "é ELT, não ETL". O silêncio na sala deixou claro que metade do time nunca tinha parado pra pensar na diferença — e que a outra metade achava que era só uma questão de ordem das letras.

Não é. A ordem importa, e a decisão errada pode custar semanas de retrabalho quando o volume escala.

A diferença que importa na prática

ETL — Extract, Transform, Load — é o modelo clássico. Você extrai os dados da fonte, os transforma numa camada intermediária (geralmente um servidor de processamento dedicado), e só então carrega o resultado limpo e estruturado no destino final.

ELT — Extract, Load, Transform — inverte as últimas etapas. Você extrai os dados e os carrega crus no destino, e a transformação acontece dentro do próprio warehouse, usando o poder computacional dele.

A diferença prática não é filosófica. É sobre onde a computação pesada acontece: num servidor de ETL intermediário ou dentro do banco/warehouse de destino.

ETL: Fonte → [Servidor ETL: transforma] → Warehouse (dados limpos)
ELT: Fonte → Warehouse (dados brutos) → [Warehouse: transforma no lugar]

Por que ETL dominou por tanto tempo

ETL foi a resposta natural quando warehouses eram caros e computacionalmente limitados. Armazenamento em Oracle ou Teradata custava caro por GB, e deixar dados sujos lá era desperdício de dinheiro real. Fazia sentido pré-processar num servidor dedicado antes de persistir.

A transformação no ETL era feita por ferramentas como Informatica, SSIS ou código Python customizado. O dado que chegava no warehouse era como um produto acabado: validado, tipado, com schema definido, pronto para queries analíticas.

O problema: a lógica de transformação fica num lugar separado do dado. Quando a regra de negócio muda — e ela sempre muda — você altera o código de ETL, reprocessa o histórico, e torce pra que a janela de manutenção caiba no SLA.

Por que ELT faz mais sentido em pipelines modernos

A virada veio com o BigQuery, o Redshift e o Snowflake. Warehouses modernos são elásticos, escalam computação separado de storage, e cobram por query executada — não por GB armazenado a preço proibitivo. O custo de armazenar dados brutos caiu drasticamente.

Com isso, carregar primeiro e transformar depois passou a ser mais barato e mais flexível:

Você preserva os dados originais. Se a lógica de transformação estiver errada, você não perdeu o dado bruto. Você reescreve a transformação e reprocessa do zero sem precisar ir buscar na fonte original de novo.

A transformação usa o poder do warehouse. Um cluster Snowflake ou BigQuery tem poder computacional que nenhum servidor ETL dedicado vai bater com custo equivalente. Agregações em bilhões de linhas são o que eles fazem bem.

Iteração mais rápida. Com ferramentas como dbt, a transformação é SQL versionado em Git. Você muda uma lógica, faz dbt run, e em minutos tem o resultado atualizado sem deploy de servidor.

Quando ETL ainda faz sentido

ELT não é sempre a resposta certa. Tem casos onde a transformação precisa acontecer antes do load:

Conformidade e privacidade (LGPD, GDPR). Se os dados brutos contêm PII — CPF, número de cartão, dados de saúde — você pode não ter permissão legal para carregar isso num warehouse antes de anonimizar ou mascarar. Nesse caso, a transformação tem que vir antes.

Fontes heterogêneas com schemas incompatíveis. Quando você está agregando dezenas de fontes com formatos completamente diferentes (arquivos flat, APIs REST, FTP legado), um servidor ETL intermediário pode fazer mais sentido do que tentar resolver tudo dentro do warehouse com SQL.

Volume muito baixo com warehouse caro. Para pipelines pequenos que rodam contra um banco de produção pago por query ou por processamento, transformar antes de carregar pode ser mais barato.

Latência baixa requerida. ETL com transformações leves e bem otimizadas pode ser mais rápido que o ciclo load-then-transform do ELT quando você precisa de dados prontos em segundos, não minutos.

O modelo híbrido que aparece na prática

Pipelines reais raramente são ETL puro ou ELT puro. O que você encontra em produção é mais parecido com isso:

1. Extract: coleta dos dados da fonte (API, banco OLTP, arquivos)
2. Light transform: limpeza mínima necessária — encoding, deduplicação de chaves, mascaramento de PII
3. Load raw: carga na camada raw/landing do warehouse
4. Heavy transform: transformações analíticas dentro do warehouse via dbt ou SQL nativo

Esse modelo fica popularizado com arquiteturas como Medallion (Bronze/Silver/Gold) no Databricks ou as camadas staging/marts do dbt. O dado bruto preservado na camada Bronze/raw serve de ponto de reprocessamento, e as camadas superiores são visões materializadas com lógica crescente de refinamento.

-- Exemplo de transformação dbt na camada silver
-- O dado bruto já está no warehouse, a lógica fica em SQL versionado

SELECT
    order_id,
    customer_id,
    -- normaliza o valor que vinha como string na fonte
    CAST(REPLACE(raw_amount, ',', '.') AS DECIMAL(10,2)) AS amount,
    -- padroniza timezone
    CONVERT_TIMEZONE('UTC', order_ts) AS order_utc
FROM raw.orders
WHERE order_id IS NOT NULL

O papel das ferramentas modernas nessa escolha

A popularização do ELT deve muito ao dbt (data build tool). Antes do dbt, fazer ELT significava SQL manual sem versionamento, sem testes, sem documentação. O dbt trouxe as práticas de engenharia de software — Git, CI, testes — para as transformações SQL.

Ferramentas de extração como Airbyte, Fivetran e Stitch automatizaram o Extract+Load, deixando o Transform como a única parte que precisa de código customizado. O pipeline vira: Airbyte faz EL, dbt faz T.

Isso não quer dizer que ETL morreu. Ferramentas como Apache Spark, Flink e frameworks de streaming ainda fazem transformações pesadas antes do load quando o caso pede — especialmente em pipelines de streaming em tempo real onde você precisa enriquecer ou agregar eventos antes de persistir.

Quando ELT escala mal

Tem um problema que pouca gente menciona em posts sobre ELT: se você carregar dados brutos sem nenhum controle de qualidade, o warehouse vira um data swamp. Tabelas raw com schemas inconsistentes, duplicatas, valores nulos onde não deveriam existir — e toda a lógica de limpeza espalhada em dezenas de modelos dbt sem documentação.

A disciplina que o ETL forçava (transformar antes de persistir) tinha um efeito colateral positivo: erros de dados eram detectados antes de entrar no warehouse. Com ELT, a detecção precisa ser explícita — testes dbt, contratos de dados, validações no pipeline de extração.

ELT com disciplina é melhor que ETL. ELT sem disciplina é pior que qualquer alternativa.

Perguntas frequentes

ETL ou ELT — qual é mais rápido para implementar?

Depende do contexto. Para um pipeline simples com uma fonte e um destino já definidos, ELT com Airbyte + dbt pode estar rodando em horas. Para integrar dezenas de fontes heterogêneas com regras de negócio complexas, ETL com transformação customizada pode ser mais rápido de manter no médio prazo — especialmente quando o time conhece melhor Python ou Java do que SQL analítico.

Posso usar dbt com ETL?

Dbt é uma ferramenta de transformação SQL que roda dentro do warehouse. Por definição, ele opera no modelo ELT — os dados precisam estar no warehouse antes de você rodar dbt run. Usar dbt implica adotar ELT, pelo menos na etapa de transformação.

O que é EtLT?

É um termo que aparece em arquiteturas que fazem uma transformação leve antes do load (mascaramento de PII, deduplicação) e depois transformações analíticas completas dentro do warehouse. É o modelo híbrido descrito acima com nome próprio. A maioria dos pipelines de produção é EtLT na prática, mesmo quando a equipe não usa esse termo.

Preciso de um servidor dedicado para ETL?

Não necessariamente. ETL pode rodar em Lambda/Cloud Functions para volumes menores, ou em containers orquestrados por Airflow/Prefect para volumes maiores. O servidor dedicado de ETL foi necessário numa época de infraestrutura menos elástica. Hoje, a computação de transformação pode ser serverless ou containerizada sem custo fixo.

Arquitetura certa depende do seu warehouse, não da sigla

A pergunta "ETL ou ELT?" é menos importante do que "onde minha computação de transformação é mais barata, mais manutenível e mais confiável?". Se o warehouse tem poder computacional elástico e o time conhece SQL — ELT com dbt é a escolha óbvia hoje. Se os dados têm restrições de privacidade severas ou as fontes são caóticas demais para carregar cru — ETL ou o modelo híbrido faz mais sentido.

O que não existe mais é uma resposta universal. ETL não é legado e ELT não é moderno por si só. São ferramentas, e como toda ferramenta, o valor depende do uso.

Nota: o conteúdo editorial acabou aqui. O que vem abaixo é uma indicação de ferramenta relacionada ao tema do post.

Ferramenta relacionada

Pipelines ELT frequentemente envolvem inspeção de arquivos intermediários — CSVs exportados de fontes, JSONs de APIs, dumps de tabelas. O CSV para JSON do Quick Tools converte esses arquivos diretamente no navegador sem upload para servidor, útil para inspecionar amostras de dados antes de decidir o schema de carga no warehouse.