數據質量控制

1）任命和原則

為什麼：可靠的報告（GGR/稅收），防凍和RG模型，合規卸載，產品和個性化。

• Schema-first&Contracts：所有來源都必須公布合同數據。
• DQ代碼：存儲庫中的規則、版本、測試和評論。
• 觀察默認值：度量/邏輯/線性。
• 按設計保密：最低PII，掩碼和RLS/CLS。
• Cost-aware：優先考慮關鍵規則，智能樣本。

2）質量測量分類法

完整性（Full）-必填字段/字符串的比例。
Validity（有效性）：符合類型/範圍/參考。
Uniqueness（唯一性）：沒有重復鍵/事件。
一致性：參考完整性，業務不變性。
Accuracy（精度）：逼近「真實」源（摘要對賬）。
Timeliness/Freshness（及時性）：材料延遲。
Lineage Integrity：保存轉換的起源/版本。

對於每個域，都定義了KPI的質量和關鍵性（臨界/專業/次要）。

3）合同和計劃（真相來源）

數據合同：JSON Schema/Avro/OpenAPI/AsyncAPI，位於Registry中。
穩定性：反向兼容的更改-添加無效；破解-新版本+雙重記錄。
可跟蹤性：在事件中-「event_id」，「trace_id」，「schema_version」，「source」。

4） DQ代碼： 工件結構

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

規則： 聲明性YAML/SQL；

嚴重性： 映射→警報通道/升級級別；

CI：電路linter，兼容性測試，「dry-run「/模擬器。

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驗證：計劃驗證，尺寸限制，類型和enum's。
流式檢查：dedup「（event_id，source）」，allowed lateness，貨幣/金額的有效性。
邊界：嚴重錯誤→ DLQ+警報；不是關鍵的標簽→，而是跳過（帶有「dq_flag」標誌）。
度量標準：按批次列出completeness/lag/dup-rate。

8）處理錯誤和例外

DLQ/Quarantine：「病態」記錄被保留,可供修復。
Exception records：排除卡（所有者、期限、原因、區域）。
自動倒退：使用最後一個正確的店面快照。
關閉SLA：關鍵-≤ 24-48小時；主要是≤ 5個奴隸。天。

9）與隱私和合規性保持一致

PII最小化：不要在分析層中檢查「原始」PII；應用別名。
RLS/CLS：檢查是在考慮字段掩蔽的情況下進行的。
區域化：規則考慮到「司法」（EEA/UK/BR）。
法律保留：禁止重新錄制檔案作為保留的一部分。

10）可觀察性，SLI/SLO和Alerta

• Freshness p95（Silver）：≤ 15分鐘。
• Completeness (critical types): ≥ 99.5%.
• Validity (schema): ≥ 99.9%.
• Duplicate rate: ≤ 0.1%.
• DQ incident MTTR: ≤ 24–48 ч.

Alerta：嚴重性路由（pager for critical）、平滑化（alerta）、「維護視窗」。

11） Dashbords（最低設置）

按領域和市場劃分的Freshness/Completeness熱卡。
按事件數量和修復費用排在前N位。
漏鬥DQ： ingest → silver → gold（損失/修復）。
用於關鍵報告（調節/GGR/RG/AML）的線卡。
「舊式」電路和客戶端映射（SDK/電路版本）。

12）流程和RACI

R（響應）：數據工程（每個表的規則），域所有者（語義）。

A (Accountable): Head of Data/CDO.

C（咨詢）：合規/法律/DPO，體系結構，SRE。
I （Informed）： BI/產品/營銷/財務/運營。

規則生命周期：咆哮→句子→「黑暗啟動」→包含→監控→回顧。

13）核對和精度（Accuracy）

校驗金額/交易：與OLTP/提供商（PSP/KYC）合並。
兩環比較：用於選擇性驗證的獨立管道。

公差： 按度量劃分的百分比閾值（例如GGR ≤ 0的差異。2%).

日常行為： 備審報告.

14）成本和優先級

更頻繁地運行關鍵規則（流/小時），次要規則是每日規則。
對重型表使用樣本和材料化檢查。
跟蹤成本/查詢和成本/GB,應用聚類/索引。
在命令切口（chargeback）中分配DQ預算。

15）金色店面模板（例如GGR Daily）

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）質量事件： 管理和溝通

Ticketing：用附加的樣本和指標自動創建任務。
通用模板：在受到影響時通知產品所有者/監管者。
Mortem後：根原因（schema drift, upstream bug,負載）,CAPA操作,「回歸返回」控制。

17）實施路線圖

1.關鍵表目錄（Payments，Gameplay，GGR，Compliance）。

2.YAML規則，用於10-15個關鍵檢查+CI驗證。

3.Dashboard Freshness/Completeness和Alerta用於批判。

4.DLQ/Quarantine+修補程序運行手冊。

• 規則擴展（FK/accuracy），「dry-run」模擬器，A/B包含。
• 與lineage，例外安排和SLA集成。
• 在ingest上流式傳輸DQ，用於「嘈雜」源。

• 自動生成規則文檔，成本度量。
• 「控制輪廓」（獨立重構），每周回顧展。
• Rule-as-Code平臺SDK，標準域檢查註冊表。

18）售前支票清單

• Registry的合同和計劃，兼容性測試正在進行中。
• YAML規則被清除，severity/上報被分配。
• Dashbords和Alertes是活躍的；確定並商定了SLO。
• DLQ/Quarantine可用，runbooks已記錄。
• 相互抵觸的例外/行為程序已與Legal/Compliance協調。
• 檢查費用測量和嚴重查詢限額。

19）頻繁的錯誤以及如何避免錯誤

原始數據沒有合同：輸入計劃第一和消費者測試。
手動檢查：翻譯成DQ代碼和CI。
沒有優先級：共享臨界/大調/小調和差速器通道。
缺少DLQ：沒有什麼可以處理錯誤-添加隔離。
忽略成本：分析查詢,使用實例化。
沒有後驗屍：錯誤重復-引入CAPA和回歸控制。

20）結果

數據質量控制系統不是一組不同的檢查，而是托管程序：合同和計劃，DQ編碼，可觀察性和SLO，事件紀律和交換。根據這篇文章，您將獲得可復制，可驗證且經濟高效的數據，足以用於監管報告，產品解決方案和實時風險檢測器。