Auditoria de dados e versões
1) Por que é necessário
As auditorias e versões criam reprodutividade: você pode explicar qualquer número, repetir o cálculo e desenvolver os modelos/vitrines com segurança. Em iGaming, isso é crítico para finanças (GGR/NET), pagamentos, KYC/AML, Resolvível Gaming e relatórios regulatórios.
Objetivos:- Traçado: quem alterou dados/esquema/lógica e porquê.
- Reprodução: qual versão de dados/código/modelo gerou o relatório.
- Segurança de lançamentos: reversibilidade (rollback) e previsibilidade de mudanças.
- Correspondência: registros comprovados para reguladores e auditorias internas.
2) Conceitos e níveis de versões
1. Versão de padrão: evolução de campos/tipos/semântica (SEMVER).
2. Versão do conjunto de dados (Datdepois): imagem/corte no momento; verdade para relatório/treinamento.
3. Versão da vitrine/modelo BI (Data Product Versão): fórmulas, filtros, agregações.
4. Versão pic/modelo ML: data/código/hiperparâmetros/fichas/dados (end-to-end).
5. Versão do Pipline: código de transformação, configh, dependência.
6. Versão do contrato de dados: requisitos para o produtor/consumidor (esquema, SLA, qualidade).
3) Auditoria: o que logar
Quem: sujeito (usuário/serviço), papel/atributo (RBAC/ABAC).
O que: tabela/vitrine/modelo/esquema/contrato.
Quando: hora exata, tz, identificação correlacionada.
Porquê: referência a tusk/tíquete/nota de lançamento, razão.
Versão de código/modelo, comit hash, imagem de contêiner.
Como mudou: antes/depois (diff), volume de linhas (raws affected), controle de integridade (hash/assinatura).
Contexto: ambiente (pró/estágio), domínio, sensibilidade de dados (classe).
Os registros de auditoria são imutáveis (append-only/WORM), assinados e disponíveis no SIEM.
4) Política de versões (recomendações)
SEMVER: `MAJOR. MINOR. PATCH`
MAJOR - alterações incompatíveis de padrão/semântica.
MENOR - Adições reversíveis compatíveis (novos campos/colunas com nullable, novas vitrines de vNext).
PATCH - correções sem alteração de contrato (quality-fix, backfill).
Procedimento Deprecation: janela de obsolescência, avisos no diretório/CI, data de desligamento.
Release Note: uma página para o lançamento, o que, porquê, os riscos, o plano de reversão.
5) Técnicas em armazenamento e fluxo
Time-travel/Snapshots: armazenamento de versões de tabelas; a possibilidade de executar o pedido «como estava no T-0».
SCD (Slowly Changing Dimensions): tipos 1/2/3 para medidas (jogos, provedores, jogadores).
CDC/CDF (Mudança Data/Capture & Feed): Alterações incorporadas para os fatos (taxas, pagamentos, KYC).
Registro de operações: um dado-tabela separado com eventos de edição/adição/eliminação.
Controle de integridade: hashs partituras/arquivos, assinatura de pacotes, combinação de unidades.
6) Evolução dos circuitos e Data Contracts
Contrato como código: padrão, tipos, obrigatoriedade de campos, valores válidos, SLA recente, regras DQ.
Compatibilidade: adicionaram o campo MENOR; mudaram o tipo/semântica → MAJOR com migração e dual-write.
Gate CI: O padrão de mudança do PR é bloqueado se a compatibilidade ou não for violada.
Catálogo/Registry: armazena versões e proprietários ativos/obsoletos.
7) Versionalidade em BI e métricas
Vitrines de ouro certificadas: semântica fixada KPI (GGR, ARPU, retenção).
Dual-run: nova versão da vitrine é construída paralelamente (v2), comparando métricas (tolerance bands).
Gravação de relatórios: cada exportação/dashboard faz referência a 'datapós _ versão' e 'definition _ versão'.
Cortes de calendário: «day-kat», «mês-data» - são registrados na versão dos dados.
8) Versionalidade em ML/MLOps
Modelo Registry: modelo, data, métricas de qualidade, dados de treinamento (datapós _ versão), versões de fic (função _ set _ versão).
Função Store: grupos de fich versionizados; não permitir campos quentes sem uma versão explícita.
Repro conjunto: código de treino (commit), ambiente (Docker/conda lock), cid.
Champion-Challenger: versões paralelas vendidas, relatórios de qualidade, fairness e privacidade.
Rollback: Reversão rápida para o modelo estável anterior e o conjunto de fich.
9) Rollback, backfill e correções
Plano Rollback: Cada MAIOR/MENOR é uma versão clara.
Backfill playbook: origem da verdade, faixa de datas, ordem de contagem, valores de controle, rótulos de «recomputado = true».
Visibilidade de edição: v2 só substitui v1 após a comparação; todos os relatórios «históricos» continuam a fazer referência às suas versões.
10) Segurança e complacência na auditoria
Assinatura de eventos/pacotes: o produtor assina, o consumidor verifica.
Saúde PII: Auditoria armazena tokens que não PII bruto.
Legal Hold: Impede a remoção de versões/logs por um período de investigação.
DSAR: versões encontram e descarregam os registros do sujeito por token; Contam-se as imagens históricas.
11) Métricas e SLO
Repro Rate: proporção de relatórios reproduzidos a partir da versão de dados/código ≥ limite de destino.
Coverage:% tabelas com time-travel/registro de auditoria ativado.
Schema Compatibility Pass: proporção de verificações de compatibilidade bem sucedidas na CI.
Dual-run Delta: variação v1/v2 dentro das tolerâncias.
Rollback MTTR: tempo médio de reversão da versão.
Auditoria de Integração: número de eventos assinados e verificados.
Backfill Sucess: proporção de contas concluídas corretamente.
12) Pattern para iGaming (malas)
Correção da GGR retroativa: o fornecedor repassou RTP - fazendo backfill de factos durante o período, registrando 'recomputado _ at', publicando Release Notas, comparando v1/v2; os relatórios dos meses passados não são reescritos, mas marcamos «a versão corrigida está disponível».
Regras antifrod: Mudamos a semântica de fici - MAJOR, modelos dual-run e vitrines, rollbeck por champion quando regredimos.
KYC/AML: Adicionaram novos estados do provedor - MENOR com nullable; incluímos testes de compatibilidade em contratos.
RG: Definiram a lógica das «séries perdidas» - MENOR + Release Notas e Monitoramento de Influência.
13) Ferramentas e artefatos (categorias)
Catalog/Lineage/Registry: versões de conjuntos/circuitos/vitrines, proprietários, ligações, contratos.
Orquestrador & CI/CD: gates compatibilidade, prol dual-run, publicação de notas de lançamento.
Armazenamento com time-travel: armazenamento de imagens/registros.
Signing & Checksuns: assinatura de pacotes, somas de controle das partições.
Modelo/Função Registry: versões de fic/modelos, relatórios de champion-challenger.
14) Modelos (pronto para uso)
14. 1 Release Notas (esboço)
Versão de 'payments _ gold v2. 1. 0`
Tipo: MENOR (novos campos 'psp _ country', 'method _ group')
Razão: unificação de relatórios PSP/países
Riscos: Impacto sobre os joyons com a vitrine 'risk _ signals'
Validação: dual-run 14 dias, delta ≤ 0. 2% por GGR
Rollback: mudar para 'v2. 0. 3 'através da bandeira do orquestrador
Data do deploy/proprietário/tíquete
14. 2 Passaporte da versão do conjunto
Dataset: `game_rounds_silver`
Versão «2025-11-01T00: 00: 00Z» (snapshot id)
Esquema: 'schema @ 1. 7. 0 '(referência ao contrato)
Origem: Fades de provedor A/B (commit...)
Controle de integridade: checksum, manifesto assinado
DQ: totalidade 99. 9%, frescor ≤ 15 min
Uso: 'games _ perf _ golf v3. x`, `rg_signals v1. x`
14. 3 Ato de auditoria de alterações
Evento: update schema 'kyc _ status' → 'kyc _ status, v2'
Quem: user/service, rol 'Data-Engineer'
Quando: '2025-11-01 09:32:10 + 02'
Porquê: tíquete # 3421 (novos estados do provedor)
Diff: + 'status _ reason' (nullable), enum ampliado
Verificações: CI semver pass, contrato MENOR
Assinatura: 'sig =...', hash diff: 'sha256 =...'
14. 4 Política de Versionalidade (fatia)
MAJOR: quebra a compatibilidade; dual-write ≥ 30 dias; Plano rollback obrigatório.
MENOR: reversível compatível; avisos no diretório; A/B vitrines de 7 a 14 dias.
PATCH: fixação de qualidade/recontagem; Release Notas é obrigatório.
Arquivamento: armazenando ≥ N meses para regulação; WORM para auditoria.
15) Processos (end-to-end)
1. Iniciativa: tíquete de mudança + avaliação de importação por régua.
2. Projeto: atualização do contrato/esquema + Release Notas.
3. Validação de compatibilidade CI, testes DQ, dual-run.
4. Por bandeira, canário; publicar a versão no diretório.
5. Monitoramento: delta v1/v2, KPI, queixas.
6. Retrocesso/Backfill: por playbook na regressão.
7. Pós-mortem, se houver um incidente, atualizações políticas/testes.
16) RACI (exemplo)
Políticas e padrões: CDO (A), Data Governance Council (R/A), DPO/Sec (C).
Contratos/circuitos: Domain Owners (A), Data Stewards (R), Platford/Eng (C).
Orquestração/armazenamento: Plataforma/Eng (R), SRE (C).
BI/métricas: Analytics Lead (R), Product/Finance (C).
Versões ML: ML Lead (A), DS (R), Plataforma (C).
Auditoria/registros: SecOps (R), Auditoria Internacional (C).
17) Mapa de trânsito de implementação
0-30 dias (MVP)
Incluir time-travel/instantâneos para tabelas críticas (payments, game _ rounds, kyc).
Executar os registros de auditoria e assinatura de pacotes inválidos.
Aceitar política SEMVER e modelo Release Notas.
Catálogo: adicionar 'owner', 'schema _ version', 'datapós _ versão' às vitrines top.
30 a 90 dias
Digite dual-run para todos os MENORES/MAIORES; comparação automática v1/v2.
Vincular contratos de compatibilidade CI e DQ.
Regulamento de backfill/rollback; treinar comandos.
Modelo/Função Registry com um conjunto completo de ligações «dannyye→fichi→model→inferens».
3-6 meses
Cobertura completa dos registros de auditoria, armazenamento WORM, relatórios para reguladores.
O Release de Notas Automatizadas do Diff + Régua.
Relatórios Repro Rate/Schema Compatibility/Rollback MTTR em dashboards.
Revezamento trimestral de versão KPI e «congelamento» de definições.
18) Anti-pattern
Alterar a semântica do KPI sem nova versão/lançamento-nota.
Contagem «silenciosa» sem plano backfill ou marca «recomputada».
Armazenamento de PII cru em logs de auditoria.
Falta de dual-run e substituição instantânea de vitrines.
Modelos/vitrines «eternos» sem versão ou origem.
19) Seções relacionadas
Gerenciamento de dados, Origem e Caminho de dados, Controle de acesso, Tocenização, Segurança e Criptografia, Monitoramento de modelos, Ética e DSAR, Federated Learning, ML Confidencial.
Resultado
A auditoria e a versão transformam dados e modelos em um produto confiável, cada alteração é transparente, reproduzida e reversível. Para iGaming, são fundamentos para a confiança no KPI, sustentabilidade da complacência e velocidade de lançamentos seguros.