ETL moderno para empresas que não podem parar

O ETL (extração, transformação e carregamento) 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. Hoje a operação precisa 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 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 em bruto e transformado depois, o padrão costuma ser implementado como ELT. As camadas são designadas pela qualidade crescente do dado:

Bronze: ingestão em bruto

A camada Bronze guarda o dado exatamente como 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 um erro, volta à Bronze, corrige a lógica e reprocessa sem pedir nada à origem.

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

Silver: dados validados

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

• Cada tabela tem schema documentado e versionado.
• Os registos 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, vistas agregadas para dashboards, features para ML. A Gold é concebida para o caso de uso, não para refletir a origem. Evite a armadilha de criar uma “Gold única” que se transforma num data mart genérico e lento.

Ingestão incremental: o detalhe que decide

O carregamento completo noturno ainda serve quando a tabela inteira cabe com folga na janela de processamento. Fora disso, 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 o CDC ativado (SQL Server, Azure SQL Database, Azure SQL Managed Instance), é o padrão ideal: capta apenas as linhas inseridas, alteradas e eliminadas 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 fiável. Persiste o último timestamp lido e traz apenas os registos acima dele. É simples e barato, mas tem duas falhas comuns:

• Os registos eliminados não são detetados (é necessário soft delete na origem).
• Transações confirmadas com atraso, ou um 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 em cada carregamento e elimine os duplicados na Silver.

3. Hash de comparação

Última opção. Calcula o hash do conteúdo de cada linha e compara-o com o hash anterior. Funciona em fontes sem coluna de atualização, mas consome muito mais recursos. Reserve-a para tabelas pequenas e 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 ultrapassa o SLA.
• Volume: contagem de registos por dia comparada com o histórico da própria tabela, com a margem de tolerância definida por tabela. Uma quebra brusca gera 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 e Log Analytics para as execuções do Azure Data Factory, o hub de monitorização do Microsoft Fabric para os pipelines no Fabric, Power BI para o dashboard operacional e Microsoft Purview para a linhagem de dados.

Governação leve que escala

• Catálogo de tabelas: dono, descrição, SLA e última auditoria. Microsoft Purview ou, no início, uma simples lista no SharePoint.
• Retenção explícita: defina por camada durante 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 o apagar. O armazenamento não é grátis.
• Implementação por ambiente: desenvolvimento, pré-produção e produção. Nunca edite um pipeline diretamente em produção, nem mesmo para um “ajuste rápido”.

Quando modernizar (e quando não)

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

• Carregamento completo que termina com folga dentro da janela noturna.
• Um atraso de um dia aceite pelas áreas que usam o dado.
• Um único consumidor analítico.

Sinais de que é hora de modernizar:

• Relatórios a chegar com um atraso de um dia ou mais.
• Vários consumidores (BI, ML, aplicações) a pedir os mesmos dados com regras em conflito.
• ETLs noturnos que ultrapassam a janela e tiram capacidade ao dia seguinte.
• Impossibilidade de reprocessar o 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 frescura no Power BI, troque o carregamento completo por incremental (CDC ou watermark) e só então leve o mesmo padrão às restantes tabelas.

A engenharia de dados madura mede-se pela frescura, pelo volume e pela completude com SLA explícito, não pela tecnologia mais nova.