Guia de data engineering

Data Contracts: estabilidade para seus dados

Um rename de coluna nao deveria derrubar seus dashboards. Defina o que sera entregue, com que qualidade e como comunicar mudancas.

18 min de leituraPara data & platform engineersExemplos YAML incluidos

1. Por que data contracts?

Eles deixam os dados previsiveis: consumidores sabem o que esperar, produtores sabem quem sera impactado. Qualidade e tratada na origem.

Sem contrato, acontece isso

Um rename derruba dashboards, ninguem e avisado, a pessoa de plantao passa horas buscando a causa. O contrato define regras e donos.

Pipelines estaveis

Breaking changes param antes de chegar na prod.

Ownership claro

Responsaveis e canais de contato definidos.

Incidentes mais rapidos

Schema, SLAs e runbooks estao visiveis.

2. O que deve ter no contrato

Seja direto, versionado e legivel por maquina (YAML/JSON). Estes sao os blocos basicos.

Schema + semantica

  • • Campos, tipos, not null, faixas
  • • Definicao de negocio por campo
  • • Exemplos de payload e casos de teste

SLAs & qualidade

  • • Frescor (ex. < 15 min), disponibilidade
  • • Checks (unicidade, completude, valores esperados)
  • • Escalacao, janela de incidente, runbooks

Owners & consumidores

  • • Time responsavel, pager, Slack/Teams
  • • Principais consumidores e dashboards
  • • Sensibilidade e classes de acesso

Mudancas & notificacoes

  • • Versionamento (SemVer), politica de deprecation
  • • Canal para anunciar breaking changes
  • • Plano de rollback e janela de migracao

3. Workflow: do rascunho a producao

Comece com um time de dominio, automatize os checks. Meta: bloquear breaking changes no CI, nao em producao.

1

Draft & review

Produtor escreve o contrato (YAML/JSON). Consumidor valida campos, semantica e SLAs.

2

CI e lint

Linter de schema, testes dbt/Great Expectations no PR. Breaking changes sao bloqueados.

3

Registry & rollout

Versao aprovada vai para registry/catalogo. Deploy em staging, depois prod.

4

Monitoring

Dashboards de frescor, erros, qualidade. Alertas para owner + consumidores.

4. Versionamento & breaking changes

Use SemVer: PATCH para correcoes, MINOR para adicoes compativeis, MAJOR para breaking changes. Diga quanto tempo a versao anterior fica ativa.

Mudancas compativeis

  • • Novo campo com default
  • • Limite/intervalo ampliado
  • • Valores Enum adicionados (com aviso)

Breaking changes

  • • Remover ou renomear campo
  • • Tipo mais restritivo (ex. string -> int)
  • • Mudar semantica sem avisar
Anuncie versoes MAJOR com antecedencia e mantenha versao antiga + nova em paralelo durante a migracao.

5. Enforcement & monitoramento

Shift-left

  • • Lint do contrato no PR
  • • Schema registry bloqueia incompatibilidade
  • • Testes dbt / Great Expectations no CI

Runtime & observabilidade

  • • Alertas de frescor e erros
  • • Dashboards de qualidade e SLAs
  • • Runbooks e escala de plantao

6. Ferramentas & proximos passos

Junte definicao, registry e checks de qualidade. Comece simples e automatize depois.

Blocos uteis

  • • Schema registry (OpenAPI/Avro/Protobuf)
  • • Testes dbt, Great Expectations para checks
  • • Catalogos/Lineage para analise de impacto

Com o Datadef

  • • Documente contratos no DiagramAI
  • • Mostre lineage e owners
  • • Gerencie versoes e SLAs por dataset

7. FAQ

Preciso de uma ferramenta dedicada?

Nao. Comece com YAML no repo + CI. Depois conecte uma registry ou catalogo se necessario.

Como lidar com dados sensiveis?

Adicione tags de sensibilidade, classes de acesso e regras de mascaramento. Amarre-as a politicas na pipeline.

Quem e o owner do contrato?

O time produtor. Os consumidores revisam, mas o producer permanece responsavel por qualidade e SLAs.