Porque é que os seus pipelines de dados falham (e como os contratos de dados resolvem isso)

A maioria das falhas de pipeline não começa com um erro dramático. Começa com uma alteração bem-intencionada a três equipas de distância: alguém renomeia uma coluna, aperta um tipo ou remove um campo que “ninguém usa”. Horas depois, um dashboard está errado, um modelo está a pontuar lixo e um engenheiro de plantão está a fazer bisecção de commits às 3 da manhã.

A causa raiz quase nunca é o código; é a falta de acordo sobre o aspeto que os dados devem ter. Esse acordo é um contrato de dados.

O que é realmente um contrato de dados

Um contrato de dados é uma especificação versionada e legível por máquina de um conjunto de dados, com a qual produtores e consumidores se comprometem. No mínimo, cobre:

• Esquema: nomes de campos, tipos e nulidade.
• Semântica: o que cada campo significa e os seus valores permitidos.
• Garantias de qualidade: expectativas de frescura, completude e unicidade.
• Propriedade: quem é responsável quando o contrato é violado.

Fundamental: o contrato vive no controlo de versões, junto do código que produz os dados; não numa página de wiki que fica desatualizada no dia em que é escrita.

Aplique-o em CI, não em produção

Um contrato que não é aplicado é apenas documentação. O padrão que funciona:

1. Os produtores declaram o contrato como código (por exemplo, um contrato de modelo em dbt ou uma entrada num schema registry).
2. Cada alteração a um job produtor corre uma verificação em CI que compara a nova saída com o contrato.
3. Uma alteração disruptiva falha o build; o produtor ou atualiza o contrato deliberadamente (subindo a sua versão) ou corrige a regressão.

# Um contrato de modelo simples em dbt
models:
  - name: orders
    config:
      contract: { enforced: true }
    columns:
      - name: order_id
        data_type: string
        constraints: [{ type: not_null }]
      - name: total_amount
        data_type: numeric

A alteração que antes escapava em silêncio passa agora a aparecer como um build vermelho, revisto por quem é dono do impacto a jusante.

O retorno

As equipas que adotam contratos deixam de tratar a qualidade dos dados como uma atividade de combate a incêndios. As alterações disruptivas tornam-se visíveis, negociadas e versionadas. Os consumidores podem construir sobre um conjunto de dados sabendo que não vai mudar debaixo dos seus pés sem aviso; e quando muda, recebem um período de descontinuação em vez de um alerta às 3 da manhã.

Não precisa de contratualizar todas as tabelas no primeiro dia. Comece pelo punhado de conjuntos de dados que alimentam os seus dashboards e modelos mais importantes, prove o padrão e expanda a partir daí. A fiabilidade acumula-se.