データ品質管理

1）目的と原則

理由：信頼性の高いレポート（GGR/税金）、不正防止およびRGモデル、コンプライアンスアップロード、製品およびパーソナライゼーション。

• Schema-first&Contracts：契約データを公開するには、すべてのソースが必要です。
• DQ-as-code：リポジトリ内のルール、バージョン、テスト、レビュー。
• Observation-by-default： metrics/logging/lineage。
• プライバシー・バイ・デザイン：PII最小、マスキングおよびRLS/CLS。
• コスト意識：重要なルールの優先順位付け、スマートサンプル。

2）品質測定の分類

「完全性」（Completeness）-必須フィールド/行の割合。
Validity-Matches types/ranges/reference books。
一意性：重複したキー/イベントはありません。

一貫性： 参照整合性、ビジネス不変性

正確さ-「真の」ソースにアプローチ（要約和解）。
タイムライン/鮮度-材料の遅延。
Lineage Integrity：変換の原点/バージョンを保持します。

品質と重要性KPI （critical/major/minor）は、ドメインごとに定義されています。

3）契約とスキーム（真実の源）

データ契約：JSON スキーマ/Avro/OpenAPI/AsyncAPI、レジストリによってホストされています。
安定性：後方互換性のある変更-nullableを加えること；breaking-新しいバージョン+ダブルエントリ。
トレーサビリティ：イベント-'event_id'、 'trace_id'、 'schema_version'、 'source'。

4） DQ-as-code： アーティファクト構造

/dq/
rules/
silver. payments. yaml gold. ggr_daily. yaml checks/
sql/
python/
policies/
severities. yaml notifications/
routes. yaml

ルール： 宣言YAML/SQL；

重要度： マッピング→アラートチャンネル/エスカレーションレベル；

CI：回路リンター、互換性試験、ドライラン/シミュレータ。

5）サンプルルール（YAML）

yaml table: silver. payments owner: data-payments slo:
freshness_minutes: 15 completeness_percent: 99. 5 rules:
- name: amount_positive severity: critical type: range column: amount min: 0. 01
- name: currency_in_whitelist severity: major type: in_set column: currency set: [EUR, USD, GBP, TRY, BRL]
- name: unique_tx severity: critical type: unique columns: [transaction_id]
- name: fk_user_exists severity: critical type: foreign_key column: user_pseudo_id ref_table: dim. users ref_column: user_pseudo_id
- name: ts_monotonicity severity: minor type: temporal expression: "ts between date_sub(now(), interval 90 day) and now()"

6） SQLテスト（サンプル）

キーの独自性

sql
SELECT transaction_id, COUNT() AS c
FROM silver. payments
GROUP BY transaction_id
HAVING COUNT() > 1;

必須フィールドの完全性

sql
SELECT COUNT() AS nulls
FROM silver. payments
WHERE amount IS NULL OR currency IS NULL OR ts IS NULL;

参照/一貫性

sql
SELECT p. currency
FROM silver. payments p
LEFT JOIN ref. currencies r ON p. currency = r. code
WHERE r. code IS NULL;

7）ストリーミングDQ（リアルタイム）

Ingest-validation：スキーマ検証、size-limits、 types、 enum's。
オンストリームチェック：dedup '（event_id、 source）'、許可された遅延、通貨/金額の妥当性。
境界：クリティカルエラー→DLQ+アラート；critical→tagではなく、（'dq_flag'フラグで）スキップします。
メトリクス：パーティー別の完全性/遅延/dup-rate。

8）エラーや例外の処理

DLQ/検疫：病気の記録は保持され、修正のために利用可能です。
例外レコード：除外カード（所有者、日付、理由、エリア）。
オートフォールバック：ディスプレイケースの最後の正しいスナップショットを使用します。
閉じるSLA： critical-≤ 24-48時間；major-≤ 5人の従業員日。

9）プライバシーとコンプライアンスの調整

PII最小化：分析レイヤーで「raw」 PIIをチェックしないでください。エイリアスを使用します。
RLS/CLS-Checkはフィールドマスキングに基づいて実行されます。
地域化：ルールは「管轄権」（EEA/UK/BR）を考慮に入れます。
法的保留：保留の一環としてアーカイブを書き換えることはありません。

10）観察可能性、SLI/SLOおよび警報

• 鮮度P95（シルバー）：≤ 15分
• 完全性（クリティカルタイプ）：≥ 99。5%.
• 有効性（スキーマ）：≥ 99。9%.
• 重複レート：≤ 0。1%.
• DQインシデントMTTR： ≤ 24-48インチ。

アラート：クリティカル、アンチエイリアス、メンテナンスウィンドウのページャー。

11）ダッシュボード（最小セット）

ドメインと市場による鮮度/完全性ヒートマップ。
インシデント率と修正コストによるトップNテーブル。
DQファネル： ingest→silver→gold（損失/修正）。
クリティカルレポート用のLinedgeマップ（レギュレータ/GGR/RG/AML）。
「レガシー」スキーマとクライアント（SDK/スキーマバージョン）のマップ。

12）プロセスとRACI

R（責任ある）：データエンジニアリング（テーブル上のルール）、ドメイン所有者（意味論）。
A（説明責任）：データ/CDOの責任者。
C（コンサルティング）：コンプライアンス/法的/DPO、アーキテクチャ、SRE。
I （Informed）： BI/Продукт/Маркетинг/Финансы/Операции。

ルールライフサイクル：オファー→レビュー→「ダークラン」→インクルージョン→モニタリング→レトロスペクティブ。

13）和解と正確さ

チェックサム/トランザクション：OLTP/プロバイダ （PSP/KYC）のボルト。
2ループ比較：選択的検証のための独立したパイプライン。

許容誤差は、メトリックによるパーセンテージしきい値です（例： GGR分散≤ 0。2%).

毎日の行為：監査の和解レポート。

14）コストと優先順位付け

重要なルールをより頻繁に実行（ストリーミング/時間）、マイナー-毎日。
重いテーブルのフェッチと実体化されたチェックを使用します。
コスト/クエリとコスト/GBを追跡し、クラスタリング/インデックスを適用します。
チームのコンテキストでDQの予算を割り当てます（チャージバック）。

15）ゴールドストアフロント用テンプレート（GGRデイリー例）

yaml table: gold. ggr_daily owner: fin-analytics slo:
ready_by_local_time: "06:00"
rules:
- name: ggr_not_negative severity: critical type: range column: ggr min: 0. 0
- name: market_known severity: major type: in_set column: market set_ref: ref. markets
- name: fx_source_present severity: major type: not_null column: fx_source
- name: completeness_by_market severity: critical type: completeness partition_keys: [event_date, market]
expected_rows_expression: "ref. expected_activity(event_date, market)"

16）質の高いインシデント： 管理とコミュニケーション

発券：添付された選択とメトリックでタスクを自動作成します。
Commテンプレート：影響を受けると製品の所有者/レギュレータに通知します。
Post-mortem：根本原因（スキーマドリフト、アップストリームバグ、ロード）、CAPAアクション、「回帰リターン」の制御。

17）実装ロードマップ

1.重要なテーブルのカタログ（支払い、ゲームプレイ、GGR、コンプライアンス）。

2.10-15キーチェック+CI検証のYAMLルール。

3.新鮮さ/完全性ダッシュボードと重要なアラート。

4.DLQ/検疫+ランブックの修正。

• ルール拡張（FK/精度）、ドライランシミュレータ、A/Bインクルージョン。
• 血統統統合、例外配置およびSLA。
• 「ノイズの多い」ソースのingestでDQをストリーミングします。

• ルール、コスト指標によるドキュメントの自動生成。
• 「コントロール輪郭」（独立した和解）、毎週のレトロスペクティブ。
• 標準ドメインチェックのレジストリであるRule-as-CodeプラットフォームSDK。

18）売り上げ前のチェックリスト

• レジストリの契約とスキーマ、互換性テストは合格します。
• YAMLルールが凍結され、重症度/エスカレーションが割り当てられます。
• ダッシュボードとアラートがアクティブになります。SLOは定義され、合意されます。
• DLQ/検疫が利用可能で、ランブックが文書化されています。
• 法令・コンプライアンスに同意した例外・和解手続き。
• 重い要求の点検そして限界の費用の測定。

19）頻繁なミスとそれらを回避する方法

契約なしの生データ：スキーマファーストテストとコンシューマテストを入力します。
「マニュアル」チェック：DQ-as-codeとCIに変換します。
優先順位付けなし：個別のクリティカル/メジャー/マイナーおよびアラートチャンネル。
DLQはありません。エラーを処理するものは何もありません。
コストを無視：プロファイルクエリ、マテリアライゼーションを使用します。
No post-mortems：エラーが繰り返されます-CAPAと回帰制御を入力します。

20）ボトムライン

データ品質管理システムは、散乱チェックのセットではなく、管理されたプログラムです。契約とスキーム、DQ-as-code、 observabilityとSLO、インシデントと和解規律。この記事に従うことで、規制報告、製品ソリューション、リアルタイムのリスク検出器に十分な再現性、検証可能、費用対効果の高いデータを受け取ることができます。