以下是我按照业务域 → 核心实体 → 具体规则的层次，梳理电商各业务域必须监控的质量规则，每项规则包含检查逻辑、阈值建议、优先级、监控频率，供大家实践参考。

---

一、交易域（核心营收域）

1.1 订单事实表（dwd_order_fact）

规则类别	规则名称	检查逻辑	阈值/标准	优先级	监控频率
完整性	订单必填字段缺失	order_id, user_id, order_time, total_amount 不能为空	缺失率 < 0.1%	P0	实时
准确性	订单金额合理性	total_amount = product_amount + shipping_fee - discount_amount	金额误差 < 0.01元	P0	批次(T+1)
一致性	订单状态流转逻辑	状态变更符合预设流程：创建 → 支付 → 发货 → 完成	100%符合	P1	批次
及时性	订单数据同步延迟	订单创建时间到数仓入库时间差	< 5分钟(实时) / < 30分钟(批次)	P0	实时
唯一性	订单ID重复	COUNT(DISTINCT order_id) = COUNT(*)	重复数 = 0	P0	批次
业务规则	异常订单检测	total_amount < 0 或 > 1000000（需结合业务）	异常订单占比 < 0.01%	P1	批次
关联性	订单-商品关联完整性	订单在dwd_order_item中有对应商品记录	缺失关联率 < 0.1%	P1	批次

1.2 支付事实表（dwd_payment_fact）

规则类别	规则名称	检查逻辑	阈值/标准	优先级	监控频率
准确性	支付金额与订单匹配	payment_amount = 对应订单的pay_amount	匹配率 > 99.9%	P0	实时
一致性	支付状态一致性	支付成功订单在订单表中状态必须为"已支付"	100%一致	P0	实时
完整性	三方支付流水号	third_payment_id 不为空（支付成功时）	缺失率 < 0.1%	P1	批次
及时性	支付回调延迟	支付成功时间到回调入库时间差	< 3分钟	P0	实时

1.3 退款事实表（dwd_refund_fact）

规则类别	规则名称	检查逻辑	阈值/标准	监控频率
业务规则	退款金额≤订单金额	refund_amount ≤ 原订单pay_amount	100%符合	P0/批次
时效性	退款审批时效	退款申请到审批完成时间	< 48小时（根据SLA）	P1/批次
一致性	退款状态同步	退款成功需同步更新订单状态	同步率 > 99.5%	P1/实时

---

二、商品域

2.1 商品维度表（dim_product）

规则类别	规则名称	检查逻辑	阈值/标准	优先级	监控频率
完整性	核心商品信息	product_id, product_name, category_id, price 不为空	缺失率 < 0.5%	P1	批次
准确性	价格合理性	price > 0 且 < 上限值（如100000）	异常率 < 0.1%	P1	批次
一致性	上下架状态一致性	商品在商品中心与数仓状态一致	不一致率 < 0.5%	P2	批次
及时性	商品信息更新延迟	商品信息变更到数仓同步时间	< 1小时	P2	批次

2.2 库存事实表（dwd_stock_fact）

规则类别	规则名称	检查逻辑	阈值/标准	监控频率
准确性	库存数量非负	stock_quantity ≥ 0	100%符合	P0/实时
业务规则	超卖检测	实际销售数量 ≤ 可用库存	超卖订单数 = 0	P0/实时
一致性	库存一致性对账	数仓库存 = 业务系统库存 - 锁定库存	差异率 < 1%	P1/批次

---

三、用户域

3.1 用户维度表（dim_user）

规则类别	规则名称	检查逻辑	阈值/标准	优先级	监控频率
完整性	用户注册信息	user_id, register_time, register_channel 不为空	缺失率 < 1%	P1	批次
唯一性	用户ID唯一	user_id 不重复，手机号/邮箱唯一性	重复率 < 0.01%	P0	批次
准确性	用户属性合理性	age在[1,120]，gender∈['M','F','U']	异常率 < 0.5%	P2	批次
及时性	用户标签更新	VIP等级、用户分层标签更新延迟	< 4小时	P2	批次

3.2 用户行为事实表（dwd_user_behavior）

规则类别	规则名称	检查逻辑	阈值/标准	监控频率
完整性	行为日志必填字段	user_id, event_time, event_type, page_id 不为空	缺失率 < 0.5%	P1/实时
准确性	时间序列合理性	event_time 在合理范围内（不超前不穿越）	异常率 < 0.1%	P1/批次
一致性	事件完整性	关键路径事件不丢失：首页→列表页→详情页	关键路径完整率 > 95%	P2/批次

---

四、流量域

4.1 页面访问事实表（dwd_page_view）

规则类别	规则名称	检查逻辑	阈值/标准	优先级	监控频率
完整性	埋点字段填充	page_url, referrer, device_id 不为空	缺失率 < 5%	P2	批次
准确性	UV统计准确性	同一device_id在同一天不重复计数	UV重复率 < 0.1%	P1	批次
一致性	页面URL规范化	URL参数标准化，去除UTM冗余参数	标准化率 > 90%	P2	批次
及时性	流量数据延迟	访问时间到数仓入库时间差	< 10分钟（实时）	P1	实时

4.2 搜索事实表（dwd_search_fact）

规则类别	规则名称	检查逻辑	阈值/标准	监控频率
完整性	搜索关键词	search_keyword 不为空	缺失率 < 1%	P2/批次
业务规则	搜索无结果率	search_results_count = 0 的比例	< 20%（行业标准）	P1/批次

---

五、营销域

5.1 优惠券事实表（dwd_coupon_fact）

规则类别	规则名称	检查逻辑	阈值/标准	优先级	监控频率
业务规则	优惠券使用规则	使用时间在有效期内，满足最低消费	违规使用率 < 0.1%	P0	批次
一致性	优惠券状态同步	券状态在发放、使用、核销环节一致	不一致率 < 0.5%	P1	实时
完整性	优惠券核销记录	已使用优惠券必须有核销记录	缺失率 = 0	P1	批次

5.2 活动维度表（dim_activity）

规则类别	规则名称	检查逻辑	阈值/标准	监控频率
准确性	活动时间逻辑	start_time < end_time	100%符合	P1/批次
业务规则	活动预算控制	活动实际消耗 ≤ 预算金额	超预算率 = 0	P0/实时

---

六、财务域（对账核心）

6.1 财务对账规则（跨系统）

规则类别	规则名称	检查逻辑	阈值/标准	优先级	监控频率
一致性	GMV三方对账	数仓GMV vs 支付系统GMV vs 财务系统GMV	差异率 < 0.1%	P0	日终批次
一致性	订单收入对账	数仓订单金额 vs ERP系统销售金额	差异率 < 0.5%	P0	日终批次
准确性	退款金额对账	数仓退款总额 = 支付系统退款总额	差异金额 = 0	P0	日终批次
完整性	佣金计算完整性	所有应结算订单均计算佣金	缺失率 = 0	P1	批次

---

七、数据服务层（API/报表）

7.1 核心报表数据质量

规则类别	规则名称	检查逻辑	阈值/标准	监控频率
及时性	日报产出时间	核心经营日报在每天9:00前产出	准时率 > 98%	P0/实时监控
稳定性	报表数据波动	核心指标日环比波动超过阈值	波动 > ±30%时告警	P1/批次
一致性	报表间一致性	同一指标在不同报表中数值一致	差异率 = 0	P0/批次

7.2 数据API服务监控

规则类别	规则名称	检查逻辑	阈值/标准	监控频率
可用性	API响应可用性	HTTP状态码200比例	> 99.5%	P0/实时
性能	API响应时间	P95响应时间	< 500ms	P1/实时
准确性	API返回数据准确性	抽样验证返回数据与源数据一致	准确率 > 99.9%	P2/批次

---

八、规则优先级与响应机制

8.1 优先级定义

优先级	定义	响应时间	影响范围	示例
P0（致命）	影响核心营收或决策	< 30分钟	公司级	GMV数据错误、支付对账不平
P1（严重）	影响业务运营效率	< 2小时	部门级	订单数据延迟、库存不一致
P2（一般）	影响数据使用体验	< 24小时	团队级	用户标签缺失、报表字段空值
P3（提示）	数据规范性提醒	定期处理	个人级	命名不规范、注释缺失

8.2 监控策略矩阵

高业务价值 + 高发生概率 → 实时监控 + 自动阻断（如：支付金额异常）
高业务价值 + 低发生概率 → 批次监控 + 即时告警（如：GMV对账差异）
低业务价值 + 高发生概率 → 批次监控 + 定期报告（如：埋点字段缺失）
低业务价值 + 低发生概率 → 抽样检查 + 知识沉淀（如：商品描述规范性）

---

九、实施建议与最佳实践

9.1 分阶段实施路线

-- 第一阶段（1-3个月）：核心营收保障
重点监控：订单、支付、退款、GMV对账
目标：P0问题发现率100%，解决时间<1小时

-- 第二阶段（3-6个月）：业务运营保障
扩展监控：库存、用户、商品、营销活动
目标：数据质量问题减少50%

-- 第三阶段（6-12个月）：全面数据治理
覆盖：流量、搜索、推荐、财务、API服务
目标：建立数据质量文化，业务方自助监控

9.2 阈值设置原则

1. 统计基线法：基于历史数据的3σ原则设置阈值

   -- 示例：订单金额波动阈值
   阈值上限 = 历史平均金额 + 3 * 历史标准差
   阈值下限 = 历史平均金额 - 3 * 历史标准差

2. 业务规则法：根据业务逻辑设置硬性规则

   sql

   -- 示例：库存不能为负
   WHERE stock_quantity < 0  -- 直接报错

3. 同比环比法：监控指标的同比环比变化

   sql

   -- 示例：DAU波动监控
   今日DAU / 昨日DAU < 0.7 OR > 1.3  -- 波动超过30%告警

9.3 规则模板示例

# 数据质量规则配置模板（YAML格式）
rule:
  name: "订单金额准确性检查"
  domain: "交易域"
  entity: "dwd_order_fact"
  type: "准确性"
  priority: "P0"
  
  # 检查逻辑
  logic:
    sql: |
      SELECT 
        order_id,
        total_amount,
        product_amount + shipping_fee - discount_amount as calculated_amount,
        ABS(total_amount - (product_amount + shipping_fee - discount_amount)) as diff
      FROM dwd_order_fact
      WHERE dt = '${bizdate}'
      HAVING diff > 0.01
    
    # 替代方案：使用存储过程或UDF
    # function: "check_order_amount_consistency"
  
  # 阈值配置
  threshold:
    warning: 0.01    # 警告阈值：差异>0.01元
    error: 0.10      # 错误阈值：差异>0.10元
    max_records: 100 # 最大检查记录数（抽样）
  
  # 调度配置
  schedule:
    type: "cron"
    expression: "0 2 * * *"  # 每天凌晨2点执行
    timeout: 1800            # 超时时间(秒)
  
  # 告警配置
  alert:
    enabled: true
    channels: ["dingtalk", "email"]
    receivers: ["data-team", "business-owner"]
    template: |
      主题：订单金额数据异常告警
      内容：发现${count}笔订单金额计算不一致，最大差异${max_diff}元
      
  # 修复建议
  remediation:
    auto_fix: false  # 是否支持自动修复
    manual_steps:
      - "检查discount_amount计算逻辑"
      - "验证product_amount来源"
      - "核对shipping_fee配置"
    
  # 血缘关联
  lineage:
    upstream_tables: ["ods_order", "ods_order_item"]
    downstream_tables: ["dws_order_daily", "ads_gmv_report"]

---

十、常见问题排查清单

10.1 当发现数据质量问题时

1. 立即响应：

   • 确认问题影响范围（哪些报表、哪些业务方）

   • 设置临时解决方案（如：使用昨日数据）

2. 根因分析（5个排查方向）：

   源头系统 → 数据同步 → 数仓加工 → 数据服务 → 业务使用

3. 沟通协调：

   • 业务方：告知影响范围和预计恢复时间

   • 技术团队：协调资源优先修复

   • 管理层：汇报进展和风险

10.2 质量规则维护机制

1. 定期评审：每季度评审规则有效性和阈值合理性

2. 版本管理：规则变更记录、影响评估、回滚方案

3. 知识沉淀：问题案例库、最佳实践文档、培训材料

---

这个清单覆盖了电商核心业务域的关键质量检查点。在实际应用中，大家可以根据自己企业具体情况调整阈值、优先级和监控频率。