ETL ou ELT num time de porte médio, e como saber qual você precisa
ELT é o conselho padrão e nem sempre está certo. Onde cada padrão cabe, o que a conta do data warehouse esconde e a restrição que decide por você.
A resposta moderna é ELT: carrega o dado cru no data warehouse primeiro e transforma lá dentro com SQL. Armazenamento é barato, processamento é elástico, e lógica de transformação em SQL é mais fácil de revisar do que um pipeline dentro da ferramenta de ETL de alguém.
Essa resposta está certa com frequência suficiente para ser um padrão razoável. Não está sempre certa, e os casos em que falha são previsíveis.
A diferença de verdade
Os dois padrões extraem das fontes e entregam dado analisável. A questão é onde a transformação acontece e o que fica guardado no caminho.
ETL transforma antes de carregar. O warehouse recebe o dado já moldado. O dado cru ou não é retido, ou vive fora do warehouse.
ELT carrega cru e depois transforma dentro do warehouse, em camadas. O dado cru fica retido, então dá para reprocessar quando uma transformação se mostra errada.
Essa última propriedade é por que o ELT venceu em analytics. Transformações estão sempre erradas em algum momento, e reprocessar a partir do cru retido é muito mais barato do que pedir dois anos de histórico de volta ao sistema de origem.
| Restrição | Padrão | Por quê |
|---|---|---|
| Dado regulado que não pode pousar cru | ETL | Mascarar ou tokenizar antes da carga é requisito, não preferência |
| Analytics sobre dado de negócio, fontes cooperativas | ELT | Dado cru retido torna reprocessamento barato e erros recuperáveis |
| Fonte só exporta arquivos à noite | Qualquer um | A janela de lote decide o frescor, não o padrão |
| Frescor abaixo de um minuto | Nenhum: streaming | Os dois padrões são de lote; forçá-los aqui produz sistema frágil |
| O gargalo de orçamento é o warehouse | ETL | Transforme onde o processamento custa menos que o do warehouse |
| Lógica de transformação muda com frequência | ELT | SQL versionado ganha de reconfigurar uma ferramenta de pipeline |
A conta que ninguém prevê
O ELT move custo de tempo de engenharia para processamento de warehouse, e processamento de warehouse é medido.
O padrão que produz faturas surpresa é direto: uma camada de transformação que reconstrói tudo a partir do cru a cada execução, agendada de hora em hora, sobre uma tabela que cresce. Funciona bem no primeiro mês e custa dinheiro de verdade no sexto, sem que nada no código tenha mudado.
Três hábitos mantêm isso sob controle:
- Modelos incrementais por padrão. Reconstrução total deve ser escolha deliberada com um motivo, não o padrão que ninguém revisitou.
- Particione e agrupe pelo que você filtra. A maior parte do custo de warehouse é varrer dado que a consulta não precisava.
- Atribua custo por modelo. Se você não enxerga qual transformação custa mais, não consegue otimizar a que importa.
Onde os times realmente travam
Na prática, nenhum dos dois padrões é a parte difícil. Três outras coisas são.
Extração de fontes não cooperativas. Uma fonte sem API, sem captura de mudanças e sem coluna confiável de atualização determina o seu desenho inteiro. Você vai consultar e comparar, receber arquivos ou ler uma réplica. Esse é o trabalho de verdade, e é por isso que às vezes cabe uma camada anticorrupção na frente da fonte.
Mudança de esquema. Alguém acrescenta uma coluna, renomeia outra ou muda um tipo lá em cima. Sem testes de contrato na fonte, isso aparece como painel silenciosamente errado, e não como job que falhou.
Posse da camada semântica. "Cliente ativo" significa uma coisa para o financeiro e outra para vendas. Essa divergência não se resolve com padrão nenhum; resolve-se nomeando um dono para cada definição. Pipelines que pulam essa etapa produzem números todos defensáveis e mutuamente inconsistentes.
Um padrão razoável para um time de porte médio
Se nada na tabela de restrições força a sua mão:
- Carregue cru no warehouse, retido, particionado por data de ingestão.
- Transforme em SQL versionado, com camadas separando cru, limpo e definições de negócio.
- Rode testes sobre as tabelas de saída, não sobre o pipeline: unicidade, não nulo, integridade referencial, variação de contagem.
- Alerte por frescor, não só por falha. Um job que silenciosamente parou de rodar parece idêntico a um sem dado novo.
- Mascare ou tokenize campos regulados na ingestão, antes de pousarem, que é onde isso vira ETL para um subconjunto de colunas, discretamente.
Esse último ponto é a resposta prática na maioria dos ambientes regulados: ELT para a maior parte do dado, ETL para as colunas que não podem pousar cruas. Quais colunas são essas, se você lida com dado de saúde, decorre das salvaguardas técnicas.
Se o "pipeline" proposto é na verdade um robô lendo telas porque a fonte não tem interface, a decisão é outra: veja RPA ou integração por API.
Isso é o miolo do nosso trabalho de dados e operações com IA, e como tratamos acesso a dado de cliente está nas práticas de segurança.