ETL versus ELT: onde a transformação é executada e o que isso muda

O que é

A página citada do Azure Architecture Center descreve o ETL (extract, transform, load) como um processo de integração de dados que consolida dados de fontes diversas em um armazenamento unificado. A fase de transformação é executada por um motor especializado, muitas vezes por meio de tabelas de staging, e as operações típicas são filtrar, ordenar, agregar, juntar, limpar, deduplicar e validar. A página afirma que o ELT (extract, load, transform) difere do ETL somente quanto ao lugar em que a transformação acontece: no pipeline ELT, ela ocorre no armazenamento de dados de destino, usando a capacidade de processamento desse próprio armazenamento em vez de um motor separado. Segundo a página, isso elimina o motor de transformação da arquitetura, e escalar o armazenamento de destino também escala o pipeline; o ELT, porém, só funciona bem quando o sistema de destino é potente o bastante para transformar os dados com eficiência. Ferramentas como o dbt ficam no T do ELT; sua documentação o descreve como uma ferramenta que transforma dados brutos do warehouse em produtos de dados confiáveis.

Por que importa

A ordem das letras muda quatro coisas na prática. Onde a computação é cobrada: no ELT, paga-se com tempo de consulta no warehouse; no ETL, com um cluster ou serviço separado. O que chega bruto: o ELT copia as tabelas de origem como elas são, de modo que as decisões de minimização de dados precisam ser tomadas na extração ou por controle de acesso no warehouse. Como funcionam as reexecuções: uma transformação ELT é uma consulta sobre dados que continuam lá, então corrigir algo significa reexecutar SQL; uma correção no ETL pode exigir reextrair dados de uma fonte que mudou desde então. Quem pode alterar a lógica: o SQL no warehouse é legível por analistas; o código em um motor separado pertence a quem opera esse motor.

Como aplicar

• Escolha ELT quando o destino for um warehouse colunar ou lakehouse que já dá conta do volume de dados e as transformações puderem ser expressas em SQL sobre tabelas carregadas.
• Escolha ETL, ou uma etapa de transformação antes da carga, quando a fonte contiver dados que nunca devem chegar ao destino (segredos, campos excluídos por política), quando o destino for um pequeno banco de dados operacional ou quando a transformação exigir código ou bibliotecas que o destino não consegue executar.
• Em ambos os casos, mantenha a extração bruta imutável e separada das saídas transformadas, para que uma transformação possa ser reproduzida a partir da mesma entrada.
• Registre, para cada tabela de saída, qual snapshot da fonte e qual versão da transformação a produziram.

Armadilhas

Carregar tudo bruto e adiar a modelagem produz um warehouse que só o seu autor consegue consultar. Os custos do ELT crescem conforme a frequência com que os modelos são reconstruídos por completo; modelos incrementais exigem a disciplina de idempotência descrita no artigo relacionado. Em designs mistos, com parte da limpeza antes da carga e parte depois, é preciso documentar o que é feito em cada etapa; caso contrário, uma regra de deduplicação acaba aplicada duas vezes ou nenhuma.