Um dado falso em produção não é apenas um bug técnico. É uma decisão de negócio errada. Um faturamento superestimado que cria uma falsa impressão de crescimento. Um cliente classificado como ativo que não é, gerando marketing ineficaz.
A IBM (2025) estima o custo de um dado ruim em US$ 40.000 em média. Pode chegar a US$ 500.000 dependendo do contexto. O custo da prevenção — testes, contracts, monitoramento — é insignificante em comparação. No entanto, muitas organizações não testam nada. Por quê? Porque as consequências são invisíveis, difusas.
Um dashboard exibe um número errado, ninguém percebe durante 3 meses. É a urgência oculta da engenharia de dados: implementar salvaguardas antes que o desastre aconteça.
Data Contracts: formalizar o contrato
Um Data Contract é um acordo escrito entre o produtor de um dado e seus consumidores. Ele especifica precisamente: o schema exato (colunas, tipos, nulabilidade), os SLAs de atualização (dados atualizados todos os dias antes das 8h), os SLAs de disponibilidade (99,5% do tempo), as garantias de cardinalidade (não menos de 1M de linhas/dia), as regras de negócio (sem valores negativos para montantes).
O produtor se compromete a respeitar o contrato. O consumidor se compromete a usar o dado corretamente. Se o produtor violar o contrato — entrega 1h atrasada, schema alterado sem aviso — o consumidor tem o direito de recusar. Os Data Contracts reduzem em 75% as anomalias de schema em produção.
É a responsabilidade explícita. É engenharia.
Schemas estritos e versionamento
Um schema estrito significa: sem colunas adicionais não validadas, sem mudanças de tipo sem migração, sem renomeação silenciosa. BigQuery, Snowflake, Redshift suportam todos schemas estritos. Cada coluna tem um tipo, uma nulabilidade, uma descrição.
As breaking changes são proibidas: renomear uma coluna só se faz com migração planejada. Adicionar uma coluna não-nulável quebra os contratos. Schemas mal versionados causam 30% das anomalias de dados.
Fixar o schema uma vez, testá-lo rigidamente, depois evoluí-lo com um processo claro — depreciação > notificação > migração > remoção em 6 meses. É disciplina.
Great Expectations e testes automatizados
Great Expectations é a ferramenta padrão para testes de qualidade de dados. Definir expectations (asserções) e executá-las automaticamente.
Exemplos concretos: "a coluna purchase_date não deve ter nulos", "o montante deve ser >= 0", "o e-mail deve corresponder ao pattern", "o número de linhas não deve cair mais de >10% dia a dia".
Esses testes são executados após cada carregamento. Se uma expectation falhar, alerta ou bloqueio do pipeline. Great Expectations reduz 80% da detecção de anomalias. Quando uma coluna se torna subitamente nulável, o alerta é disparado imediatamente. É a detecção precoce antes da cascata em análises falsas.
SLA de dados e Observabilidade
Um SLA (Service Level Agreement) de dados é um contrato entre produtor e consumidor — disponibilidade garantida (99,5%), latência máxima (dados com menos de 24h), qualidade garantida (>95% de validade).
Se o produtor violar o SLA, deve compensar ou justificar. Isso cria accountability. SLAs bem definidos reduzem em 90% as disputas entre equipes: tudo é preto no branco.
A observabilidade associada ao SLA mede continuamente — latência real, taxa de validade, erros por tipo. Dashboards mostram o estado de saúde de cada dado em tempo real. Se uma curva sobe, alerta. A equipe pode intervir antes que o usuário descubra o problema em produção.
Gestão de mudanças: os três tipos
Um contrato de dados rigoroso impõe um processo disciplinado para mudanças. Três tipos: aditiva (nova coluna nulável) — sem necessidade de notificação.
Depreciações (coluna removida em 6 meses) — notificação a todos os consumidores 3 meses antes.
Breaking changes (remover uma coluna, mudar um tipo) — discussão com todos os consumidores, migração planejada. Toda mudança passa por uma PR dbt, revisada pelos stakeholders, testada rigorosamente, depois implantada com changelog.
Sem esse processo, as mudanças quebram silenciosamente dependências. Com ele, é engenharia de software aplicada aos dados.
Em produção
Na Bomzai, falamos em industrializar. Industrializar os dados é ter confiança no que circula. E a confiança vem do rigor.
Schemas estritos, SLAs, testes automatizados, gestão de mudanças disciplinada. Não é luxo, é o mínimo para produzir em produção. Um dado ruim em produção se torna excepcional, não a norma.
Os Data Contracts transformam os dados de um caos não governado em uma cadeia de suprimentos confiável. Produtor e consumidor responsáveis juntos. Fornecedor e cliente de um contrato. E isso muda completamente o jogo.
