データの整合性

1）データ整合性とは

データの整合性は、ソースや変換からストアフロント、API、エクスポートまで、データがライフサイクルを通じて正しい、一貫性のある、一貫性のあるものであることを保証するための一連のプロパティとコントロールです。目的は、同じステートメントが繰り返されたときに同じ答えを与え、変更が追跡可能で検証可能であることです。

2）誠実さの種類と彼らが住んでいる場所

エンティティ-一意の主キー、重複はありません。
参照有効なFKリンクは「ハング」リンクがない。
ドメイン有効範囲とフォーマット（タイプ、長さ、ディレクトリ）。
ビジネスルール：サブジェクト領域不変量（残高≥ 0、取引金額=0など）。
一時的：単調とタイムスタンプの一貫性、正しいタイムゾーン。
アクセスポリシー：RLS/CLSは、可視データの論理的整合性に違反しません。

3）データ契約とスキーマ（真実の源）

私達はセットおよびでき事のための形式的な契約を置きます；入り口と変身後に適用します。

yaml dataset: payments primary_key: txn_id foreign_keys:
- fk: user_id -> users.user_id 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: currency, type: string, in: [USD,EUR,TRY,UAH]}
- {name: event_time, type: timestamp, tz: UTC}
dq_rules:
- "duplicates(txn_id)=0"
- "ref_integrity(user_id, users.user_id)=true"
- "sum(amount) >= 0"
evolution:
semver: [MAJOR, MINOR, PATCH]
breaking_changes_require: approval:data-governance

4）トランザクション保証と分離

OLTPのための酸：原子性、一貫性、分離、耐久性。
絶縁レベル：Read Committed/Repiatable Read/Serializable-「dirty 「/unique/phantom readsのリスクを選択します。
OLAPとlakehouse：テーブルのatomicコミット（トランザクションログ）、idempotent sink、 schema-evolutionと互換性コントロール。
KPI数式の整合性：セマンティック層→レポートとAPIのための1つの真実。

5）分散システム： 順序、繰り返し、idempotency

イベント順序：'event_time'+'ingested_at'、透かしと遅延公差を使用します。イベント時間に基づいて集計します。
再配達（少なくとも一度）：グローバル'event_id'、 idempotency keys tables、 upsert/merge by stable key。
アウトオブオーダー：ウィンドウの再計算、遅延戦略、補償。
正確に1回の意味：トランスポートは最低1回、レシーバ-idempotent。

6）各層の整合性検証（DQ）

• 鮮度/完全性/一意性/有効な値/参照整合性。
• 異常：重複のバースト、タイムギャップ、分布の急激なシフト。
• KPI数式の制御：計算のバージョニングと結果を一致させるためのテスト（ゴールデンセット）。
• 輸出管理-違反（検疫）を伴うセットの発行を禁止します。

yaml expect_column_values_to_be_unique: {column: txn_id}
expect_column_values_to_not_be_null: {column: user_id}
expect_column_values_to_be_in_set: {column: currency, value_set: [USD,EUR,TRY,UAH]}

7）財務および業務の完全性

ダブルエントリー：残高のデビット/クレジット。切断の要約の和解。
総不変量：配当金額=配当額+手数料+調整。
運用不変量：SLA/ガードレールメトリクスはビジネスルールを破りません（たとえば、自動修復は重複を作成しません）。

8）系統、監査および再現性

Linage：ショーケース/機能のソース。変革と所有者の可視性。
監査証跡：who changed who what、 when and what；schema/formula/jobのバージョン。
スナップショット/チェックポイント：過去のレポートを再計算して確認する機能。
Repro：同じスライスで同じクエリ→同じ結果（バージョンとレイヤー）。

9）完全性を損なうことなくセキュリティとプライバシー

RLS/CLS： row/columnフィルタは不変量に違反してはいけません（例えば、可視サンプルの合計は宣言されたものと一致するはずです）。
マスキング/トークン化：デッドアップと参照整合性を維持するための決定論的戦略。
暗号化：圧縮の後でチャネルおよび「ディスク」で；キー管理およびアクセスの監査。
DSAR/Retention： delete/anonymizeは接続性（カスケードポリシー）を破壊しません。

10）セルフサービスおよび自動修理

隔離：疑わしいパーティー/バッチの分離；消費者-「クリーン」ブランチ。
リプレイ/バックフィル：変更できない生のログからウィンドウをリプレイします。
調整：レイヤーとシステムの調整（raw↔curated↔marts；istochnik↔DWH）。
Dedup/Compaction/Rebuild：インデックス/集計を修復するためのシステムプロシージャ。
Policy-as-code： 「what anomaly→what action→thresholds→escalation」。

11）モデリングおよびストレージ・プラクティス

安定したキー：代理PK （UUID/ULID）、参照帳の変更されていない自然なキー。
Normalizatsiya↔denormalizatsiya：ソース内のFK接続、ロジックバージョン制御による非正規化ショーケース。
SCD1/SCD2：寸法のガイド履歴。
ソート/クラスタリング：RLE/ゾーンマップを改善し、和解を簡素化します。
ハッシュとチェックサム：ファイル/バッチの整合性をチェックします。

12）時間とレポートの整合性

フォーミュラバージョン：2025年1月のレポートは、バージョンX式で再現する必要があります。
カットオフと「期間閉鎖」：店の窓とアーカイブスライスを凍結します。
遅れて到着した事実：補充のメカニズムとレポートのバージョンマークとの再集計。
オーバーライドの文書化：手動調整-監査のみ。

13）統合とAPI

API契約： スキーマ、タイプ、必須フィールド、エラーコード；バージョン管理（v1/v2）

入り口での検証：悪いペイロードを拒否し「、静かに修復」しないでください。
Idempotent POST： idempotenceキー、retry safe。
ファイルへのエクスポート：バッチ一貫性、ハッシュ、署名。

14） Antipatterns

SELECT in sales queries and blizzards-MINOR evolutionで分解します。
FK「言葉で」：実際の参照チェックはありません。
監査と報告のないサイレントデータ修正。
TZとタイムフォーマットを1セットでミックスします。
「グリップ」KPIはバージョンとログなしで上書きされます。
フォールバック戦略のない単一の重複除外キー。
リンクチェックをカスケードすることなくDSAR削除。

15）実装ロードマップ

1.在庫と重大性：セット/イベントマップ、所有者、リスク、不変量。
2.契約とスキーム：タイプ/制約/FK、 CI互換性チェックを形式化します。
3.パイプラインのDQ：鮮度/完全性/独自性/RI、検疫、アラート。
4.トランザクション基盤：アトミックシンク、アップサート/マージ、SCD履歴、数式バージョン管理。
5.リネージと監査：ディレクトリ、トレース、変更ログ、アクセスログ。
6.修復ポリシー：リプレイ/バックフィル/dedup/コードとして調整する。SLO MTTRデータ。
7.セキュリティ/priv： RLS/CLS、マスキング、暗号化、DSARプロセス。
8.レポート：カットオフ、フリーズスライス、KPIバージョン管理。

16）プレリリースチェックリスト/ディスプレイケース

• PK/FKとドメイン制約が設定され、テストに合格します。
• スキーマ/数式のバージョン管理が有効になっています。schema-diffグリーン。
• DQルール（鮮度/完全性/独自性/範囲/RI）は緑色です。
• Idempotentエントリ：upsert/merge、 idempotenceキー（イベント用）。
• 時間：'event_time'と'ingested_at'、 TZ=UTC；遅いデータポリシー。
• 血統と目に見える監査；検疫と警告が含まれていました。
• RLS/CLS/マスキングは不変量およびRIに違反しません。
• テストされるDSAR/Retention；カットオフ/アーカイブの準備ができました。

17）ミニテンプレート

SQL： 参照整合性チェック

sql select count() as orphans from fact_payments f left join dim_users u on f.user_id = u.user_id where u.user_id is null;
-- ожидаем orphans = 0

検疫/修復ポリシー（擬似YAML）

yaml policy: payments_integrity detect:
- rule: duplicates(txn_id) > 0
- rule: ref_integrity(user_id, users.user_id) = false auto_actions:
- quarantine_partition: {date: today}
- trigger_replay: {window: "last_2h"}
escalate_if:
- condition: violations_persist>30m page: "oncall-data"

測定SCD2図

sql
-- dim_user_status (SCD2)
user_id, status, valid_from, valid_to, is_current

18）ボトムライン

データの完全性は、単一のチェックではなく、エンドツーエンドの保証システムです。正式な契約と制限、トランザクションと分散不変、修理の検証と自動化、ラインと監査、プライバシーと権利。これらの要素が連携すると、データはソリューションの信頼できる基盤となり、インシデントはまれで短く予測可能です。