数据质量规则草拟

以下为用户手机号的5条数据质量规则，聚焦格式、有效性、唯一性、验证和异常控制，确保数据的准确性、完整性与可用性。

1. 格式标准化（E.164）

• 目的：统一存储格式，避免歧义与重复。
• 规则定义：手机号必须存储为 E.164 标准格式，匹配正则 ^+[1-9]\d{1,14}$（以“+”开头，后接1–15位数字，首位不得为0）。
• 校验要点：
  • 输入时可接受本地格式（含空格、破折号等），入库前必须规范化为 E.164。
  • 移除所有非数字字符（“+”除外），禁止扩展字符或前导0（国家码后）。
• 处置策略：不符合格式的记录拒绝写入或进入修复队列；统一在写入层或ETL中进行规范化。

2. 国家码与号码计划有效性

• 目的：确保号码属于已分配的国家/地区并符合本地号码规则。
• 规则定义：
  • 国家码必须属于有效的 E.164 国家/地区代码列表（如 +1、+44、+86 等）。
  • 若系统已知用户的国家/地区（或通过号码解析得到），则按该国号码计划校验本地长度与号段合法性（例如在已配置的规则中验证长度范围、前缀可用性）。
• 校验要点：拒绝未分配或保留的国家码；对不匹配本地计划的号码标记为无效。
• 处置策略：标记无效并进入人工复核或提示用户更正；定期更新国家码与号段元数据。

3. 唯一性与归一化去重

• 目的：避免一个号码对应多个用户，确保关联关系清晰。
• 规则定义：
  • 在同一租户/业务域内，规范化后的手机号必须唯一（对活动用户）。
  • 去重基于 E.164 规范化结果，而非原始输入文本。
• 校验要点：新增/更新时进行唯一性检查；对重复号码触发冲突处理。
• 处置策略：阻止写入或转入合并流程；保留冲突审计记录并通知数据运营。

4. 验证与可达性（Deliverability）

• 目的：提升联系方式的可靠性与通信成功率。
• 规则定义：
  • 号码必须拥有验证状态字段（如 is_verified、verified_at、verification_method），通过短信或语音OTP完成验证。
  • 若发生不可达（如持续发送失败、运营商返回无效），更新可达性状态（如 is_deliverable=false）。
• 校验要点：新增或变更手机号需在规定时间内完成验证；对持续不可达的号码降低可信度或限制使用。
• 处置策略：未验证号码仅限低风险用途（如资料展示），禁止用于强依赖通信的流程；对不可达号码触发清洗/更新流程。

5. 异常与黑名单控制

• 目的：剔除不合规、测试或受限制的号码，降低数据污染。
• 规则定义：
  • 拒绝内部测试号码、已知垃圾/欺诈号码、用户退订（opt-out）名单中的号码。
  • 若配置了本地号码计划的保留/未分配号段，入库时应拦截。
• 校验要点：在写入与发送前均进行黑名单与保留段校验；对疑似异常（高风险模式、频繁更换）的号码进行额外审查。
• 处置策略：标记并隔离；禁止用于发送；保留审计轨迹与触发告警。

补充建议（实施层面简述）：

• 建立数据字典：明确手机号字段的数据类型、约束、验证流程与状态字段定义。
• 引入号码解析组件：在规范化时解析国家码与本地规则，定期同步元数据。
• 审计与监控：记录新增/变更的时间戳、来源、操作者；设监控指标（验证率、不可达率、重复率）并设阈值告警。

以下为“订单创建时间”（字段示例：order_create_time，类型建议：TIMESTAMP，UTC）5条数据质量规则。每条规则包含目的、校验逻辑与示例校验查询（伪SQL），并以参数化形式提供可调阈值，便于在不同系统中复用。

1. 完整性与唯一性（每单仅一个创建时间）

• 目的：确保每个订单存在且仅存在一个有效的创建时间，避免同一订单多值或缺失。
• 校验逻辑：
  • 非空：order_create_time IS NOT NULL。
  • 同一订单唯一：对同一 order_id，创建时间取值必须唯一。
• 示例校验（伪SQL）：
  • 缺失检测： SELECT order_id FROM orders WHERE order_create_time IS NULL;
  • 同单多值检测： SELECT order_id FROM orders GROUP BY order_id HAVING COUNT(DISTINCT order_create_time) > 1;

2. 类型、格式与时区标准化

• 目的：确保字段可解析为时间戳，统一至 UTC，精度一致，消除因字符串存储或时区混用导致的错误。
• 校验逻辑：
  • 可解析：SAFE_CAST(order_create_time AS TIMESTAMP) 不为 NULL（若存为字符串）。
  • 时区统一：存储为 UTC（无本地时区偏移）；若来源含时区偏移，需归一至 UTC 后再入库。
  • 精度一致：统一到秒或毫秒（例如 TIMESTAMP(3)）；禁止混用不同精度。
• 示例校验（伪SQL）：
  • 可解析性： SELECT order_id, order_create_time FROM orders WHERE SAFE_CAST(order_create_time AS TIMESTAMP) IS NULL;
  • 精度（毫秒）一致性（示意）： SELECT order_id, order_create_time FROM orders WHERE EXTRACT(MICROSECOND FROM order_create_time) % 1000 <> 0;

3. 合理取值范围与未来时间限制

• 目的：剔除异常早/晚的时间，控制与当前时间的偏离，抵御时钟漂移或系统回填错误。
• 校验逻辑（参数化）：
  • 下界：order_create_time >= ${data_start_date}（如系统上线日或可用数据起始日）。
  • 上界：order_create_time <= CURRENT_TIMESTAMP() + INTERVAL ${clock_skew_minutes} MINUTE（允许少量时钟漂移，如5分钟）。
• 示例校验（伪SQL）： SELECT order_id, order_create_time FROM orders WHERE order_create_time < TIMESTAMP '${data_start_date}' OR order_create_time > CURRENT_TIMESTAMP() + INTERVAL ${clock_skew_minutes} MINUTE;

4. 业务时序一致性（与其他关键节点的相对顺序）

• 目的：保证创建时间在业务流程中居于起点，不晚于支付、审核、发货、取消等后续节点。
• 校验逻辑（存在即校验，空值不判错）：
  • 若 pay_time 不为 NULL，则 order_create_time <= pay_time；
  • 若 approve_time 不为 NULL，则 order_create_time <= approve_time；
  • 若 ship_time 不为 NULL，则 order_create_time <= ship_time；
  • 若 cancel_time 不为 NULL，则 order_create_time <= cancel_time。
• 示例校验（伪SQL）： SELECT order_id FROM orders WHERE (pay_time IS NOT NULL AND order_create_time > pay_time) OR (approve_time IS NOT NULL AND order_create_time > approve_time) OR (ship_time IS NOT NULL AND order_create_time > ship_time) OR (cancel_time IS NOT NULL AND order_create_time > cancel_time);

5. 不可变性与历史快照一致性

• 目的：创建时间一经写入即不可变，避免回填或重复抽取导致的“时间漂移”。
• 校验逻辑：
  • 在增量/日终对比中，同一 order_id 的 order_create_time 不应变化。
  • 允许的例外须带有审计标记（如修复批次号 fix_batch_id）并纳入变更白名单。
• 示例校验（伪SQL，基于昨日快照 orders_d_1 与今日快照 orders_d）： SELECT cur.order_id, prev.order_create_time AS old_ct, cur.order_create_time AS new_ct FROM orders_d cur JOIN orders_d_1 prev USING (order_id) WHERE cur.order_create_time <> prev.order_create_time AND COALESCE(cur.fix_batch_id, '') = '';

实施与监控建议

• 指标与阈值：为每条规则定义异常率阈值（如 error_rate <= 0.1%），超过即告警。
• 失败样本存储：将违规样本写入隔离表（含规则ID、检测时间、样本行键、原因）。
• 自动化调度：在数据入湖/入仓链路上游执行校验，失败时阻断或降级下游任务。
• 溯源与修复：记录违规分布与来源系统，制定修复SLA与回填流程（含时区归一与重算策略）。