ETL vs ELT: diagramas de pipeline, trade-offs e quando usar cada um

O financeiro pede a receita por código de desconto dos últimos dois anos. Em uma empresa, isso é uma pequena mudança de SQL e uma reconstrução, porque toda linha de pedido já carregada continua em uma tabela bruta. Em outra, o job noturno nunca guardou a coluna de desconto, então alguém altera o job e reextrai dois anos de histórico da produção.

A diferença está em onde a transformação roda. O ETL (extract, transform, load) dá forma aos dados em um motor separado antes de chegarem ao warehouse. O ELT (extract, load, transform) copia os dados brutos para o warehouse e dá forma a eles lá com SQL. Essa escolha define sua conta de computação, quão frescos os dados ficam, quão fácil é mudar a lógica e onde os dados pessoais vão parar.

Este post percorre os dois pipelines, compara os dois, mostra onde o ETL ainda vence e o híbrido comum, e termina com um diagrama lado a lado.

Como funciona um pipeline ETL

No ETL, um motor de transformação fica entre as fontes e o warehouse. Uma execução noturna:

1. Extrai linhas novas e alteradas, com uma consulta em uma coluna updated_at ou a partir de um fluxo de change data capture.
2. Transforma essas linhas no motor: limpa valores, remove duplicatas, junta dados de referência, mascara dados pessoais e remodela o resultado em tabelas de fatos e dimensões.
3. Carrega o resultado no warehouse com inserts ou merges.

O motor pode ser Informatica, SQL Server Integration Services (SSIS), um job Spark ou um script Python. Os extratos brutos costumam ficar em uma área de staging que o job limpa depois de uma execução bem-sucedida, então o warehouse não consegue responder a uma pergunta que o job não previu.

Como funciona um pipeline ELT

No ELT, o warehouse faz o trabalho de transformação:

1. Extração e carga. Um loader como Fivetran ou Airbyte copia as tabelas de origem para um schema raw quase sem alterações, adicionando colunas de metadados como _fivetran_synced ou _airbyte_extracted_at que registram quando cada linha foi sincronizada.
2. Transformação. Modelos SQL, geralmente gerenciados com dbt, leem as tabelas brutas e constroem tabelas limpas e unidas em outros schemas.
3. Entrega. Ferramentas de BI consultam as tabelas finais, normalmente chamadas de marts.

O ELT se espalhou com os warehouses em nuvem que separam armazenamento de computação, como BigQuery e Snowflake: manter cópias brutas é barato e a capacidade de transformação escala com o warehouse. Como toda linha carregada permanece, você pode corrigir um modelo, adicionar uma coluna ou definir uma nova métrica e reconstruir a partir do histórico sem tocar na origem.

ETL vs ELT comparados

Os agendamentos importam mais que a sigla: a sincronização padrão do Fivetran roda a cada seis horas, o que é menos fresco que um job ETL de hora em hora.

Quando o ETL ainda vence

• Dados pessoais não podem chegar brutos. Se e-mails ou números de cartão em texto puro nunca devem chegar ao warehouse, mascare-os antes da carga. As políticas de mascaramento do warehouse não mudam o que é armazenado: o Dynamic Data Masking do Snowflake, um recurso da edição Enterprise, mascara valores em texto puro no momento da consulta.
• O destino não consegue transformar. Um warehouse legado de capacidade fixa, um índice de busca ou um arquivo entregue por um parceiro esperam dados prontos.
• Enriquecimento que o SQL trata mal, como chamadas de API por linha, geocodificação, leitura de PDF ou scoring com modelos, muitas vezes se encaixa melhor em Python ou Spark.
• Streaming com latência apertada. Apache Flink ou Kafka Streams transformam eventos segundos depois de acontecerem; o diagrama de arquitetura do Kafka mostra de onde eles leem.
• Volume que você não quer guardar. 10.000 sensores com uma leitura por segundo produzem 864 milhões de linhas por dia (10.000 × 86.400). Médias de um minuto calculadas antes da carga reduzem isso para 14,4 milhões (10.000 × 1.440), 60 vezes menos.

O híbrido comum

Na prática, muitos pipelines ELT incluem uma pequena transformação antes da carga, às vezes escrita EtLT. Transforme em trânsito apenas o que nunca deve chegar bruto; faça todo o resto no warehouse, onde é versionado, testado e fácil de reconstruir.

Para dados pessoais, o column hashing do Fivetran aplica hash em uma coluna durante a sincronização com SHA-256 e um salt por destino, então e-mails com hash ainda permitem joins; o data blocking descarta uma coluna por completo. Os mappings do Airbyte podem aplicar hash ou criptografar campos por stream. Seja qual for a ferramenta, prefira um hash com salt: um SHA-256 simples de um e-mail pode ser comparado com uma lista de endereços conhecidos. Duas ressalvas a mais: o hash cobre as sincronizações futuras, então o histórico exige uma nova sincronização, e um hash com salt é pseudônimo, não anônimo. Pelo GDPR, dados pseudonimizados continuam sendo dados pessoais (considerando 26). Este post não é aconselhamento jurídico; leia o texto oficial com sua equipe de privacidade e mantenha um mapa de dados de por onde os dados pessoais fluem.

ELT com modelos SQL em camadas

O guia de estrutura de projeto do dbt descreve três camadas que funcionam com qualquer ferramenta SQL:

Os lakehouses usam a mesma ideia com os nomes bronze, silver e gold; veja o diagrama de arquitetura medallion.

O dbt traz quatro testes de dados genéricos, unique, not_null, accepted_values e relationships, e qualquer consulta que retorne linhas com falha pode virar um teste. As verificações de freshness pegam um loader que parou em silêncio. Uma única definição de source declara os dois:

sources:
  - name: shop
    schema: raw_shop
    config:
      loaded_at_field: _fivetran_synced
      freshness:
        warn_after: {count: 12, period: hour}
        error_after: {count: 24, period: hour}
    tables:
      - name: orders
        columns:
          - name: id
            data_tests:
              - unique
              - not_null

dbt source freshness (ou dbt freshness no dbt v2) emite um aviso quando o valor mais recente de _fivetran_synced tem mais de 12 horas e reporta erro após 24.

Orquestração e qualidade de dados

Um orquestrador executa as etapas em ordem. No Airflow, um DAG (tarefas com dependências e um agendamento) dispara a sincronização do loader, espera por ela e depois roda o dbt. A integração do Dagster com o dbt transforma cada modelo dbt em um asset, uma tabela que deveria existir, então um mart pode depender diretamente da tabela que uma sincronização do Fivetran escreve.

De qualquer forma, o dbt build mantém dados ruins fora dos dashboards: ele roda modelos, testes, snapshots e seeds na ordem do DAG, e um teste com falha pula tudo o que vem depois. Adicione verificações de freshness e um alerta para a equipe responsável, e tanto dados errados quanto dados velhos aparecem antes que um stakeholder perceba.

O Reverse ETL, que o Airbyte chama de data activation, roda no sentido contrário: copia dados modelados do warehouse para ferramentas como um CRM ou um help desk. No momento em que escrevo (novembro de 2026), a Hightouch o oferece como produto independente, e a Fivetran (que adquiriu a Census) e o Airbyte o incluem junto com a ingestão.

O diagrama ETL vs ELT

Como ler:

• Duas faixas, mesmas pontas: o mesmo banco de pedidos Postgres e os mesmos dashboards de BI. Só o meio muda.
• O âmbar marca a transformação: um motor separado antes do warehouse no ETL, a caixa de modelos dbt dentro do warehouse no ELT.
• As molduras do warehouse mostram o que é armazenado. A do ETL guarda só fct_orders; a do ELT guarda raw.orders como foi carregado, os modelos e marts.fct_orders.
• A aresta roxa é o híbrido: o loader aplica hash nos dados pessoais antes de as linhas chegarem.
• O bloco Markdown lista a ordem de execução do ELT, os limites de freshness e qual schema o BI lê.

Desenhando diagramas ETL e ELT com clareza

• Coloque a transformação onde ela roda. Desenhar a transformação do ELT fora do warehouse esconde seu principal custo e risco.
• Desenhe o warehouse como uma fronteira. Raw, staging e marts dentro de uma moldura são schemas em um só sistema, não bancos separados.
• Rotule as arestas com o que se move (linhas brutas, linhas com hash, tabelas construídas) e com o agendamento quando importar.
• Marque onde os dados pessoais são mascarados e onde ainda existem em texto puro.
• Mostre camadas, não cada modelo. Uma tabela de exemplo por camada basta; a linhagem pertence à documentação gerada pelo dbt.
• Mantenha o fluxo de controle separado. Desenhe os gatilhos do orquestrador como arestas tracejadas para que ninguém os confunda com dados.

O diagrama de arquitetura de pipeline de dados mostra um pipeline completo com CDC, Kafka e um warehouse.

Monte no Archboard

1. Entre com Google ou GitHub e crie um diagrama.
2. Adicione dois nós Moldura do pacote Básico, um acima do outro, para as faixas ETL e ELT, e uma Moldura aninhada para o warehouse em cada faixa, na mesma posição horizontal.
3. Na faixa ETL, adicione um nó Postgres do pacote Dados, uma Caixa do Básico para o motor de transformação, um nó Armazém de dados do pacote Dados para fct_orders dentro da moldura do warehouse, e uma Caixa do Básico para o BI. Rotule as arestas: raw rows, cleaned and conformed rows, SQL queries.
4. Na faixa ELT, adicione um nó Postgres e uma Caixa do Básico para o loader. Dentro da moldura do warehouse, adicione nós Armazém de dados para raw.orders e marts.fct_orders, com uma Caixa do Básico para os modelos dbt entre eles. Termine com uma Caixa do Básico para o BI e rotule as arestas do mesmo jeito.
5. Pinte as duas caixas de transformação de âmbar e a aresta de saída do loader de roxo. Adicione notas de Texto do Básico sob os nós que precisam de explicação e uma legenda curta de cores.
6. Adicione um bloco Markdown do pacote Básico com a ordem de execução e os limites de freshness.

Se o pipeline já existe como fluxograma Mermaid, cole-o na ferramenta de Mermaid para diagrama editável para obter um primeiro rascunho. O exemplo usa 15 nós de diagrama e fica dentro do plano Free.

Perguntas frequentes

Qual é a diferença entre ETL e ELT? Onde a transformação roda. O ETL transforma os dados em um motor separado e carrega só o resultado. O ELT carrega primeiro os dados brutos no warehouse e os transforma lá com SQL, então a cópia bruta continua disponível para reconstruções.

O ETL está ultrapassado? Não. O ELT é o padrão habitual em warehouses em nuvem, mas o ETL ainda se encaixa quando dados pessoais precisam ser mascarados antes de chegar, quando o destino não consegue transformar, e para enriquecimento pesado ou streaming de baixa latência.

O dbt é uma ferramenta de ETL? O dbt cobre o T do ELT. Ele roda modelos SQL e testes dentro do seu warehouse, mas não extrai nem carrega dados; um loader como Fivetran ou Airbyte faz isso.

O ELT é mais barato que o ETL? Depende do volume e dos hábitos. O ELT elimina o motor separado, mas cobra cada execução de modelo como computação do warehouse e armazena cópias brutas. Modelos incrementais mantêm os custos baixos; reconstruções completas de hora em hora de tabelas grandes, não.

O que é reverse ETL? Copiar dados modelados do warehouse para ferramentas operacionais como um CRM. Ele deve ler dos marts, rodar em um agendamento e ter os mesmos testes e responsáveis que qualquer outro pipeline.

Comece grátis — um assento, sem cartão de crédito.