ETL moderno para empresas que não podem parar

O ETL (extração, transformação e carga) 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. Hoje a operação precisa de dados recém-atualizados durante o horário comercial, e qualquer interrupção gera um alerta no celular do CFO.

A arquitetura medalhão em 3 camadas

Popularizada pela Databricks, a arquitetura medalhão separa o pipeline em três camadas (Bronze, Silver e Gold). Como o dado é carregado bruto e transformado depois, o padrão costuma ser implementado como ELT. As camadas são nomeadas pela qualidade crescente do dado:

Bronze: ingestão bruta

A camada Bronze guarda o dado exatamente como ele chega da origem, sem transformação nem validação. A regra de ouro: a Bronze é uma cópia fiel e reprocessável da origem. Se uma transformação mais à frente gerou erro, você volta à Bronze, corrige a lógica e reprocessa sem pedir nada à origem.

Na prática, em stack Azure: o Azure Data Factory grava arquivos Parquet no Azure Data Lake Storage Gen2, particionados pela data de ingestão.

Silver: dados validados

Aplica deduplicação, tipagem explícita, validação contra o schema esperado e normalização de chaves. A Silver é o nível em que as equipes analíticas podem consultar com segurança. Dois princípios:

• Cada tabela tem schema documentado e versionado.
• Registros inválidos vão para uma tabela _rejects e nunca são descartados em silêncio.

Gold: modelos de negócio

Tabelas prontas para consumo: star schema para BI, views agregadas para dashboards, features para ML. A 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 e lento.

Ingestão incremental: o detalhe que decide

A carga completa noturna ainda serve quando a tabela inteira cabe com folga na janela de processamento. Fora disso, você precisa de ingestão incremental, e é aqui que muitos pipelines falham. Três técnicas, por ordem de preferência:

1. Change Data Capture (CDC)

Quando a origem tem CDC habilitado (SQL Server, Azure SQL Database, Azure SQL Managed Instance), é o padrão ideal: captura só as linhas inseridas, alteradas e excluídas a partir do log de transações, com impacto mínimo na origem. O Azure Data Factory lê esse CDC de forma nativa. A replicação lógica do PostgreSQL também serve, mas fica fora do CDC nativo do Data Factory.

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 e barato, mas tem duas falhas comuns:

• Registros excluídos não são detectados (é preciso soft delete na origem).
• Transações confirmadas com atraso, ou watermark calculado pelo relógio do pipeline em vez do maior valor lido na origem, deixam linhas para trás. Releia uma pequena janela de sobreposição a cada carga e deduplique na Silver.

3. Hash de comparação

Última opção. Você calcula o hash do 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 e 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 passa do SLA.
• Volume: contagem de registros por dia comparada ao histórico da própria tabela, com a faixa de tolerância definida por tabela. Queda brusca gera alerta.
• Completude: cobertura de chaves esperadas. Se esperava 400 lojas e vieram 380, onde estão as 20?

Ferramentas do ecossistema Microsoft: Azure Monitor e Log Analytics para as execuções do Azure Data Factory, o hub de monitoramento do Microsoft Fabric para os pipelines no Fabric, Power BI para o dashboard operacional e Microsoft Purview para a linhagem de dados.

Governança leve que escala

• Catálogo de tabelas: dono, descrição, SLA e última auditoria. Microsoft Purview ou, no começo, uma lista simples no SharePoint.
• Retenção explícita: defina por camada quanto tempo guardar, lembrando que a Bronze só permite reprocessar o período que ainda retém. Mova o histórico antigo para um armazenamento mais barato em vez de apagar. Storage não é grátis.
• Deploy por ambiente: desenvolvimento, homologação e produção. Nunca edite um pipeline direto em produção, nem para um "ajuste rápido".

Quando modernizar (e quando não)

Nem toda empresa precisa da arquitetura medalhão completa. Sinais de que o stack tradicional ainda serve:

• Carga completa que termina com folga dentro da janela noturna.
• Atraso de um dia aceito pelas áreas que usam o dado.
• Um único consumidor analítico.

Sinais de que é hora de modernizar:

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

Por onde começar

Escolha uma tabela crítica que hoje chega atrasada, publique para ela um indicador de frescor no Power BI, troque a carga completa por incremental (CDC ou watermark) e só então leve o mesmo padrão às demais tabelas.

Engenharia de dados madura se mede por frescor, volume e completude com SLA explícito, não pela tecnologia mais nova.