Controle de qualidade de dados

1) Atribuição e princípios

Porquê: relatórios confiáveis (GGR/impostos), antifrode e modelos RG, downloads complicados, produtos e personalização.

• Schema-first & Contracts: Todas as fontes são obrigadas a publicar os dados do contrato.
• DQ-como-código: regras no repositório, versões, testes e ciúmes.
• Observabilidade-by-default: métricas/logs/régua.
• Private-by-design: PII mínimo, camuflagem e RLS/CLS.
• Costa-aware: priorização de regras críticas, amostras inteligentes.

2) Taxonomia medidas de qualidade

Completeness: proporção de campos/linhas obrigatórios.
Validade: conformidade com tipos/faixas/guias.
Uniqueness (Exclusividade): falta de duplicação de chaves/eventos.
Consistency (Coerência): integridade de referência, invariantes de negócios.
Accuracy (Precisão): aproxima-se de uma fonte «verdadeira» (cruzamentos resumidos).
Timeliness/Freshness (Oportunidade): atraso no material.
Lineage Integrity: preserva as origens/versões das transformações.

Cada domínio é definido por KPI de qualidade e criticidade (critical/major/menor).

3) Contratos e esquemas (origem da verdade)

Contratos de dados: JSON Schema/Avro/OpenAPI/AsyncAPI, hospedado em Registry.
Estabilidade: alterações compatíveis backward - adição de nullable; breaking - nova versão + dupla gravação.
Traçabilidade: «event _ id», «trace _ id», «schema _ version», «fonte» nos eventos.

4) DQ-como-código: estrutura de artefatos

/dq/
rules/
silver. payments. yaml gold. ggr_daily. yaml checks/
sql/
python/
policies/
severities. yaml notifications/
routes. yaml

Regras: YAML/SQL declaratório;

Seriedade: maping → alert canais/níveis de escalação;

LI: Linters de circuito, testes de compatibilidade, «dry-run «/simulador.

5) Exemplos de regras (YAML)

yaml table: silver. payments owner: data-payments slo:
freshness_minutes: 15 completeness_percent: 99. 5 rules:
- name: amount_positive severity: critical type: range column: amount min: 0. 01
- name: currency_in_whitelist severity: major type: in_set column: currency set: [EUR, USD, GBP, TRY, BRL]
- name: unique_tx severity: critical type: unique columns: [transaction_id]
- name: fk_user_exists severity: critical type: foreign_key column: user_pseudo_id ref_table: dim. users ref_column: user_pseudo_id
- name: ts_monotonicity severity: minor type: temporal expression: "ts between date_sub(now(), interval 90 day) and now()"

6) testes SQL (amostras)

Exclusividade das chaves

sql
SELECT transaction_id, COUNT() AS c
FROM silver. payments
GROUP BY transaction_id
HAVING COUNT() > 1;

Abrangência dos campos obrigatórios

sql
SELECT COUNT() AS nulls
FROM silver. payments
WHERE amount IS NULL OR currency IS NULL OR ts IS NULL;

Guias/Consistência

sql
SELECT p. currency
FROM silver. payments p
LEFT JOIN ref. currencies r ON p. currency = r. code
WHERE r. code IS NULL;

7) Fluxo DQ (real-time)

Validação de Ingest: schema validation, size-limits, tipos e enum's.
On-stream verificação: deadup '(event _ id, fonte)', allowed lateness, validade de moedas/somas.
Limites: erros críticos → DLQ + alert; não criteriosos → formatar, mas omitir (com a bandeira 'dq _ flag').
Métricas: completeness/lag/dup-rate.

8) Trabalhar com erros e exceções

DLQ/Quarantine: gravações «doentes» são mantidas, disponíveis para correção.
Exceção records: cartão de exceção (owner, prazo, razão, área).
Auto-fallback - Usar a última vitrine correta.
SLA encerramento: crítico - ≤ 24-48 h; Major - ≤ 5 escravo. dias.

9) Alinhamento com privacidade e complicações

PII-Minimização: Não verifique PII crus em camadas analíticas; aplique pseudônimos.
RLS/CLS: As verificações são feitas com base no disfarce dos campos.
Regionalização: as regras consideram 'jurisdicção' (EEA/UK/BR).
Legal Hold: proibição de regravar arquivos como parte da retenção.

10) Observabilidade, SLI/SLO e alertas

• Freshness p95 (Silver): ≤ 15 min
• Completeness (critical types): ≥ 99. 5%.
• Validity (schema): ≥ 99. 9%.
• Duplicate rate: ≤ 0. 1%.
• DQ incident MTTR: ≤ 24–48 ч.

Alerts: rotação por gravidade (pager para critical), suavização (alertas de dedução), «maintenance windows».

11) Dashboards (conjunto mínimo)

Cartão térmico Freshness/Completeness para domínios e mercados.
Top N tabelas de invenção rate e valor de correção.
Vórtice DQ: ingest → silver → gold (perda/correção).
Mapa da linha para relatórios críticos (regulador/GGR/RG/AML).
Mapa de circuitos e clientes «obsoletos» (versões SDK/circuitos).

12) Processos e RACI

R (Resolvível): Data Engineering (regras por tabela), Domain Owners (semântica).
A (Accountable): Head of Data/CDO.
C (Consulted): Compliance/Legal/DPO, Arquitetura, SRE.
I (Informed): BI/Produto/Marketing/Finanças/Operações.

Ciclo de vida da regra: sugestão → ciúmes → «início escuro» → inclusão → monitoramento → retrospectiva.

13) Acertos e precisão (Accuracy)

Valores de controle/transação: conjunto com provedores OLTP/PSP/KYC.
Comparações de dois contornos: pipeline independente para validação seletiva.
Permissões: liminares de porcentagem de métricas (por exemplo, divergência GGR ≤ 0. 2%).
Atas diárias: relatórios de verificação.

14) Custo e priorização

Regras críticas executem com mais frequência (streaming/relógio), menor - daily.
Use a amostra e materializações para tabelas pesadas.
Rastree o custo/query e o custo/GB, e aplique o clustering/indexação.
Atribua o orçamento para DQ no corte de comandos.

15) Modelos para vitrines gold (exemplo GGR Daily)

yaml table: gold. ggr_daily owner: fin-analytics slo:
ready_by_local_time: "06:00"
rules:
- name: ggr_not_negative severity: critical type: range column: ggr min: 0. 0
- name: market_known severity: major type: in_set column: market set_ref: ref. markets
- name: fx_source_present severity: major type: not_null column: fx_source
- name: completeness_by_market severity: critical type: completeness partition_keys: [event_date, market]
expected_rows_expression: "ref. expected_activity(event_date, market)"

16) Incidentes de qualidade: gestão e comunicação

Ticketing: Criação automática de tarefas com amostras e métricas anexadas.
Modelos comm: notificação de proprietários de produtos/reguladores em caso de impacto.
Pós-mortem: causa raiz (schema draft, upstream, carga), ação CAPA, controle de «retorno de regressão».

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

1. Catálogo de tabelas críticas (Payments, Gamplay, GGR, Compliance).

2. Regras YAML para 10-15 inspeções-chave + validação CI.

3. Dashboard Freshness/Completeness e alertas para critical.

4. DLQ/Quarantine + runbook correções.

• Extensão de regras (FK/accuracy), simulador «dry-run», A/B inclusões.
• Integração com lineage, acordos de exclusão e SLA.
• Fluxo DQ em ingest para fontes «ruidosas».

• Gerenciamento automático da documentação de acordo com as regras, métricas de valor.
• «Contornos de controle» (independent recordation), uma retrospectiva de semana.
• Rule-as-Código SDK de plataforma, registro de verificações de domínio padrão.

18) Folha de cheque antes de vender

• Contratos e esquemas em Registry, testes de compatibilidade estão sendo realizados.
• As regras YAML estão arrasadas, severity/escalar foram atribuídas.
• Os dashboards e alertas estão ativos; Os SLO foram definidos e negociados.
• DLQ/Quarantine está disponível, runbooks documentados.
• Os procedimentos de exclusão/atos de forró estão alinhados com o Legal/Compliance.
• Medição do custo de verificação e limites para solicitações pesadas.

19) Erros frequentes e como evitá-los

Dados crus sem contrato: insira schema-first e consumer-tests.
Verificações manuais: transfira para DQ-tipo e CI.
Sem prioridade: divida critical/major/menor e canais de alertas.
DLQ ausente: nada para lidar com erros - adicione quarentena.
Sem valor: Perfilhe as solicitações, use a materialização.
Não há pós-mortems, os erros são recorrentes. Digite CAPA e controle de regressão.

20) Total

O sistema de controle de qualidade de dados não é um conjunto de verificações separadas, mas sim um programa gerido, como contratos e esquemas, DQ-como-código, observabilidade e SLO, disciplina de incidentes e forró. Seguindo este artigo, você vai obter dados reproduzíveis, verificáveis e econômicos suficientes para relatórios regulatórios, soluções de alimentos e detectores de risco real-time.