Camada analítica transformada, testada e orquestrada

Prazo

03/11/2026

Peso

14% da nota final

Semana

Semana 13 no cronograma

Onde entregar

No repositório público da Squad, com a tag e3

É aqui que a plataforma passa a responder à pergunta de gestão declarada na E1. Até agora o dado foi movido; nesta Entrega ele é modelado para consumo, testado e posto para rodar sozinho.

O que se espera

Um modelo dimensional com fato e dimensão, granularidade declarada por extenso — “uma linha por município por mês” — e ao menos uma dimensão de variação lenta, porque quase todo domínio público tem uma: município que muda de nome, prestador que troca de razão social, classificação que é revista.

As transformações ficam em ferramenta declarativa e versionada — dbt ou SQLMesh —, organizadas em camadas. Junto delas, os testes de dados: esquema, volume, unicidade, integridade referencial, e ao menos um de distribuição, que é o que pega o erro silencioso.

E tudo isso agendado, num grafo de dependência com retry, com um backfill que você executou de verdade e pode demonstrar.

A decisão desta Entrega

O ADR da E3 é sobre modelagem analítica ou ferramenta de transformação.

• Estrela ou Data Vault? One big table? A resposta depende de quantas fontes se integram e de quanto o esquema da origem muda — e disso você já tem evidência, vinda da E2.
• Em que granularidade o fato vive? Uma granularidade fina demais explode o volume; grossa demais impede a pergunta. Meça as duas.
• dbt ou SQLMesh, Airflow ou Dagster: a opção nula aqui é um cron com script SQL, e ela merece ser levada a sério antes de descartada.

Erros que se repetem

• Fato sem granularidade declarada. Ninguém consegue dizer o que uma linha representa, e a agregação dupla passa despercebida.
• Testes que só verificam o que não quebra. not_null em coluna que nunca é nula não testa nada. Teste o que o domínio tem de sujo: valor negativo onde não cabe, salto de série, município que some entre dois anos.
• Dimensão de variação lenta tratada como sobrescrita. O histórico se perde e a série temporal fica errada retroativamente — o erro mais difícil de detectar depois.
• Orquestração que nunca falhou. Sem retry exercitado e sem backfill executado, o grafo é decorativo. Derrube uma dependência de propósito e mostre o que acontece.
• Painel que não responde à pergunta. Bonito, com dez gráficos, e nenhum deles é a resposta que a E1 prometeu.

Checklist de aceite

É o que a monitoria confere na correção. Item não atendido não zera a Entrega, mas pesa nos critérios de funcionamento e reprodutibilidade.

• Modelo analítico com fato e dimensão, granularidade declarada e ao menos uma dimensão de variação lenta
• Transformações versionadas em ferramenta declarativa (dbt ou SQLMesh), organizadas em camadas
• Testes de dados: esquema, volume, unicidade, integridade referencial e ao menos um de distribuição
• Orquestração agendada com grafo de dependência, retry e backfill demonstrado
• Ao menos uma consulta otimizada a partir do plano de execução, com `EXPLAIN (ANALYZE, BUFFERS)` antes e depois no repositório
• Métrica de freshness e SLA declarado para ao menos uma tabela de consumo
• 1 ADR sobre a escolha de modelagem analítica ou de ferramenta de transformação
• Painel analítico respondendo à pergunta de gestão declarada na E1