Governança de Dados: Métodos de Aplicação

Governança de dados falha quando é tratada como um projeto de tecnologia. O ponto de partida deve ser organizacional: definir papéis, identificar domínios críticos e construir confiança nos dados antes de escolher ferramentas.

Passo 1: inventariar e classificar os dados

Antes de qualquer política, é necessário saber o que existe.

Classificação por sensibilidade:

Público: pode ser compartilhado externamente
Interno: uso dentro da organização
Confidencial: acesso restrito a times específicos
Restrito: PII, dados financeiros, segredos comerciais

Por domínio de negócio: agrupe os dados por origem ou responsabilidade (clientes, pedidos, produtos, finanças). Isso define as fronteiras para stewardship e ownership.

Passo 2: definir papéis e responsabilidades

Um modelo básico para começar:

Papel	Quem é	O que faz
Data Owner	Líder de negócio (diretor, VP)	Aprova políticas de acesso, resolve disputas de definição
Data Steward	Analista ou engenheiro de dados do domínio	Define regras de qualidade, cataloga, monitora SLAs
Data Engineer	Engenheiro de dados	Implementa regras técnicas, pipelines de qualidade
Data Consumer	Analistas, cientistas, sistemas	Usa dados conforme políticas

Armadilha comum: concentrar todos os papéis em um time de dados central. Isso cria gargalo e resistência dos domínios.

Passo 3: criar um glossário de negócio

O glossário define o significado acordado de termos importantes para a organização.

Exemplo de entrada no glossário:

Termo: Receita Líquida
Domínio: Finanças
Definição: Valor total faturado menos devoluções, descontos e impostos.
Fonte autoritativa: tabela fato_vendas no DW, coluna receita_liquida
Data Owner: Diretoria Financeira

Esse glossário deve ser mantido no catálogo de dados e referenciado nos metadados das tabelas. Evita a situação onde “receita” significa coisas diferentes em cada dashboard.

Passo 4: implementar catálogo de dados

O catálogo é o inventário vivo dos ativos de dados. Cada ativo deve ter:

Metadados técnicos: localização, schema, tamanho, frequência de atualização
Metadados de negócio: descrição, glossário de colunas, dono, classificação de sensibilidade
Metadados operacionais: linhagem, qualidade atual, jobs que alimentam

Com dbt: o próprio schema.yml torna-se fonte de metadados de negócio. Definições de colunas e testes ficam versionados junto com o código:

models:
  - name: fct_vendas
    description: Fatos de vendas com granularidade de pedido
    columns:
      - name: pedido_id
        description: Identificador único do pedido
        tests:
          - unique
          - not_null
      - name: receita_liquida
        description: Valor faturado menos devoluções, descontos e impostos
        tests:
          - not_null

Passo 5: definir e monitorar qualidade

As dimensões de qualidade mais usadas:

Dimensão	Pergunta	Exemplo de regra
Completude	O campo está preenchido?	`receita IS NOT NULL`
Unicidade	Há duplicatas indesejadas?	`pedido_id` deve ser único
Validade	O valor está dentro do esperado?	`status IN ('ativo', 'inativo')`
Consistência	Os dados são coerentes entre fontes?	Contagem de pedidos = contagem no sistema OLTP
Atualidade	Os dados estão frescos?	Última carga há menos de 2 horas
Precisão	Os valores refletem a realidade?	Mais difícil de automatizar, requer validação manual

Passo 6: contratos de dados

Data contracts são acordos formais entre quem produz dados e quem os consome. Definem:

Schema esperado (nomes e tipos de colunas)
SLAs de atualização (freshness)
Regras de qualidade (o que o produtor garante)
Processo de versionamento e comunicação de mudanças breaking

Exemplo minimalista em YAML (Data Contract Specification):

dataContractSpecification: 0.9.3
id: contract-pedidos-v1
info:
  title: Pedidos
  version: 1.0.0
  owner: [email protected]
models:
  pedidos:
    fields:
      pedido_id: {type: string, required: true, unique: true}
      cliente_id: {type: string, required: true}
      valor_total: {type: number, required: true, minimum: 0}
      status: {type: string, enum: [pendente, confirmado, cancelado, entregue]}
servicelevels:
  freshness:
    description: Dados atualizados a cada 30 minutos
    threshold: 30m

Passo 7: controle de acesso

Implemente RBAC (Role-Based Access Control) ou ABAC (Attribute-Based):

RBAC: usuários recebem papéis (analista, cientista, admin), papéis têm permissões sobre tabelas/schemas
ABAC: permissões baseadas em atributos do dado (sensibilidade = confidencial) e do usuário (departamento = RH)

Column-level security: mascarar colunas PII para usuários sem permissão (ex: mostrar *** em vez do CPF).

Row-level security: filtrar linhas com base no perfil do usuário (ex: vendedor X só vê pedidos da sua região).

No Databricks: Unity Catalog permite column masks e row filters nativos. Ver databricks-unity-catalog.

Armadilhas comuns

Governança sem patrocínio executivo: sem um sponsor, políticas não são seguidas e o programa morre
Começar pela ferramenta: comprar Collibra antes de ter processos e papéis definidos resulta em um catálogo vazio
Tentar catalogar tudo de uma vez: comece pelos domínios críticos e expanda iterativamente
Governança como polícia: times evitam o catálogo se ele for percebido como burocracia punitiva

Second Brain

Explorer