以下是我按照业务域 → 核心实体 → 具体规则的层次，梳理电商各业务域必须监控的质量规则，每项规则包含检查逻辑、阈值建议、优先级、监控频率，供大家实践参考。
一、交易域（核心营收域）
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 阈值设置原则
统计基线法：基于历史数据的3σ原则设置阈值
-- 示例：订单金额波动阈值 阈值上限 = 历史平均金额 + 3 * 历史标准差 阈值下限 = 历史平均金额 - 3 * 历史标准差
业务规则法：根据业务逻辑设置硬性规则
sql
-- 示例：库存不能为负 WHERE stock_quantity < 0 -- 直接报错
同比环比法：监控指标的同比环比变化
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 当发现数据质量问题时
立即响应：
确认问题影响范围（哪些报表、哪些业务方）
设置临时解决方案（如：使用昨日数据）
根因分析（5个排查方向）：
源头系统 → 数据同步 → 数仓加工 → 数据服务 → 业务使用
沟通协调：
业务方：告知影响范围和预计恢复时间
技术团队：协调资源优先修复
管理层：汇报进展和风险
10.2 质量规则维护机制
定期评审：每季度评审规则有效性和阈值合理性
版本管理：规则变更记录、影响评估、回滚方案
知识沉淀：问题案例库、最佳实践文档、培训材料
这个清单覆盖了电商核心业务域的关键质量检查点。在实际应用中，大家可以根据自己企业具体情况调整阈值、优先级和监控频率。
