自修复数据

1）定义和目标

自我修复数据是一种数据工程方法，其中自动检测到缺陷，并且在不涉及人员或最少干预的情况下（针对敏感案例的人为环路）执行纠正措施（修复，重新交付，回滚，重新分配，重新索引）。
目标：降低MTTR数据，提高信心，抵御漂移和故障，可预测的拥有成本。

2）需要治疗的典型故障

方案和合同：不兼容的更改，丢失的列，类型冲突。
质量/完整性：复制、跳过、独特/指南完整性违规。
时间和新鲜度：喷射延迟，窗户上的"漏洞"，TZ/局部同步。
ID和密钥：更改ID生成器、冲突、浮动自然密钥。
事件顺序：迟到事件、重新排序、重新交付（at-least-once）。
存储：批次降级、文件位/块、缓存。
权利/安全：不正确的掩码/加密,卸载中的PII泄漏。

3）自我修复的支柱

1.具有自动测试的数据合同（schemas+规则）。
2.等效管线（无双重效果的重新启动）。
3.日志和可重复性（raw/bronze不可改变，lineage）。
4.修复机制（replay、backfill、compaction、merge-repair、rebuild）。
5.可观察性和SLO（新鲜，丰度，独特性，潜伏性）。
6.决策策略（当自动编写，升级时）。

4）合同和质量测试

合同描述：电路，允许的范围，唯一性，RLS/掩饰，SLA新鲜度。

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

在每个步骤中进行测试：注入→舞台→展示。违反规则会激活自动维修（见下文）和/或隔离。

5）相似性和决定性

Upsert/Merge按稳定键（历史SCD2，切片SCD1）。
确定性变换：在相同的参数下一个输入→一个输出。
版本控制：捕获代码/电路/图层版本和数据标签（watermark）。
Idempotent sink：通过staging+atomic swap/rename写入。
Exactly-once的含义：可以接受"at least-once"运输+等效接收器。

6）自动维修机制（修复工具包）

Replay/Backfill：从未更改的日志（raw）重新传送到't ∈ ［T0, T1］'窗口。
Reconciliation（核对）：对图层（raw ↔ curated ↔ marts）和系统（source ↔ DWH）之间的单元/密钥进行比较。
Deduplication：按键（txn_id，event_id）+距离启发式缩写（"肮脏"键的模糊）。
Compaction：将小文件转换为大批次（Parquet/ORC）,重新索引。
Merge-repair：在记录冲突中-优先级谓词（按源/时间/版本）。
Rebuild索引/实例化：重新计算聚合/cube/roll-up。
Quarantine/Shadow：可疑派对被隔离；消费者正在阅读"干净"的树枝。
Schema mediation：次要变化下的自动投影选择器（填充默认值，可计算列）。

7）存储保护和完整性

支票和块验证（CRC，平价）。
定量存储（RAFT/Paxos兼容系统，quorum reads/writes）。
擦除编码（erasure coding）以实现经济高效的冗余。
对象转换（对象存储版本，undelete）。

Atomic commit в Lakehouse (transaction log, ACID-таблицы: Delta/Iceberg/Hudi).

8）事件顺序和"肮脏的现实"

后期事件：保持后期窗口，使用watermark'和；重新计算窗口。
重新交付：通过全局"event_id"，idempotency-keys表进行删除。
偏移时间：TZ正常化，存储"ingested_at"和"event_time"。
订单外：基于event_time的单元，并根据水厂进行调整。

9）决策逻辑（策略引擎）

规则： "什么异常→什么动作→什么阈值→谁是所有者。"

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）数据的可观察性和SLO

• 新鲜（Freshness）店面≤ 15分钟。
• 完整性（Completeness）> 99。5%在关键领域。
• 密钥唯一性（Uniqueness）-副本<0。01%.
• 计算的潜在性：p95 <5分钟。
• 维修稳定性：MTTR-data <30分钟。

度量标准和Alerta：在Prometheus/Grafana中展出；建立优先数据事件磁带。

11）重新融合和匹配（练习）

在滑动窗口中的图层/系统之间对齐聚合："计数/sum/min/max"。
密钥匹配：集合'Δ=（A\B） ∪ （B\A）'的对称差。
定期"审核工作"：与源进行比较，对初选进行抽样检查。
付款/财务：双重记录（双入门）,日间切断对账,调整日志。

12）方桉管理和演变

用于电路的SemVer： MAJOR （断开）/MINOR （添加）/PATCH（修复）。
CI/CD中的合同：schema-diff，兼容性，迁移的自我发生。
Backfill-hook：在MINOR中添加默认值/可计算字段,重新计算店面。
灵活的投影：读者阅读专栏的子集；我们禁止"SELECT"。

13）安全、隐私、合规性

RLS/CLS：字符串/列过滤器，尤其是在修复分支和导出中。
PII掩码：用于持续重复数据消除的确定性（tokenization）。
访问/导出审核：谁看到了导出的内容,发送到哪里。
DSAR/Retention：修复过程中自动删除/匿名；回扣考虑到法律要求。

14）成本和性能

Cost-aware backfill：窗口宽度限制（例如,滑动3-7天）。
实例化和缓存：仅重新计算更改的部分（积压）。
优先级：首先是关键店面（财务，风险），然后是分析。
非峰值维修：夜间窗口/调度器中的低优先级。

15）事件测试和模拟

Chaos-date-testing：故意在摊位上打破部分/计划。

假延迟： 模拟跳过蹦床,出订单,复制.

Golden datasets：修理后对账的基准。
GameDays：团队定期进行跑步训练。

16）反模式

"无形"更正：无审计和报告的无声编辑。
未编号的背景：没有真相来源/公式版本。
修理时对OLTP的大量实时查询：完成插件。
消费者中的SELECT：任何次要更改都会中断。
唯一重复数据消除密钥：不存在fallback键/散列签名。

17）实施路线图

1.发现：关键集/指标，风险，所有者；依赖图。
2.合同和测试：将计划/规则正式化为CI；出版词汇表。
3.相似性：将关键的管道重写为upsert/merge, atomic sink。
4.原始期刊和线条：不变层，完整的元数据，watermark'和。

5.修复力学： backfill/replay，dedup，compaction，quarantine；policy engine.

6.可观察性和SLO：质量差板，Alerta，优先磁带。
7.混沌数据和培训：定期练习+runbook'和。
8.价值优化：增量重新计算,窗口优先级。

18）发行前的支票清单

• 数据合同和质量测试涵盖关键集。
• Piplines是幂等的；有原子评论和回滚。
• 设置了backfill/replay和quarantine,并指定了升级策略。
• Freshness/Completeness/Uniqueness/Latency度量标准和Alerta在销售中。
• 包括编辑/维修审计；存储公式和店面版本。
• DSAR/Retention在修理和回滚时遵循。
• 有runbook'，进行演习，MTTR目标固定。
• backfill 's的成本仅限于预算警卫。

19）自动辅助示例（模板）

"店面X的新鲜度失败"→ backfill（last_2h）→如果不是30分钟→ quarantine+呼叫页面。
"重复txn_id激增"→包括严格的dedup+源对账→原因报告。
"MINOR模式更改"→ →聚集体生成可计算的默认字段。
"分期付款损失"→从经过验证的设施中恢复→支票金额验证。

底线：自修复数据不是一个"修复脚本",而是系统体系结构：正式合同、等效管道、可靠的日志记录、自动修复机制以及具有严格SLO的透明可观察性。这样的系统不仅可以自我管理，而且可以将事件转变为具有可理解的成本和恢复时间的托管事件。