2. 数据质量基础：六大维度在坏账场景中的映射

数据质量不是抽象概念，而是由六个可度量、可验证的维度构成的工程框架。在坏账率哨兵场景中，每个维度都对应着具体的业务风险与SQL检查点。本节将逐一拆解六大维度，并给出其在坏账数据流中的映射关系。

2.1 六大维度总览

维度	核心定义	坏账场景映射	典型SQL检查
准确性	数据反映真实业务的程度	逾期金额、罚息计算是否正确	SUM(overdue_principal) vs 台账
完整性	必要字段无缺失	合同号、逾期天数、客户ID不可为空	IS NULL / COUNT(*) 对比
一致性	跨系统、跨表数据逻辑统一	核心系统与数仓的坏账口径一致	JOIN 比对关键字段
及时性	数据在有效时间内可用	T+1 坏账报表是否按时产出	MAX(etl_time) vs 业务截止时间
唯一性	实体记录不重复	同一笔贷款不应出现两条坏账记录	ROW_NUMBER() 去重检测
有效性	数据符合业务规则与格式	逾期天数在0~180天范围内	CASE WHEN 边界值校验

2.2 维度映射详解

2.2.1 准确性（Accuracy）

准确性是坏账数据的生命线。一笔逾期本金被多算1元，坏账率就可能偏离真实值。在哨兵场景中，准确性检查聚焦于：

• 金额计算校验： 逾期本金 = 应还本金 - 已还本金，需与核心系统逐笔对账。
• 利息与罚息： 复利计算是否按合同约定执行，SQL需验证公式逻辑。
• 分类标签： 五级分类（正常/关注/次级/可疑/损失）是否与逾期天数匹配。

-- 准确性检查示例：逾期本金与核心系统对账
SELECT
    a.loan_id,
    a.overdue_principal AS dw_amount,
    b.overdue_principal AS core_amount,
    ABS(a.overdue_principal - b.overdue_principal) AS diff
FROM dw_bad_loan a
JOIN core_loan_snapshot b ON a.loan_id = b.loan_id
WHERE ABS(a.overdue_principal - b.overdue_principal) > 0.01;

2.2.2 完整性（Completeness）

缺失字段在坏账场景中会直接导致哨兵无法计算关键指标。完整性检查必须覆盖所有下游依赖字段：

• 强制非空字段： loan_id, customer_id, overdue_days, overdue_principal, etl_time。
• 业务关键字段： contract_no, product_type, branch_code 缺失会影响维度分析。
• 时间戳字段： 缺失 etl_time 会导致无法判断数据新鲜度。

-- 完整性检查：统计各字段缺失率
SELECT
    COUNT(*) AS total_records,
    SUM(CASE WHEN loan_id IS NULL THEN 1 ELSE 0 END) AS missing_loan_id,
    SUM(CASE WHEN overdue_days IS NULL THEN 1 ELSE 0 END) AS missing_overdue_days,
    SUM(CASE WHEN overdue_principal IS NULL THEN 1 ELSE 0 END) AS missing_principal
FROM dw_bad_loan
WHERE dt = '2025-03-01';

2.2.3 一致性（Consistency）

坏账数据通常来自多个上游系统（核心银行、信贷审批、催收系统），口径不一致是哨兵误报的头号原因。一致性检查包括：

• 口径对齐： 各系统对“逾期”的定义是否一致（M1/M2/M3 的起算规则）。
• 编码统一： 客户ID、产品编码、机构编码在不同系统中是否映射正确。
• 汇总校验： 数仓层坏账总额与各源系统汇总值是否一致。

2.2.4 及时性（Timeliness）

坏账率哨兵是时效敏感型应用。如果T+1报表在上午10点仍未产出，当日的风险监控窗口就已关闭。及时性检查点：

• ETL完成时间： 检查 dw_bad_loan 表最新分区的时间戳。
• 批处理延迟： 对比调度系统日志与数据实际落地时间。
• 数据新鲜度： 业务日期与系统时间的差值是否在SLA范围内。

-- 及时性检查：获取最新分区的时间戳
SELECT
    MAX(dt) AS latest_partition,
    MAX(etl_time) AS latest_etl_time,
    DATEDIFF(hour, MAX(etl_time), GETDATE()) AS delay_hours
FROM dw_bad_loan;

2.2.5 唯一性（Uniqueness）

重复记录是坏账率计算的隐形杀手。一笔坏账被重复统计，会导致坏账率虚高。唯一性检查必须基于业务主键：

• 业务主键： loan_id + dt 或 loan_id + 逾期期次。
• 重复检测： 使用 ROW_NUMBER() 或 COUNT(*) 分组检测。
• 去重策略： 保留最新 etl_time 的记录，或标记重复由业务确认。

-- 唯一性检查：检测重复的贷款记录
SELECT
    loan_id,
    dt,
    COUNT(*) AS dup_count
FROM dw_bad_loan
GROUP BY loan_id, dt
HAVING COUNT(*) > 1;

2.2.6 有效性（Validity）

有效性确保数据符合业务定义的合法范围。坏账场景中常见的有效性规则：

• 值域约束： overdue_days BETWEEN 0 AND 180，overdue_principal >= 0。
• 格式约束： contract_no 符合特定正则模式，customer_id 为纯数字。
• 枚举约束： loan_status 必须在（'正常','关注','次级','可疑','损失'）中。

-- 有效性检查：检测逾期天数超出业务范围
SELECT
    loan_id,
    overdue_days,
    CASE
        WHEN overdue_days < 0 THEN '负值异常'
        WHEN overdue_days > 180 THEN '超长逾期'
        ELSE '正常范围'
    END AS validity_flag
FROM dw_bad_loan
WHERE overdue_days < 0 OR overdue_days > 180;

2.3 六大维度协同架构

下图展示了六大维度在坏账率哨兵数据管道中的协同位置。每个维度对应一个质量检查节点，形成从数据采集到指标输出的完整防线。

2.4 维度优先级矩阵

在实际工程中，六大维度并非同等重要。根据坏账率哨兵的业务影响，我们定义以下优先级：

优先级	维度	业务影响	检查频率
P0	准确性、完整性	直接导致坏账率计算错误	每次ETL后立即执行
P1	一致性、及时性	影响跨系统对账与监控时效	每日定时检查
P2	唯一性、有效性	影响明细分析与报表准确性	每日批量检查

2.5 本章小结

六大维度在坏账率哨兵场景中形成了完整的质量检查体系：

• 准确性 确保坏账金额计算无误
• 完整性 保证关键字段无缺失
• 一致性 统一跨系统口径
• 及时性 保障数据在有效窗口内可用
• 唯一性 防止重复记录污染指标
• 有效性 约束数据在合法范围内