数据质量控制

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，事件纪律和交换。根据这篇文章，您将获得可复制，可验证且经济高效的数据，足以用于监管报告，产品解决方案和实时风险检测器。