ETL moderno para empresas que não podem parar

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

A arquitetura medallion em 3 camadas

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

Bronze — ingestão em bruto

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

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

Silver — dados validados

Aplica deduplicação, tipagem explícita, validação face ao schema esperado e normalização de chaves. O silver é o nível onde as equipas analíticas podem consultar com segurança. Dois princípios:

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

Gold — modelos de negócio

Tabelas prontas para consumo — star schema para BI, vistas agregadas para dashboards, features para ML. O gold é concebido para o caso de uso, não para refletir a origem. Evite a armadilha de criar um “gold único” que se transforma num data mart genérico e lento.

Ingestão incremental: o detalhe que decide

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

1. Change Data Capture (CDC)

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

2. Watermark de timestamp

A origem tem uma coluna updated_at fiável. Persiste o último timestamp lido e traz apenas os registos acima dele. Simples, barato, mas atenção a duas falhas comuns:

• Os registos eliminados não são detetados (é necessário soft delete na origem).
• Um relógio desalinhado entre origem e pipeline provoca perda de linhas.

3. Hash de comparação

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

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

Um pipeline sem observabilidade é uma aposta. Três sinais mínimos num dashboard operacional:

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

Ferramentas do ecossistema Microsoft: Azure Monitor + Log Analytics para as execuções, Power BI para o dashboard operacional, Microsoft Purview para a lineage visual.

Governação leve que escala

• Catálogo de tabelas: dono, descrição, SLA, última auditoria. Microsoft Purview ou uma simples lista SharePoint no início.
• Retenção explícita: bronze 90 dias, silver 2 anos, gold conforme o negócio. O armazenamento não é grátis.
• Implementação por ambiente: dev → staging → produção. Nunca editar o pipeline diretamente em produção, nem mesmo para um “ajuste rápido”.

Quando modernizar (e quando não)

Nem toda a empresa precisa de um medallion completo. Sinais de que a 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 a chegar com um atraso de um dia ou mais.
• Múltiplos consumidores (BI, ML, aplicações) a pedir os mesmos dados com regras conflituosas.
• ETLs noturnos a exceder a janela e a roubar capacidade ao dia seguinte.
• Impossibilidade de reprocessar o histórico sem tocar na origem de produção.

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