数据质量规则草拟

以下为客户邮箱的5条数据质量规则。每条规则包含适用范围、验证要点与处置原则，用于在采集、清洗、存储与使用环节保障邮箱数据的准确性、完整性与可递送性。

1. 语法与字符集合规
- 适用范围：所有客户邮箱输入与批量导入。
- 验证要点：
  - 必须符合 local-part@domain 基本结构；不允许空格、控制字符或不可见字符（如零宽空格）。
  - 不允许本地部分以点开头/结尾或出现连续点。
  - 长度限制：本地部分≤64，域名各标签≤63；为保证兼容性，邮箱总长度≤254。
  - 国际化策略：
    - 域名可为IDN，入库统一转换为Punycode；显示层可保留原始Unicode。
    - 若系统未启用EAI（RFC 6531），本地部分仅允许ASCII；如启用EAI，存储与传输使用UTF-8，并进行Unicode规范化（NFC）。
- 处置原则：不合规直接拒收并返回明确错误码与示例说明；对IDN进行Punycode转换后再入库。

2. 规范化与存储一致性
- 适用范围：入库前的清洗与存储。
- 验证要点：
  - 去除首尾空白；域名统一小写；本地部分保留原样（避免破坏大小写语义）。
  - 统一进行Unicode规范化（NFC），并移除不可见字符。
  - 同时保存原始值与规范化值：用于风险审计与复现。
- 处置原则：规范化后写入标准字段（normalized_email），原始值写入原始字段（raw_email）；若规范化导致值变化，记录清洗日志与变更原因。

3. 可递送性验证（DNS/SMTP）
- 适用范围：注册、更新与周期性健康检查。
- 验证要点：
  - DNS层：域名必须可解析；优先存在MX记录；如无MX但存在A/AAAA记录，视为可尝试投递。
  - SMTP层（可选增强）：通过安全的RCPT TO探测（不发送邮件）验证收件人是否存在；控制重试策略与超时，避免被目标服务器拒绝或列入黑名单。
  - 记录验证状态：pending/verified/invalid，并打上时间戳与来源（DNS/SMTP）。
- 处置原则：无解析或明确不存在的地址标记为invalid并禁止作为主通信渠道；定期重验证，遇到临时性DNS失败设置为soft-invalid并进入重试队列。

4. 唯一性与生命周期管理
- 适用范围：客户主邮箱字段及其变更。
- 验证要点：
  - 在客户维度，主邮箱唯一；跨客户维度，不允许同一规范化邮箱绑定多个活跃客户账户（防止账户挪用）。
  - 去重以规范化邮箱为准；域名大小写不区分，本地部分按字面匹配（避免误合并）。
  - 邮箱状态必须在通过可递送性验证后方可标记为active；变更需审计（旧值、新值、操作人、时间、原因）。
- 处置原则：发现重复时触发合并/冲突流程；未验证邮箱限制用于高风险动作（密码重置、合同发送等）。

5. 风险控制与质量分级
- 适用范围：注册、导入与营销发送名单。
- 验证要点：
  - 禁止一次性/临时邮箱域名（基于维护的域名黑名单）；对高风险域名（新注册、低信誉）降级评分与限流。
  - 限制角色型地址（如 admin@、support@、info@、sales@、contact@、help@、no-reply@）作为客户主邮箱，除非业务场景明确需要。
  - 对历史退信、投诉、取消订阅等行为进行质量打分，低分地址须人工复核或剔除。
- 处置原则：命中黑名单直接拒收；命中角色型地址转人工或提示更换为个人邮箱；质量分低于阈值的地址从发送名单中移除或进入再验证流程。

以上规则应以可配置策略实现（例如是否支持EAI、角色地址名单、黑名单源、验证频率），并配套错误码、审计日志与监控指标（通过率、退信率、验证成功率）以持续优化数据质量。

以下为用户手机号的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与回填流程（含时区归一与重算策略）。