3. 准确性校验：定义与标准、字段级校验规则、跨字段逻辑校验、基于参考数据的校验

准确性校验，说白了就是检查数据是不是「对的」。

完整性保证数据不缺，唯一性保证数据不重，但数据本身可能是错的——比如用户年龄填了 200 岁，订单金额多了一个零。我见过太多系统，数据不缺也不重，但一跑报表全是笑话。所以，准确性校验才是数据质量里最见真功夫的一环。

3.1 准确性的定义与标准

准确性，指的是数据记录的值与真实世界中的实际值一致的程度。听起来简单，但落地时你会发现，什么叫「真实值」有时候都说不清楚。

我个人习惯把准确性拆成三层来看：

• 语法准确性：数据格式、类型、长度是否符合规范。比如手机号必须是 11 位数字。
• 语义准确性：数据值在业务语境下是否合理。比如订单金额不能为负数。
• 事实准确性：数据是否真实反映了客观事实。比如用户填的出生日期是否与身份证一致。

你想想看，很多团队只做了语法准确性，就觉得万事大吉了。其实真正的坑在后面两层。

3.2 字段级校验规则

字段级校验是最基础也是最容易出效果的。我一般把它分成四类规则，直接上表：

规则类型	说明	示例
值域校验	检查字段值是否在允许范围内	年龄 0-150，折扣率 0-1
格式校验	检查字段格式是否符合规范	邮箱含 @，日期格式 yyyy-MM-dd
枚举校验	检查字段值是否在枚举列表中	性别只能是 M/F/U
精度校验	检查数值精度是否达标	金额保留两位小数

举个例子，我在项目中遇到过这样一个场景：用户上传的 CSV 里，日期字段有的写「2024-01-01」，有的写「2024/1/1」，还有写「2024年1月1日」的。嗯，这种格式不统一的问题，靠字段级校验就能拦住大部分。

-- 字段级校验 SQL 示例：值域 + 格式 + 枚举
SELECT
  order_id,
  CASE
    WHEN amount <= 0 THEN '金额必须大于0'
    WHEN amount > 1000000 THEN '金额超出合理范围'
    ELSE NULL
  END AS amount_error,
  CASE
    WHEN order_date NOT REGEXP '^[0-9]{4}-[0-9]{2}-[0-9]{2}$' THEN '日期格式错误'
    ELSE NULL
  END AS date_error,
  CASE
    WHEN status NOT IN ('PENDING', 'PAID', 'SHIPPED', 'CANCELLED') THEN '状态值非法'
    ELSE NULL
  END AS status_error
FROM orders
WHERE
  amount <= 0
  OR amount > 1000000
  OR order_date NOT REGEXP '^[0-9]{4}-[0-9]{2}-[0-9]{2}$'
  OR status NOT IN ('PENDING', 'PAID', 'SHIPPED', 'CANCELLED');

3.3 跨字段逻辑校验

字段级校验只能管单个字段，但很多业务错误是字段之间打架造成的。跨字段逻辑校验，就是检查多个字段之间的逻辑关系是否一致。

我曾经接手过一个电商数据仓库，发现大量订单的「下单时间」晚于「发货时间」。你想想看，货都发了才下单？这明显是数据采集时的时间戳搞混了。这种问题，字段级校验根本发现不了。

常见的跨字段逻辑校验场景：

• 时间顺序校验：下单时间 < 支付时间 < 发货时间 < 签收时间
• 金额一致性校验：商品单价 × 数量 = 订单金额（考虑折扣和税费）
• 状态流转校验：订单状态不能从「已支付」跳回「待支付」
• 父子数据校验：子订单的金额之和应等于父订单总金额

-- 跨字段逻辑校验示例：时间顺序 + 金额一致性
SELECT
  order_id,
  CASE
    WHEN pay_time < order_time THEN '支付时间早于下单时间'
    WHEN ship_time < pay_time THEN '发货时间早于支付时间'
    ELSE NULL
  END AS time_logic_error,
  CASE
    WHEN ABS((unit_price * quantity) - total_amount) > 0.01 THEN '金额计算不一致'
    ELSE NULL
  END AS amount_logic_error
FROM orders
WHERE
  pay_time < order_time
  OR ship_time < pay_time
  OR ABS((unit_price * quantity) - total_amount) > 0.01;

3.4 基于参考数据的校验

这是准确性校验里最硬核的部分。说白了，就是拿你的数据和「标准答案」做比对。这个标准答案，就是参考数据。

参考数据可以是：

• 外部权威数据：国家统计局、工商局、银保监会等官方数据
• 内部主数据：企业内部的客户主数据、产品主数据
• 历史基线数据：经过人工核验的历史数据快照
• 第三方数据服务：企业征信、地址库、邮编库等

我在做金融风控数据治理时，就吃过参考数据不全的亏。当时我们校验用户身份证号，只做了长度和格式检查，结果大量虚假身份证号通过了校验。后来接入了公安部的身份证验证接口，准确率直接从 60% 飙到了 99.9%。

-- 基于参考数据的校验示例：比对客户地址与标准地址库
SELECT
  c.customer_id,
  c.address AS raw_address,
  s.standard_address,
  CASE
    WHEN s.standard_address IS NULL THEN '地址未匹配到标准库'
    WHEN similarity(c.address, s.standard_address) < 0.8 THEN '地址相似度不足'
    ELSE '地址校验通过'
  END AS address_validation_result
FROM customers c
LEFT JOIN standard_address_library s
  ON c.city = s.city
  AND c.district = s.district
WHERE
  s.standard_address IS NULL
  OR similarity(c.address, s.standard_address) < 0.8;

3.5 准确性校验体系全景

说了这么多，我把准确性校验的整体结构画成一张图，方便你理解各层之间的关系。

从这张图你能看出来，准确性校验不是单点作战。它从三层标准出发，经过三种校验方式，最终通过规则引擎输出结果。每一层都有坑，每一层都需要和业务方反复对齐。

我个人建议，刚开始做准确性校验时，先从字段级校验入手，快速出效果建立信心。然后逐步扩展到跨字段逻辑校验，最后再啃基于参考数据校验这块硬骨头。步子迈大了，容易扯着蛋。