O que são ETL e ELT: conceitos fundamentais
ETL significa Extrair, Transformar e Carregar (Extract, Transform, Load). Nesse modelo, os dados passam por uma etapa de transformação antes de chegarem ao sistema de destino. ELT inverte essa ordem: os dados são Extraídos, Carregados e então Transformados, com a transformação acontecendo dentro do próprio destino.
A diferença central não está no que é feito, mas em onde e quando a transformação ocorre. No ETL, existe uma camada intermediária que processa os dados. No ELT, o destino assume esse trabalho.
As duas abordagens resolvem o mesmo problema: integrar dados de múltiplas fontes em um repositório centralizado. A escolha entre elas depende de fatores como infraestrutura disponível, volume de dados, exigências de conformidade e maturidade da equipe.
Como funciona o ETL na prática
No ETL, uma camada intermediária, chamada de staging ou servidor de transformação, recebe os dados das fontes, aplica regras de limpeza, padronização e enriquecimento, e só então envia os dados prontos para o destino. O destino nunca vê dados brutos.
Essa separação permite aplicar testes de qualidade e validações antes que qualquer dado entre no ambiente analítico. Erros são capturados no meio do caminho, reduzindo o risco de contaminação do repositório de destino.
A exigência de infraestrutura dedicada para a transformação é o principal custo operacional do modelo. Quanto maior o volume de dados ou a complexidade das regras, mais recursos essa camada intermediária precisa.
ETL é mais indicado quando o volume de dados é controlado, quando há restrições sobre a exposição de dados brutos no destino ou quando o ambiente de destino tem capacidade de processamento limitada.
Como funciona o ELT na prática
No ELT, os dados brutos são carregados diretamente no data warehouse ou data lake. A transformação é executada depois, usando o processamento do próprio destino, que em plataformas cloud modernas é altamente paralelizado e elástico.
Data warehouses como BigQuery, Snowflake e Redshift foram projetados exatamente para esse modelo. Eles processam grandes volumes com consultas SQL distribuídas, o que torna a transformação no destino viável em escala.
Ferramentas como o dbt (data build tool) se tornaram referência na camada de transformação do ELT. Com dbt, as transformações são escritas em SQL com versionamento, testes e documentação, aproximando a engenharia de dados de práticas de desenvolvimento de software.
Os dados brutos ficam preservados no destino. Se as regras de negócio mudarem, é possível reprocessar a transformação sem precisar extrair os dados novamente das fontes originais.
ETL vs ELT: comparativo direto
Velocidade de ingestão
ELT tende a ser mais rápido na etapa de ingestão porque elimina o processamento intermediário antes do carregamento. Os dados chegam ao destino com menos latência. No ETL, a transformação adiciona tempo antes que os dados estejam disponíveis para consumo.
Escalabilidade
ELT escala de forma mais natural em ambientes cloud. O processamento do destino cresce conforme a demanda, sem necessidade de redimensionar uma camada intermediária separada. No ETL, o servidor de transformação pode se tornar um gargalo em picos de volume.
Qualidade de dados
ETL oferece controle mais rígido: as transformações e validações acontecem antes da carga, impedindo que dados com problemas entrem no destino. No ELT, a qualidade precisa ser gerenciada dentro do destino, o que exige governança ativa, políticas de acesso e monitoramento contínuo.
Custo
ETL demanda infraestrutura dedicada para a camada de transformação. ELT transfere esse custo para o processamento no destino, cobrado em plataformas cloud por consulta ou por volume processado. Nenhum dos dois é universalmente mais barato; depende do padrão de uso.
Privacidade e segurança
ETL permite mascarar, anonimizar ou descartar dados sensíveis antes que eles cheguem ao ambiente analítico. No ELT, dados brutos, incluindo informações pessoais, ficam armazenados no destino, o que aumenta a superfície de exposição e exige controles adicionais.
Quando escolher ETL e quando escolher ELT
Prefira ETL quando:
- Há dados sensíveis que não devem ser armazenados brutos no destino, por exigência da LGPD, contratos ou políticas internas.
- O ambiente de destino é legado ou on-premise, com capacidade de processamento limitada para transformações pesadas.
- As regras de transformação são estáveis e bem definidas, com pouca necessidade de reprocessamento histórico.
Prefira ELT quando:
- O destino é um data warehouse cloud moderno com alta capacidade de processamento paralelo.
- A exploração dos dados brutos é necessária e o modelo analítico evolui com frequência.
- A equipe tem familiaridade com SQL avançado e práticas de engenharia de software para trabalhar com ferramentas como dbt.
Projetos que envolvem dados pessoais de clientes no Brasil merecem atenção redobrada. A LGPD impõe obrigações sobre coleta, armazenamento e acesso a dados pessoais. Carregar dados brutos com CPF, endereço ou comportamento de consumo diretamente em um data warehouse exige políticas claras de controle de acesso, catalogação e retenção, o que aumenta a complexidade do ELT nesses cenários.
Pontos de atenção antes de decidir
A escolha entre ETL e ELT não precisa ser binária. Arquiteturas híbridas são comuns em ambientes maduros: algumas fontes passam por transformação antes da carga (dados sensíveis, sistemas legados), enquanto outras alimentam diretamente o destino para transformação posterior.
Antes de assumir que ELT é mais barato, calcule o custo real de processamento no destino. Em plataformas que cobram por volume de dados lido nas consultas, transformações pesadas e recorrentes podem gerar custos expressivos.
A governança de dados brutos no ELT exige esforço consistente: catálogo de dados atualizado, controle granular de acesso por tabela e coluna, políticas de retenção e auditoria de quem acessa o quê. Sem isso, o destino vira um data swamp.
Ferramentas de orquestração, como Apache Airflow, Prefect ou Dagster, são relevantes nos dois modelos. A escolha do orquestrador é uma decisão independente e merece avaliação separada, considerando integração com as ferramentas já existentes no stack.
Como avaliar a melhor abordagem para o seu projeto
Use as perguntas abaixo como ponto de partida para estruturar a decisão:
- Os dados contêm informações pessoais sensíveis? Se sim, mapeie o que pode ou não ser armazenado bruto no destino antes de definir a arquitetura.
- Qual é o destino dos dados? Data warehouse cloud moderno favorece ELT. Ambientes on-premise ou destinos com capacidade limitada favorecem ETL.
- Com que frequência as regras de negócio mudam? Alta frequência de mudança favorece ELT, pela facilidade de reprocessamento sem nova extração.
- Qual é o nível de maturidade da equipe em SQL e engenharia de dados? ELT com dbt exige proficiência técnica que nem toda equipe tem hoje.
- O custo de processamento no destino foi estimado? Simule cenários reais de volume antes de assumir que ELT é a opção mais econômica.
Documente os critérios que levaram à decisão. À medida que o volume de dados cresce e a equipe amadurece, a arquitetura pode precisar evoluir, e ter o raciocínio registrado facilita revisões futuras sem retrabalho desnecessário.
