Validação de dados

1) Por que precisa de uma plataforma iGaming

Confiança nos relatórios e KPI: GGR/NET, conversões, retenção, RG.
Confiabilidade do ML/screen: fichas corretas para antifrode/recomendação/RG.
Operações em tempo real: alertas à deriva/perda de eventos antes que o pagamento/UX seja prejudicado.
Complaens: Falta de PII/segredos onde eles não devem existir; Uma rastreabilidade comprovável.

2) Onde validar: níveis de controle

1. Guindaste (batch/stream): padrão, tipos, campos obrigatórios, idempotency/dedup.
2. Processamento estrim: janelas/marcas de água, ordem, omissão/atraso, exactly-once.
3. ETL/ELT e transformações: links/joyons, agregados, balanços de negócios.
4. DWH/vitrine (Gold): consistência entre as tabelas, frescura, exclusividade das chaves.
5. Função Store/on-line: faixa de fic, coerência de offlayn↔onlayn.
6. BI/API: Contagem e filtros, SLAs em latency/freshness, k-anonimato.

3) Tipos de verificação (diretório)

Padrão: tipo/nullable/enum/regex/JSON-shape; alterações incompatíveis → parar.
Domínios: Somas de ≥0, Moeda ∈ a.EUR, USD, TRY, BRL, taxa ≤ limite, strana∈litsenzii.
Identidade/chaves: a chave primária é única, o foreign key não é «pendurado».
Qualidade de campo: preenchimento, comprimento, formato (BAN, BIN, e-mail token).
Estatísticas/linhas básicas: frequências, distribuição, corredores quantes.
Anomalias: saltos bruscos de volume/fração, zeros/duplicados, schema draft.
Frescor: max (ts) não mais do que X; A Liga ingest→gold ≤ T.
Consistência: soma de detalhes = resumo; multi-table reconciliation.
Privacidade/segurança: Zero-PII fora das áreas permitidas; Toquenização/máscaras.
Regulação: RG/AML campos estão presentes e plausíveis (datas, sinais).

4) Data Contracts (contratos de dados)

O contrato fixa o padrão + regras de qualidade + SLO entre a fonte e os consumidores.

yaml dataset: payments_ingest_v2 owner: team-payments schema:
id: {type: string, pattern: "^[a-f0-9]{32}$", unique: true}
ts: {type: timestamp, timezone: "UTC", nullable: false}
amount: {type: decimal(18,2), min: 0. 00}
currency: {type: string, enum: ["EUR","USD","TRY","BRL"]}
psp: {type: string, required: true}
quality:
freshness_max: "PT5M"
completeness_min: 0. 995 duplicate_rate_max: 0. 001 pii_allowed: false slo:
p95_ingest_latency_ms: 30000 success_rate: 0. 995

Alterações de contrato - através de semver e migração: 'MAJOR' quebra, 'MENOR' adiciona um campo e 'PATCH' corrige a descrição.

5) «Expectativas» e políticas

As expectativas são verificações declaratórias executadas em pipas (batch/stream).

yaml expectations:
- name: unique_primary_key check: "unique(id)"
severity: "error"
- name: amount_non_negative check: "amount >= 0"
severity: "error"
- name: currency_enum check: "currency in ['EUR','USD','TRY','BRL']"
severity: "error"
- name: ts_fresh_enough check: "now() - max(ts) <= interval '5 minutes'"
severity: "warn"
- name: pii_absent check: "no_plain_pii(columns: ['email','card','iban'])"
severity: "error"

• 'error' → quarentena de partição/batch, alerta + tíquete; bloco downstream.
• 'warn' → passa, mas cria uma tarefa de análise; marcação de qualidade.
• 'info' → apenas o monitoramento.

6) Streaming: especificidades de verificação

Watermarks/late data: permitimos o atraso de 'n' 120s', senão a quarentena; Compensamos com janelas finais.
Idempotency: chave de evento + hash payload → deadup no corretor/fluxo.
Exactly-once: sing transacional (+ sinks idumpotentes) para fluxos críticos (pagamentos/rodadas).
Contadores de volume: «esperado» vs «recebido» por janela; divergência → alert.

scala val deduped = stream
.keyBy(_.id)
.process(new DeduplicateWithin(Time. minutes(10)))

val validated = deduped
.filter(_.amount >= 0)
.filter(_.currency in Set("EUR","USD","TRY","BRL"))

emitToQuarantineIfLate(validated, allowedLateness = 120. seconds)

7) DWH/SQL: invariantes e comprimidos

sql
-- uniqueness
SELECT id, COUNT() c FROM gold. payments GROUP BY 1 HAVING c>1;

-- freshness
SELECT NOW() - MAX(ts) AS lag FROM gold. payments;

-- reconciliation of totals
SELECT
SUM(amount) AS by_rows,
(SELECT total_amount FROM gold. payments_summary WHERE date=CURRENT_DATE) AS by_summary
FROM gold. payments
WHERE date = CURRENT_DATE;

Matching com vitrines: cruzamentos diários 'detail' summary ', relatórios de discrepância, tíquetes automáticos.

8) Privacidade e segurança

Redação PII padrão: máscaras/tokens na entrada; proibindo e-mails «crus »/cartões/telefones nos logs.
Políticas de permissão: tabelas PII - camada/diretório separada, acesso por papel (RBAC/ABAC).
O anonimato K dos relatórios é um mínimo de N linhas em corte.
Detetores Leak: verificações regulares para modelos PII, «segredos» (chaves/tokens).
Jurisdição: geo/tenant-isolamento (país/marca/licença), chaves separadas.

9) Métricas de qualidade e SLO

• Freshness - Atraso max (ts).
• O Completeness é a proporção de registros indevidos/esperados.
• Uniqueness - chaves duplicadas.
• Consistency - invariantes e balanços (entre tábulos).
• Accuracy - Verificação com origem/regras de domínio externas.
• Validity - conformidade com os tipos/enum/regex.

• `Freshness payments_gold ≤ 5 мин` (p95).
• `Completeness game_rounds ≥ 99. 7 %/dia '.
• `Duplicate_rate ≤ 0. 1‰`.
• `PII_leak = 0`.

10) Alertas, tíquetes e runbook

Routing: Slack/PagerDuty → dono do domínio; aplicamos automaticamente sample e diff.
Agrupamento: um incidente no conjunto «labels: datse = payments, brand = TR».

1. Verificar a liga ingest e a fila do corretor.

2. Comparar «esperado vs recebido» por PSP.

3. Activar retraí/mudar de rota PSP.

4. Anotar a causa; restart backt; Fazer um pós-mortem.

11) Versionização, testes e processo waiver

Semver regras de qualidade: 'quality @ MAJOR. MINOR. PATCH`.
Testes de transformação unit (SQL/DBT/python) e testes de contrato para fontes.
REDES GOLDEN: As malas de discrepância e fuga conhecidas são obrigatórias em regressão.
Waiver (exceção): permissão de curto prazo para quebrar a regra (descrição, proprietário, prazo, medidas compensatórias).

12) Diretórios/artefatos (modelos prontos)

12. 1 Passaporte Dataset

yaml dataset: gold. game_rounds owner: team-games steward: data-governance contracts: ["games_rounds_v3"]
quality_slo:
freshness_p95: "PT10M"
completeness_min: 0. 997 uniqueness_max_dup: 0. 0005 alerts:
channels: ["#dq-incidents","#games-ops"]
severity_map: {error: "P1", warn: "P2"}

12. 2 Política de quarentena

yaml quarantine:
storage: "s3://quarantine/payments/"
retention: "P30D"
access: ["team-payments","data-governance"]
auto_reprocess:
cron: "/15  "
max_attempts: 3

12. 3 Expectation для Feature Store

yaml featureset: fs_payments_online_v1 checks:
- name: feature_freshness check: "now() - max(feature_ts) <= interval '60 seconds'"
severity: "error"
- name: range_amount_avg check: "amount_avg in [0, 2000]"
severity: "warn"
- name: enum_device check: "device in ['ios','android','web']"
severity: "error"

13) Especificidades iGaming: malas prontas

Pagamentos/PSP: Combinação de depósitos/conclusões com relatórios PSP; estatais em falta → quarentena de batch; alert para «decline _ rate».
Provedores de jogos: queda 'rounds _ per _ min' vs baseline + schema drivt do provedor → unidade de transformação do provedor A, banner de status.
RG/AML: campos obrigatórios (limites, self-exclusion, status KYC); KYC atrasado → a bandeira para o bloco de pagamento, tíquete para a complacência.
Marketing/CRM: validade dos parâmetros de campanha, UTM, EP; O anonimato nas vitrines.

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

0-30 dias (MVP)

1. Incluir contratos de conjuntos-chave: payments, game _ rounds, users, featuras.
2. Catálogo de expectativas (10-15 base) + quarentena + alerta.
3. Dashboard Freshness/Completeness/Uniqueness; Relatório de incidentes.
4. Runbook’и для `Freshness`, `Duplicates`, `Schema drift`.

30 a 90 dias

1. Cruzamentos e balanços entre tábulos; processo waiver e regras semver.
2. Estrim-validação (late data, deadup, watermarks); Detectores PII.
3. Integração com CI/CD: Testes contratuais de fontes e transformações.
4. Qualidade SLO em comandos de domínios OKR.

3-6 meses

1. As dicas AIops de liminares; auto-localização de causas.
2. Políticas de qualidade e relatórios de marca cruzada/geo.
3. Pós-mortem P1 incidentes → reabastecimento de redes e regulamentos golden.
4. Alinhamento com alertação de fluxo e análise de anomalias (traçado único).

15) RACI

Data Governance (A/R): padrões, contratos, auditorias de regras.
Domain Owners (R): espera de domínios e invariantes.
Data Platford (R): quadro de expectativas, quarentena, alertas, monitoramento.
Segurança/DPO (A/R): privacidade/PII/k-anonimato, geo/tenant-isolamento.
SRE/Observabilidade (C): Rotação de incidentes, SLO/SLI.
Produt/Finance (C): balanços de negócios, prioridades de incidentes.

16) Anti-pattern

Validar «só em DWH» é tarde, caro, doloroso.
Sem quarentena - «sujeira» vai para Gold/ML e quebra a confiança.
Liminares rígidos sem sazonalidade/relógio/mercado → tempestade de alertas.
A ausência do dono e semver regras → o caos das exceções.
Logs de PII e «screenshots para o canal compartilhado».
Dias de saúde em vez de um circuito permanente.

17) Seções relacionadas

As Práticas de Ops, Auditoria de Dados e Versões, Origem e Caminho de Dados, Alertas de Fluxo de Dados, Análise de Anomalias e Correlações, Controle de Acesso, Segurança de Dados e Criptografia, Políticas de Armazenamento, MLOs: Operação de modelos.

Resultado

A validação não é um filtro na ponta, mas um contrato de qualidade de passagem, que vai de injecção e strim a vitrines e ficção online. Expectativas claras, quarentena, alertas e SLO transformam os dados em um ativo confiável: relatórios corretos, modelos sustentáveis, pagamentos seguros, complacências calmas.