ETL moderno para empresas que não podem parar

ETL tradicional foi desenhado para uma realidade que já não existe: janela noturna de 4 horas, origens estáveis, tolerância a um dia de atraso. Operações modernas precisam de dados recém-atualizados durante o horário comercial — e qualquer interrupção gera um alerta no celular do CFO.

A arquitetura medallion em 3 camadas

Popularizado pela Databricks, o padrão medallion separa o pipeline em três camadas nomeadas por qualidade crescente de dado:

Bronze — ingestão bruta

Ingesta exatamente como o dado chega. Sem transformação, sem validação. A regra de ouro: bronze é fonte de verdade reprocessável. Se uma transformação mais à frente gerou erro, você volta ao bronze, corrige a lógica e reprocessa sem pedir nada à origem.

Na prática, em stack Azure: Azure Data Factory escreve arquivos Parquet em Azure Data Lake com particionamento por data de ingestão.

Silver — dados validados

Aplica deduplicação, tipagem explícita, validação contra schema esperado, e normalização de chaves. Silver é o nível onde times analíticos podem consultar com segurança. Dois princípios:

• Cada entidade tem schema documentado e versionado.
• Registros inválidos vão para uma tabela _rejects, nunca descartados silenciosamente.

Gold — modelos de negócio

Tabelas prontas para consumo — star schema para BI, views agregadas para dashboards, features para ML. Gold é desenhada para o caso de uso, não para refletir a origem. Evite a armadilha de criar uma "gold única" que vira um data mart genérico lento.

Ingestão incremental: o detalhe que decide

Full-load noturno é aceitável para volumes pequenos (≤10M de linhas). Acima disso, você precisa de ingestão incremental — e aqui é onde 70% dos pipelines falham. Três técnicas por ordem de preferência:

1. Change Data Capture (CDC)

Quando a origem suporta (SQL Server CDC, Azure SQL, Postgres logical replication), é o padrão ideal. Captura apenas linhas alteradas via log de transação, com impacto mínimo na origem. Azure Data Factory tem conectores CDC diretos.

2. Watermark de timestamp

A origem tem uma coluna updated_at confiável. Você persiste o último timestamp lido e traz apenas registros acima dele. Simples, barato, mas cuidado com dois falhos comuns:

• Registros deletados não são detectados (precisa de soft delete na origem).
• Relógio desalinhado entre origem e pipeline causa perda de linhas.

3. Hash de comparação

Última opção. Você hashea o conteúdo de cada linha e compara com o hash anterior. Funciona em fontes sem coluna de atualização, mas consome muito mais recurso. Reserve para tabelas pequenas/estáveis.

Observabilidade: o que você precisa saber às 9h da manhã

Pipeline sem observabilidade é uma aposta. Três sinais mínimos em um dashboard operacional:

• Frescor: idade do dado mais recente em cada tabela gold. Vermelho quando > SLA.
• Integridade: contagem de registros por dia vs baseline (±20% do histórico). Queda brusca = alerta.
• Completude: cobertura de chaves esperadas. Se esperava 400 lojas e vieram 380, onde estão as 20?

Ferramentas do ecossistema Microsoft: Azure Monitor + Log Analytics para runs, Power BI para o dashboard operacional, Microsoft Purview para lineage visual.

Governança leve que escala

• Catálogo de tabelas: dono, descrição, SLA, última auditoria. Microsoft Purview ou simples lista SharePoint no começo.
• Retenção explícita: bronze 90 dias, silver 2 anos, gold conforme negócio. Storage não é grátis.
• Deploy por ambiente: dev → staging → produção. Nunca editar pipeline direto em produção, mesmo para "ajuste rápido".

Quando modernizar (e quando não)

Nem toda empresa precisa de medallion completo. Sinais de que o stack tradicional ainda serve:

• Volume < 10M linhas/dia.
• Janela de processamento noturno comportável.
• Um único consumidor analítico.

Sinais de que é hora de modernizar:

• Relatórios chegando com atraso de 1 dia ou mais.
• Múltiplos consumidores (BI, ML, apps) pedindo os mesmos dados com regras conflitantes.
• ETLs noturnos excedendo a janela e roubando capacidade do dia seguinte.
• Impossibilidade de reprocessar histórico sem tocar na origem de produção.

Engenharia de dados madura não é a que usa a tecnologia mais nova — é a que oferece frescor, integridade e completude com SLA operacional explícito.