Integridade dos dados

1) O que é a integridade dos dados

A integridade dos dados é um conjunto de propriedades e controles que garante que os dados são corretos, coerentes e inconsistentes em todo o ciclo de vida, de fontes e transformações a vitrines, API e exportações. O objetivo é que a mesma afirmação dê a mesma resposta quando repetida e qualquer alteração seja rastreável e verificável.

2) Tipos de integridade e onde eles vivem

Essencial (Entity): chaves primárias únicas, sem duplicação.
Referência (Referential): laços FK corretos; não há links pendentes.
Domain: quadros e formatos válidos (tipo, comprimento, guias).
Regras empresariais: invariantes de área de objeto (saldo de ≥ 0, soma de cabos = 0 etc.).
Tempo: monotonia e coerência de marcadores de tempo, zonas de tempo corretas.
Políticas de acesso: RLS/CLS não violam a coerência lógica dos dados visíveis.

3) Contratos de dados e esquema (origem da verdade)

Definir contratos formais para conjuntos e eventos; aplicamo-los na entrada e depois de cada transformação.

yaml dataset: payments primary_key: txn_id foreign_keys:
- fk: user_id -> users.user_id schema:
- {name: txn_id, type: string, unique: true}
- {name: user_id, type: string, not_null: true}
- {name: amount, type: decimal(18,2), min: 0}
- {name: currency, type: string, in: [USD,EUR,TRY,UAH]}
- {name: event_time, type: timestamp, tz: UTC}
dq_rules:
- "duplicates(txn_id)=0"
- "ref_integrity(user_id, users.user_id)=true"
- "sum(amount) >= 0"
evolution:
semver: [MAJOR, MINOR, PATCH]
breaking_changes_require: approval:data-governance

4) Garantias de transação e isolamento

O ACID para OLTP é atômico, consistente, isolado, duradouro.
Níveis de isolamento: Read Committed/Repeatable Read/Serializable - Escolha os riscos de leitura suja/única/fantasma.
OLAP e lakehouse: Comitas de tabelas atômicas (transaction jobs), idempotent sink e schema-evolution com controle de compatibilidade.
Coerência das fórmulas KPI: camada semântica → uma única verdade para relatórios e API.

5) Sistemas distribuídos: ordem, repetições, idempotação

Ordem de eventos: use 'event _ time' + 'ingested _ at', watermarks e tolerância lateness; unidades baseadas em event time.
Nova entrega (at-least-once): global 'event _ id', tabelas de idempotency keys, upsert/merge sobre chave sustentável.
Out-of-order: reaproveitamento de janelas, estratégia de atrasos, compensações.
Exactly-once no sentido: o transporte pode ser at-least-once, o receptor pode ser idimpotente.

6) Validação da integridade (DQ) em cada camada

• Freshness/Completeness/Uniqueness/Valid Values/Referential Integrity.
• Anomalias: saltos duplicados, quebras de tempo, deslocamentos bruscos de distribuição.
• Controle de fórmulas KPI: Versões de cálculos e testes de correspondência de resultados (golden sets).
• Controle de exportação: proibição da emissão de conjuntos de infração (quarantine).

yaml expect_column_values_to_be_unique: {column: txn_id}
expect_column_values_to_not_be_null: {column: user_id}
expect_column_values_to_be_in_set: {column: currency, value_set: [USD,EUR,TRY,UAH]}

7) Integridade financeira e operacional

Duplo-entry (gravação dupla): débito/crédito em balanço; cruzamentos em cut-off.
Invariantes finais: valor do pagamento = valor dos débitos + comissão + ajustes.
Invariantes operacionais: As métricas SLA/guerrail não quebram as regras de negócios (por exemplo, a reparação automática não duplica).

8) Lineage, auditoria e reprodução

Linj: da fonte às vitrines/fique; visibilidade das transformações e proprietários.
Auditoria dos trailers: quem mudou o quê, quando e porquê; versões de circuitos/fórmulas/jobs.
Snepshots/pontos de controle: possibilidade de contar e confirmar relatórios anteriores.
Repro: o mesmo pedido de corte → o mesmo resultado (versões e camadas).

9) Segurança e privacidade sem perda de integridade

RLS/CLS: Filtros de linhas/colunas não podem violar invariantes (por exemplo, o montante da amostra aparente deve ser igual ao declarado).
Camuflagem/tocenização: estratégias determinadas para garantir que o deduto e a integridade arbitral sejam preservados.
Criptografia: no canal e «no disco» após compressão; gerenciamento de chaves e auditoria de acessibilidade.
DSAR/Retenção: remoção/anonimato não quebram a conectividade (política em cascata).

10) Auto-manutenção e reparação automática

Quarantine: isolamento de partições suspeitas/batches; os consumidores são um ramo limpo.
Replay/Backfill: reestreia a janela de um registro de raw inalterável.
Recôncile: cruzamentos de camadas e sistemas (raw↔curated↔marts; istochnik↔DWH).
Dedup/Competition/Rebuild: Procedimentos de reparação de índice/unidade do sistema.
«Que anomalia → que efeito → limiar → escalação».

11) Práticas de modelagem e armazenamento

Chaves estáveis: PK de aluguel (UUID/ULID), chaves naturais imutáveis nos guias.
Normalizatsiya↔denormalizatsiya: Ligações FK em fontes, vitrines denormalizadas com controle da versão da lógica.
SCD1/SCD2: histórico controlado para medições.
Triagem/clusterização: melhora o RLE/zona-maps e simplifica o cruzamento.
Hasts e somas de controle: verificação da integridade dos arquivos/partituras.

12) Integridade no tempo e em relatórios

Versões de fórmulas: o relatório de janeiro de 2025 deve ser reproduzido com a fórmula X.
Cut-off e «encerramento do período»: congelamento de vitrines e cortes de arquivo.
Late arriving facts: mecânica de pré-contagem e contagem com a marca da versão do relatório.
Documentação de redefinições: ajustes manuais - apenas com áudio.

13) Integração e API

Contrato API: esquemas, tipos, campos obrigatórios, códigos de erro; versionagem (v1/v2).
Validação de entrada: reject péssimo payload's, não «consertar em silêncio».
Idempotent POST: chave de idempotação, repetição segura.
Exportar para arquivos: coerência de partituras, hachês, assinaturas.

14) Antipattern

SELECT em solicitações de prod e vozes - quebrado em uma evolução MENOR.
FK em palavras: nenhuma verificação real de links.
Correções silenciosas de dados sem auditoria ou relatórios.
Mistura TZ e formatos de tempo em um conjunto.
Substituição do KPI por canetas sem versões ou registros.
A única chave de dedução sem estratégias de reposição.
Remove por DSAR sem verificação em cascata.

15) Mapa de trânsito de implementação

1. Inventory & criticidade: mapa de conjuntos/eventos, proprietários, riscos, invariantes.
2. Contratos e esquemas: formalizar tipos/restrições/FK, verificações de compatibilidade CI.
3. DQ em pipline: Freshness/Completeness/Uniqueness/RI, quarantine, alertas.
4. Base transacional: atomic-sink, upsert/merge, histórico SCD, versionabilidade de fórmulas.
5. Lineage e auditoria: catálogo, rastreamento, mudança-logs, access-logs.
6. Políticas de reparação: replay/backfill/dedup/recôncil como código; runbook’и и SLO MTTR-data.
7. Segurança/rap: RLS/CLS, camuflagem, criptografia, processos DSAR.
8. Relatórios: cut-off, cortes freeze, gerenciamento de versões KPI.

16) Folha de cheque antes do lançamento do conjunto/vitrine

• PK/FK e restrições de domínio foram definidos e testados.
• A versionização de circuitos/fórmulas está ativada; schema-diff verde.
• Regras DQ (frescura/abrangência/exclusividade/faixas/RI) verdes.
• Entradas idempotentes: upsert/merge, chave de idempotação (para eventos).
• Hora: 'event _ time' e 'ingested _ at', TZ = UTC; política late data.
• Lineage e auditoria são visíveis; quarantine e alertas incluídos.
• RLS/CLS/camuflagem não violam invariantes e RI.
• Os DSAR/Retenção foram testados; cut-off/arquivo pronto.

17) Mini-modelos

SQL: verificação da integridade de referência

sql select count() as orphans from fact_payments f left join dim_users u on f.user_id = u.user_id where u.user_id is null;
-- ожидаем orphans = 0

Política quarantine/repair (pseudo-YAML)

yaml policy: payments_integrity detect:
- rule: duplicates(txn_id) > 0
- rule: ref_integrity(user_id, users.user_id) = false auto_actions:
- quarantine_partition: {date: today}
- trigger_replay: {window: "last_2h"}
escalate_if:
- condition: violations_persist>30m page: "oncall-data"

Esquema SCD2 para medição

sql
-- dim_user_status (SCD2)
user_id, status, valid_from, valid_to, is_current

18) Total

A integridade dos dados não é uma verificação única, mas sim um sistema de garantias transversais: contratos e restrições formais, invariantes transacionados e distribuídos, validação e automação de reparos, lineage e auditoria, privacidade e direitos. Quando estes elementos funcionam juntos, os dados tornam-se uma base confiável para soluções e os incidentes são raros, curtos e previsíveis.