Dados auto-ajustáveis

1) Definição e metas

Os dados auto-ajustáveis são uma abordagem de engenharia de dados em que os defeitos são detectados automaticamente e as ações corretivas (reparação, reaproveitamento, reconsilização, reindexação) são executadas sem a participação humana ou com a intervenção mínima (human-in-the-loop para as malas sensíveis).
Metas: redução de dados MTTR, aumento da confiança, resistência à deriva e falhas, custo de posse previsível.

2) Falhas típicas que devem ser tratadas

Esquemas e contratos: alterações incompatíveis, colunas desaparecidas, conflitos típicos.
Qualidade/integridade: duplicados, omissões, violações da singularidade/integridade.
Tempo e frescura: atrasos na injeção, «buracos» nas janelas, rasconização TZ/locais.
Identificadores e chaves: mudança de gerador de ID, colisões, chaves naturais flutuantes.
Ordem de eventos: eventos atrasados, reordenamento, rearranjo (at-least-once).
Armazéns: degradação de partituras, arquivos/blocos batidos, distorção de charding.
Permissões/segurança: máscaras/criptografia incorretas, vazamentos de PII em downloads.

3) Pilares de auto-definição

1. Contratos de dados (schemas + regras) com testes automáticos.
2. Piplines Idempotentes (novo lançamento sem efeitos duplos).
3. Registro e reprodutividade (raw/bronze inalterado, lineage).
4. Mecanismos de reparação (replay, backfill, competition, merge-repair, rebuild).
5. Observabilidade e SLO (frescura, cumplicidade, singularidade, latência).
6. Políticas de tomada de decisões (quando automático, quando escalado).

4) Contratos e testes de qualidade

O contrato descreve: padrão, faixa válida, exclusividade, RLS/disfarce, SLA frescura.

yaml dataset: payments 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: created_at; type: timestamp; tz: UTC freshness_sla: 15m constraints:
- "count(distinct txn_id) = count()"
- "pct_null(user_id) < 0. 1%"
privacy:
- mask: card_pan -> BIN6LAST4 actions_on_violation:
- auto_quarantine_partition
- backfill_missing_window
- notify_owner_and_open_ticket

Os testes são feitos a cada passo, com injeção → estagnação → vitrine. A violação de regras ativa reparos automáticos (veja abaixo) e/ou quarentena.

5) Idempotidade e determinismo

Upsert/Merge em chave estável (SCD2 para histórico, SCD1 para corte).
Transformações determinadas: uma entrada → uma saída com parâmetros idênticos.
Controle de versões: capture a versão de código/esquema/camadas e marca de dados (watermark).
Idempotent sink: gravação através de estaging + atomic swap/rename.
Exactly-once é aceitável transporte at-least-once + receptor idumpotente.

6) Mecanismos de conserto automático (repair toolkit)

Replay/Backfill: Reaproveitamento pela janela 't ∈ [T0, T1]' de um registro inalterável (raw).
Reconciação (compilação): compara as unidades/chaves entre camadas (raw ↔ curated ↔ marts) e entre sistemas (origem ↔ DWH).
Deduplation: window-dedup por chave (txn _ id, event _ id) + evristy distâncias (fuzzy para chaves «sujas»).
Competition: transferência de arquivos pequenos para grandes partituras (Parquet/ORC), reindexação.
Merge-repair: Em caso de conflito de gravações, os predadores de prioridade (por fonte/hora/versão).
Rebuild índices/materializações: recontagem de unidades/cube/roll-up.
Quarantine/Shadow: As partições suspeitas são isoladas; os consumidores lêem um ramo limpo.
Schema mediation: Seletor automático de projeção (preenchimento de default, colunas computáveis) em alterações menores.

7) Proteção de armazenamento e integridade

Valores de cheque e validação de blocos (CRC, paridade).
Armazenamento quórum (RAFT/Paxos-sistemas compatíveis, quorum reads/writes).
Codificação de apagagem (erasure coding) para redundância econômica.
Versioning de objetos (object store versioning, undelete).
Atomic commit в Lakehouse (transaction log, ACID-таблицы: Delta/Iceberg/Hudi).

8) Ordem de eventos e «realidade suja»

Eventos atrasados: mantenha lateness-window, use watermark 'e; Reaproveitamento de janelas.
Nova entrega: dedup global 'event _ id', tabela idempotency-keys.
Tempo deslocado: normalização de TZ, armazenamento de 'ingested _ at' e 'event _ time'.
Out-of-order: unidades baseadas em event _ time ajustado por watermark.

9) Lógica decisória (policy engine)

Regra: «Que anomalia → que tipo de ação → quais são os limites → quem são os donos».

yaml policy: payments_freshness detect: freshness_delay > 15m auto_actions:
- trigger: backfill(last_60m)
- if: gap_persisted > 30m then: quarantine_partition(date=today, hour=current_hour)
escalate:
- if: gap_persisted > 60m -> page_oncall:data guardrails:
- do_not_expose_unverified_to_marts

10) Observabilidade e SLO para dados

• Frescura (Freshness) vitrine ≤ 15 min
• Totalidade (Completeness)> 99. 5% em campos-chave.
• Exclusividade das chaves (Uniqueness): Duplicado <0. 01%.
• Latitude de cálculo: p95 <5 min
• Sustentabilidade de reparos: MTTR-data <30 min

Métricas e alertas: Exponha em Prometheus/Grafana; construa uma fita prioritária de incidentes de dados.

11) Reconsilização e confecção (práticas)

«Count/sum/min/max» entre camadas/sistemas na janela deslizante.
Combinação de chaves: variação simétrica de multiplicidade de ' = (A\B) (B\A)'.
«Check job» periódico: comparação com a origem, verificação seletiva no primário.
Pagamentos/finanças: entrada dupla (duplo-entry), cut-off diurno, registro de ajuste.

12) Gerenciamento de esquemas e evolução

SemVer para diagramas: MAJOR (quebra )/MENOR (adiciona )/PATCH (corrige).
Contratos em CI/CD: schema-diff, compatibilidade, gerações automáticas de migração.
Backfill-gancho: Quando MENOR adicionar default/campos computáveis, contar as vitrines.
Projeções flexíveis: os leitores leem subconjeitos de colunas; Não permitimos «SELECT».

13) Segurança, privacidade, complacência

RLS/CLS: filtros de linha/coluna, especialmente nos ramos repair e exportação.
Camuflagem PII: determinação para dedução sustentável.
Auditoria de acesso/exportação: quem viu o que exportou, para onde enviou.
DSAR/Retenção: Auto-remoção/anonimato em processos repair; Os desvios levam em conta os requisitos legais.

14) Custo e desempenho

Costa-aware backfill: limite a largura das janelas (por exemplo, deslizando 3-7 dias).
Materializações e cachês: apenas as partições que mudaram (incremental).
Priorização: primeiro vitrines críticas (finanças, riscos), depois análises.
Reparações off-peak: janelas noturnas/baixa prioridade no planeador.

15) Testes e simulações de incidentes

Chaos-data-testing: rompa deliberadamente as partições/esquemas em um stage.
Atrasos falsos simulando omissões de batch, out-of-order, duplicados.
Golden datasets: referências para o ajuste após o reparo.
GameDays: treinos regulares da equipe de runbook's.

16) Antipattern

Correções «invisíveis»: edição silenciosa sem auditoria ou relatórios.
Backfill's não tocados: nenhuma fonte de verdade/versão de fórmulas.
Pesadas solicitações em live para o OLTP durante a reparação: extraia a proda.
SELECT dos consumidores: quebra em qualquer alteração MENOR.
A única chave de dedução é falta de chaves fallback/assinaturas hash.

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

1. Discovery: conjuntos críticos/métricas, riscos, proprietários; mapa das dependências.
2. Contratos e testes: formalize os circuitos/regras na CI; publish glossário.
3. Idempotidade: troque os piplins-chave para upsert/merge, atomic sink.
4. Registro Raw e lineage: camada imutável, metadados completos, watermark 'i.
5. Repair-mecânicos: backfill/replay, dedup, competition, quarantine; policy engine.
6. Observabilidade e SLO: dashboards de qualidade, alertas, fita prioritária.
7. Chaos-data e treinos: exercício regular + runbook 'i.
8. Otimização do custo: redesenhar os cálculos e priorizar as janelas.

18) Folha de cheque antes do lançamento

• Os contratos de dados e testes de qualidade cobrem conjuntos críticos.
• As pipas são idimpotentes; Há um omic commit e reversões.
• As políticas de escalação foram configuradas por backfill/replay e quarantine.
• Métricas Freshness/Completeness/Uniqueness/Latency e alertas vendidas.
• A auditoria de edição/reparos está ativada; armazenam versões de fórmulas e vitrines.
• Os DSAR/Retenção são executados em reparos e retrocessos.
• Há runbook 'e, realizado o exercício, o alvo MTTR foi fixado.
• O valor do backfill 'ov é limitado ao orçamento-guarda.

19) Exemplos de trabalho automático (modelos)

«Falhar a frescura da vitrine X» → backfill (last _ 2h) → senão ok em 30 min → quarantine + página on-call.
«Duplicar txn _ id» → incluir um dedup mais rigoroso com origem → relatório de causa.
A «alteração de padrão MENOR» → gerar um campo de default computável → rebuild.
A «perda de partituras» → ser restaurada de um objeto versionizado → verificado com uma quantia de cheque.

O resultado é que os dados auto-ajustáveis não são apenas um «script de reparação», mas uma arquitetura de sistema: contratos formais, piplines idumpotentes, registros confiáveis, mecânicos de reparação automatizados e observabilidade transparente com SLO rigoroso. Este sistema não só se corrige, mas também transforma os incidentes em eventos controlados com um custo compreensível e tempo de recuperação.