- ETL e ELT não são só siglas diferentes — representam filosofias opostas de onde a transformação de dados acontece, com implicações diretas em custo, manutenção e latência.
- A maioria dos projetos modernos usa ELT por default, mas há casos onde ETL ainda é a escolha certa — conhecer a diferença evita decisões arquiteturais caras de reverter.
- Um pipeline de dados confiável não é só código: é observabilidade, alertas de falha, testes de qualidade e documentação que permitem que o time de negócio confie nos dados.
O pipeline que ninguém vê — até quebrar
Pipelines de dados são a infraestrutura invisível que sustenta todo relatório, todo dashboard e toda decisão baseada em dados. Quando funcionam, ninguém os nota. Quando falham — e eventualmente todos falham — o problema se manifesta como "os números estão errados" ou "o relatório não atualizou", tipicamente descoberto às 8h de uma segunda-feira por um diretor em reunião.
Construir pipelines robustos exige entender não só o código, mas os trade-offs entre as abordagens possíveis. ETL, ELT, streaming, batch — cada padrão resolve um conjunto diferente de problemas e cria um conjunto diferente de custos de manutenção.
Este guia desmistifica esses conceitos para quem contrata, gerencia ou supervisiona projetos de dados — sem assumir background técnico profundo.
ETL vs. ELT: a diferença que importa
ETL (Extract, Transform, Load) e ELT (Extract, Load, Transform) descrevem a ordem em que as três operações fundamentais de integração de dados acontecem. A diferença parece pequena — mover uma letra — mas tem implicações arquiteturais significativas.
ETL: extrair dados da fonte, transformá-los em um servidor intermediário (ETL server), carregar os dados já transformados no destino. Prevalente antes do cloud — quando armazenamento era caro, fazia sentido transformar antes de carregar para não guardar "lixo".
ELT: extrair dados da fonte, carregar os dados brutos no destino (data warehouse na nuvem), transformar usando o poder de processamento do próprio warehouse. Padrão moderno — armazenamento em nuvem é barato, e warehouses como BigQuery e Snowflake têm enorme capacidade de processamento distribuído.
A implicação prática: no ELT, os dados brutos ficam armazenados no warehouse, permitindo re-transformação a qualquer momento se as regras de negócio mudarem. No ETL, os dados brutos são descartados — se a transformação estava errada, é necessário reextrair da fonte.
ETL vs. ELT: comparativo técnico
| Dimensão | ETL | ELT |
|---|---|---|
| Onde transforma | Servidor intermediário (ETL engine) | No próprio data warehouse |
| Armazena dados brutos | Não (apenas dados transformados) | Sim (raw + transformado) |
| Custo de armazenamento | Menor (apenas dados limpos) | Maior (brutos + transformados) |
| Flexibilidade de re-transformação | Baixa (requer reextração) | Alta (dados brutos sempre disponíveis) |
| Latência típica | Maior (transformação antes de carga) | Menor (carga rápida, transformação asíncrona) |
| Adequado para | Dados sensíveis que não podem ser armazenados brutos; sistemas legados | Cloud-native; data warehouse moderno |
| Exemplos de ferramentas | Informatica, SSIS, Talend | Airbyte + dbt, Fivetran + dbt |
Quando usar ETL e quando usar ELT
Use ELT quando: a empresa já usa ou planeja usar um data warehouse moderno em nuvem; quando flexibilidade para re-transformar dados históricos é importante; quando o volume de dados é grande e o warehouse oferece mais poder de processamento que um servidor ETL; quando a equipe é familiarizada com SQL e dbt.
Use ETL quando: há restrições legais ou de compliance que impedem armazenar dados brutos no warehouse (ex.: dados de saúde com PII que não podem ser carregados sem mascaramento; dados financeiros sujeitos a regulações específicas); quando a fonte de dados é um sistema legado que exige transformação pesada antes da carga; quando o warehouse destino é antigo e não tem capacidade de processamento suficiente.
Na prática, 80%+ dos novos projetos de dados em empresas que adotam cloud usam ELT. O ETL puro é cada vez mais um padrão legado — exceto nos casos de compliance acima.
Anatomia de um pipeline moderno
Um pipeline de dados moderno tem quatro componentes principais:
1. Ingestão (Extract + Load): responsável por conectar-se às fontes de dados e carregar os dados brutos no warehouse. Pode ser uma ferramenta de conector gerenciado (Airbyte, Fivetran) ou scripts customizados em Python/SQL.
2. Transformação (Transform): converte dados brutos em modelos de negócio úteis — joins entre tabelas, cálculo de métricas, limpeza, deduplicação. dbt é o padrão de mercado para essa camada.
3. Orquestração: garante que as etapas do pipeline rodem na ordem certa, no horário certo, e reprocessa automaticamente em caso de falha. Airflow, Prefect e Dagster são as opções mais comuns.
4. Observabilidade: monitora a saúde do pipeline — alertas de falha, métricas de frescor dos dados, testes de qualidade. Elementary (open-source) e Monte Carlo são ferramentas especializadas.
Ferramentas de ingestão: comparativo
| Ferramenta | Tipo | Conectores | Custo | Melhor para |
|---|---|---|---|---|
| Airbyte | Open-source + Cloud | 300+ conectores | Gratuito (self-hosted) ou ~US$300/mês (Cloud) | PMEs que querem controle; budgets limitados |
| Fivetran | SaaS | 300+ conectores | Pay per MAR (monthly active rows) | Times que não querem gerenciar infraestrutura |
| Stitch | SaaS | 100+ conectores | Plano gratuito; pago a partir de US$100/mês | PMEs com necessidades simples |
| dlt (data load tool) | Open-source Python library | Customizável | Gratuito | Engenheiros que preferem código sobre UI |
| Scripts customizados | Código próprio | Ilimitado | Custo de desenvolvimento | Fontes sem conector; lógica de extração complexa |
Transformação com dbt: o padrão de mercado
dbt (data build tool) tornou-se o padrão de mercado para a camada de transformação em arquiteturas ELT. Entender o que ele faz — e o que não faz — é essencial para qualquer projeto de dados moderno.
O que o dbt faz: converte SQL em modelos documentados, testados e versionados. Cada modelo dbt é um arquivo `.sql` que define uma tabela ou view no warehouse. O dbt compila esses modelos, resolve dependências (o grafo de modelos), executa no warehouse e gera documentação automática com lineage.
Testes nativos: o dbt tem testes built-in para validar dados — `not_null`, `unique`, `accepted_values`, `relationships`. Esses testes rodam após cada transformação e alertam quando os dados violam as expectativas.
Documentação automática: o comando `dbt docs generate` cria um site estático com o catálogo de todos os modelos, seus campos, descrições e o grafo de dependências. Isso resolve o problema de documentação de dados que equipes costumam ignorar.
O que o dbt não faz: ingestão de dados (não conecta às fontes), orquestração (não agenda execuções — precisa de Airflow ou Prefect para isso), streaming (é um sistema batch).
Pipeline moderno típico: Airbyte + dbt + Airflow + BigQuery
Conectores gerenciados extraem dados de Salesforce, PostgreSQL, Google Analytics, Shopify etc. e carregam as tabelas brutas no BigQuery (camada raw).
Modelos dbt limpam, juntam e agregam as tabelas brutas, criando tabelas staging, intermediate e marts documentadas e testadas.
DAGs do Airflow disparam o Airbyte e o dbt na sequência correta, monitoram o status de cada etapa e enviam alertas por Slack/e-mail em caso de falha.
Power BI, Looker Studio ou Metabase conectam-se às tabelas marts no BigQuery — dados confiáveis, documentados e sempre frescos para análise de negócio.
Observabilidade: como saber que o pipeline está funcionando
Um pipeline sem observabilidade é um pipeline que falha em silêncio. A observabilidade responde três perguntas continuamente:
Fresquidade (freshness): os dados foram atualizados no horário esperado? Uma tabela que deveria ser atualizada às 6h ainda com dados de D-2 às 9h é uma anomalia que precisa de alerta automático.
Qualidade: os dados atendem às expectativas de negócio? Volume de registros inesperadamente baixo (possível falha de ingestão), nulos em campos obrigatórios, distribuições fora do padrão histórico.
Linhagem (lineage): quando um problema é detectado, consegue-se rastrear de onde ele veio? A linhagem permite identificar rapidamente qual modelo dbt, qual pipeline de ingestão ou qual fonte de dados é a origem do problema.
Ferramentas como Elementary (open-source, integra nativo com dbt), Monte Carlo e Soda oferecem monitoramento de qualidade de dados. Para equipes pequenas, testes do próprio dbt + alertas de falha no Airflow cobrem 80% das necessidades.