セルフヒーリングデータ

1）定義と目的

自己修復データは、欠陥が自動的に検出されるデータエンジニアリングへのアプローチであり、修正アクション（修復、再配達、ロールバック、再統合、再インデックス化）は、人間の介入なしまたは最小限の介入（敏感なケースのためのヒューマンインザループ）で実行されます。
目標：データMTTRの削減、信頼の向上、ドリフトおよび失敗に対する回復力、予測可能な所有コスト。

2）のために扱われるべき典型的な不具合

スキームと契約：互換性のない変更、列の欠落、タイプ競合。
品質/整合性：重複、省略、独自性/参照整合性の違反。
時間と新鮮さ：注入遅延、窓の「穴」、TZ/ロケールの非同期。
識別子とキー：IDジェネレータ、衝突、浮動天然キーの変更。
イベントの順序：遅いイベント、並べ替え、再配達（少なくとも1回）。
ストレージ：バッチの劣化、壊れたファイル/ブロック、シャーディングの歪み。
権利/セキュリティ：不正確なマスク/暗号化、アップロード中のPIIリーク。

3）自己治癒の柱

1.自動テストによるデータ契約（スキーマ+ルール）。
2.Idempotentパイプライン（ダブルエフェクトなしで再起動）。
3.ジャーナリングと再現性（生/青銅不変、血統）。
4.修復メカニズム（リプレイ、バックフィル、圧縮、マージ修復、再構築）。
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） Idempotenceおよびdeterminism

安定したキーでUpsert/Merge（履歴のSCD2、スライスのSCD1）。
決定論的変換：1つの入力→同じパラメータを持つ1つの出力。
「バージョン管理」（Versioning）-コード/スキーマ/レイヤーのバージョンとデータラベル（透かし）を修正します。
Idempotent sink：ステージング+アトミックスワップ/名前変更による記録。
正確に一度の意味：許容可能な「at-lost-once」トランスポート+idempotentレシーバ。

6）修理ツールキット

Replay/Backfill：ウィンドウが変更できないログ（raw）から［T0、 T1］'を∈しないように再納品します。
調整：レイヤー間の集計/キーの比較（raw ↔ curated ↔ marts）とシステム間（source ↔ DWH）。
重複排除：キー（txn_id、 event_id）によるウィンドウデダップ+距離ヒューリスティック（汚れたキーのファジー）。
コンパクション：小さなファイルを大規模なパーティー（Parquet/ORC）に転送し、再インデックスを作成します。
Merge-repair：レコードが競合している場合、優先順位は（source/time/versionによって）予測されます。
インデックス/マテリアライゼーションの再構築：集計/キューブ/ロールアップの再計算。
隔離/影：疑わしい当事者は自分自身を隔離します。消費者は「きれいな」糸を読みます。
スキーマメディエーション：マイナーな変更のための自動プロジェクションセレクター（デフォルトの充填、計算可能な列）。

7）貯蔵の保護および完全性

チェック量とブロック検証（CRC、パリティ）。
クォーラムストレージ（RAFT/Paxos互換システム、クォーラム読み取り/書き込み）。
コスト効率の高い冗長性のための消去コーディング。
オブジェクトストアのバージョン管理（元に戻す）。
アトミックコミットLakehouse（トランザクションログ、ACID- таблицы：デルタ/アイスバーグ/フーディ）。

8）イベントの順序と「汚い現実」

Lateイベント：lateness-window、 use watermark 'and；ウィンドウを再計算します。
再配達：グローバル'event_id'によるdedup、 idempotency-keysテーブル。
オフセット時間：TZを正規化し、'ingested_at'と'event_time'を格納します。
アウト・オブ・オーダー：ウォーターマーク調整によるevent_time-based集計。

9）意思決定ロジック（ポリシーエンジン）

ルール：「what anomaly→what action→what thresholds→who is the owner」。

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

• ディスプレイケースの鮮度≤ 15分。
• 完全性>99。キーフィールドの5％。
• 一意性：重複<0。01%.
• 計算レイテンシー：p95 <5 min。
• 修理安定性：MTTRデータ<30分。

メトリックとアラート：Prometheus/Grafanaでの展示;データインシデントの優先テープを作成します。

11）和解（実践）

スライドウィンドウのレイヤー/システム間の集計：'count/sum/min/max'をチェックします。
主な和解：セット'Δ=（A\B） ∪ （B\A）'の対称的な違い。
定期的な「監査ジョブ」：ソースとの比較、ソースでの選択的チェック。
支払い/ファイナンス：二重エントリ、毎日のカットオフの和解、調整ログ。

12）回路管理と進化

スキームのSemVer： MAJOR （breaks ）/MINOR （adds ）/PATCH （fixes）。
CI/CDのコントラクト：schema-diff、互換性、マイグレーションの自動生成。
バックフィルフック：MINORでデフォルト/計算フィールドを追加し、ショーケースを再計算します。
柔軟な投影：読者は列のサブセットを読み取ります。「SELECT」を禁止します。

13）セキュリティ、プライバシー、コンプライアンス

RLS/CLS：特に修復ブランチやエクスポートでの行/列フィルタ。
持続可能な重複排除のためのPIIベースのトークン化。
Access/Export監査：エクスポート先、送信先を誰が確認したか。
DSAR/保持：修復プロセスにおける自動削除/匿名化；キックバックは法的要件を考慮します。

14）コストとパフォーマンス

コスト配慮のバックフィル：ウィンドウの幅を制限します（たとえば、3〜7日間のスライド）。
マテリアライゼーションとキャッシュ：変更されたバッチのみの再計算（増分）。
優先順位付け：最初の重要なショーケース（金融、リスク）、次に分析。
オフピーク修理：夜間の窓/スケジューラの優先度が低い。

15）テストおよびインシデントのシミュレーション

カオスデータテスト：意図的にステージ上のパーティション/回路を壊します。
偽の遅延：偽のバッチ、順序外、重複。
ゴールデンデータセット：修復後の調整のベンチマーク。
GameDays：ランブックの定期的なチームトレーニング。

16） Antipatterns

「見えない」修正：監査やレポートなしでサイレント編集。
テストされていないバックフィル：真実のソース/数式のバージョンはありません。
修理中にOLTPへの重いライブリクエスト：prodを完了します。
消費者の選択：マイナーな変更で壊れます。
重複除外の唯一の鍵は、フォールバックキー/ハッシュ署名がないことです。

17）実装ロードマップ

1.発見：重要なセット/指標、リスク、所有者；依存関係マップ。
2.契約とテスト：CIでスキーム/ルールを形式化する。用語集を公開します。
3.Idempotency： upsert/merge、 atomic sinkでキーパイプラインを書き換えます。
4.Raw log and lineage： immutable layer、 full metadata、 watermark 'and。
5.修理メカニクス：バックフィル/リプレイ、dedup、圧縮、検疫；ポリシーエンジン。
6.観測性とSLO：品質ダッシュボード、アラート、優先度テープ。
7.カオスデータとトレーニング：通常のエクササイズ+runbook'と。
8.コストの最適化：増分再計算、ウィンドウの優先順位付け。

18）プレリリースのチェックリスト

• データ契約と品質テストは重要なセットをカバーします。
• パイプラインはidempotent；原子コミットとプルバックがあります。
• バックフィル/リプレイと検疫が設定され、エスカレーションポリシーが明記されています。
• 新鮮さ/完全性/一意性/レイテンシーメトリックとprod内のアラート。
• 編集/修理の監査が含まれています。数式とストアフロントのバージョンを保存します。
• DSAR/Retentionは修理およびロールバックのために続きます。
• runbookがある'と、実施された演習、MTTR-target修正。
• バックフィルのコストは予算の警備員によって制限されています。

19）オートアクションの例（テンプレート）

「窓の鮮度障害X」→backfill （last_2h）→30分でOKでない場合→検疫+コールページ。
「Duplicate txn_id spike」→厳格なdedup+source reconciliation→原因レポートを含む。
「MINORスキーマ変更」→計算されたデフォルトフィールド→再構築の集計を生成します。
「バッチの損失」→リストア→バージョン管理対象オブジェクトからのチェック金額の確認。

ボトムライン：自己修復データは1つの「修復スクリプト」ではなく、システムアーキテクチャです。形式的な契約、アイデンポテントパイプライン、信頼性の高いロギング、自動化された修復メカニクス、および厳格なSLOによる透明なオブザビリティです。このようなシステムは、それ自体を修復するだけでなく、インシデントを理解できるコストと回復時間で管理可能なイベントに変えることもできます。