如何衡量数据质量？完整性、准确性与一致性的检查方法

衡量数据质量，先定分母，再按完整性、准确性、一致性逐项检查。完整性看该有的字段、记录和时段有没有，准确性看值和真实情况对不对，一致性看不同位置有没有矛盾。三项都通过，才能判断一份数据能不能用于分析、结算或对外汇报。

月底复盘时，运营看板、财务收款单和数仓订单宽表给出三个不同的订单数，是很常见的场景。有人先查 SQL，有人怀疑埋点，讨论很久却没有共同口径。要让数据质量变成可判断的问题，先得把它变成可计算的问题，明确检查哪张表、哪个时间窗、应有多少条记录、分子是什么、分母是什么。

下面这套方法从口径开始，依次检查完整性、准确性和一致性，再给出抽样、阈值、频率和一组可复算的演示数据。读者可以直接把检查卡套到自己的订单表、支付表或埋点事件表上。

一、先定口径，分母决定数据质量指标含义

一套可用的数据质量指标，至少要能回答四个问题，检查对象是什么，统计粒度是什么，时间窗有多长，分母取哪一批数据。少了其中任何一个，同一个 98% 都可能代表不同的事情。

分母常见有三种取法。

以订单为例。业务系统说当天应产生 100 笔订单，数仓订单表收到 100 行，支付表只有 96 条。字段完整率可以按 100 行算，支付记录完整率要按 100 笔应到订单算，金额准确率只能按能对上支付流水的记录算。三个指标都叫完成率或准确率，分母不同，不能直接比较。

检查卡至少要记录以下字段。

<code>检查对象：
统计粒度：
时间窗：
分子：
分母：
基准数据：
阈值：
检查频率：
责任人：
异常处理：
</code>

这张卡的作用是让检查可复现。换一个人、换一天，按同一张卡还能算出同一个数，指标才有比较价值。数据治理团队可以把这张卡作为共同语言，业务、分析和工程按同一口径讨论问题。

二、完整性检查，先看该有的有没有

GB/T 36344-2018《信息技术 数据质量评价指标》把数据完整性定义为按照数据规则要求，数据元素被赋予数值的程度。落到检查上，至少要分三层。

空值的判断要写进规则。NULL、空字符串、只有空格的字符串、占位值“未知”“其他”“0”，在不同系统里含义不同。金额字段的 0 可能是真实免费订单，也可能是漏填；渠道字段的“其他”可能是正常分类，也可能是兜底值。规则不写清，完整率就会忽高忽低。

<code class="language-sql">SELECT
  1.0 * (
    COUNT(*) * 3
    - SUM(CASE WHEN user_id IS NULL THEN 1 ELSE 0 END)
    - SUM(CASE WHEN amount IS NULL THEN 1 ELSE 0 END)
    - SUM(CASE WHEN channel IS NULL THEN 1 ELSE 0 END)
  ) / (COUNT(*) * 3) AS field_completeness
FROM orders
WHERE dt = '2026-10-01';
</code>

这段 SQL 算的是字段级完整率。若要看记录级完整率，直接用实际到达且能识别的记录数除以应到记录数。应到记录数通常来自业务系统、订单号段、支付回调或上游清单，不能拿数仓自己的行数当分母。

完整性检查发现问题后，定位顺序可以是采集端、必填校验、ETL 映射、分区产出。埋点事件缺参数，先看 SDK 版本和上报日志；订单表缺字段，先看上游是否允许空值；分区缺失，先看调度和数据到达时间。ETL 映射指的是抽取、转换、加载过程中的字段对应，把问题定位到具体环节，修复才有落点。

完整性高只说明该填的地方有值，不能说明值是对的。一个渠道字段 100% 有值，也可能全部填成了“未知”。

三、准确性检查，先找到可信基准

数据准确性看数据是否准确表示其所描述的真实实体。这个定义有一个前提，得有一个可信的真实值作为基准。没有基准，只能检查格式、范围和逻辑，不能算出准确率。

常见基准有四类。

• 源业务系统，例如订单系统、支付网关的原始记录。
• 外部流水，例如银行、支付渠道、结算单。
• 人工复核，例如客服回访、抽样盘点。
• 权威参考数据，例如行政区划、汇率、商品主数据。

准确性可以分两层检查。内容正确性看值是否等于基准；格式合规性看类型、长度、范围、枚举是否符合规则。格式合规只能算入门检查，不能替代内容正确性。

公式可以写成，准确率等于与基准一致的记录数除以参与核对的记录数。这里的分母有两种常见选择，报数时要同时写清楚。

两种算法都合理，区别在于是否把无法核对的记录算进分母。只报 93.9% 而不报覆盖率，读者会以为 49 条代表了 50 条；只报 92.0% 而不解释 1 条缺失，读者会以为有 4 条金额错误。更完整的写法是同时给出准确率和核对覆盖率。

抽样要按会影响结论的维度分层。订单金额核对可以按渠道、端、金额区间、新老用户分层；埋点参数核对可以按事件类型、SDK 版本、操作系统分层。每层先抽足够覆盖主要分支的样本，发现错误后再扩大样本；涉及结算、分成、合规的字段，优先全量或高覆盖核对。

准确性问题的常见来源包括业务录入错误、单位和币种不一致、时区转换、重复上报、测试数据混入生产、计算逻辑变更。定位时先确认基准本身是否可靠，再查数据加工链路。基准错了，准确率会反向指向错误的方向。

准确性检查通过，说明在核对范围内值是对的；它不能证明数据完整，也不能证明不同系统之间一致。

四、一致性检查，同一件事是否说同一个数

数据一致性看数据与其他特定上下文中使用的数据是否无矛盾。落到检查上，常见有三种一致性。

一致性检查要先把对账键、时间窗、币种和单位定清楚。订单表和支付表按 order_id 对账，时间窗都取 2026-10-01，金额都换成同一币种，才谈得上比较。时间窗错开一天，晚到的支付会被误判为缺失；币种没统一，金额差异会被误判为错误。

公式可以写成，一致率等于对账一致的记录数除以参与对账的记录数。参与对账的分母同样要写清楚，是按应检订单算，还是按能关联上的订单算。

例如订单表应检 100 笔，支付表能关联 96 笔，其中 4 笔金额不一致。按应检订单算，一致率是 92/100=92.0%；按可关联订单算，一致率是 92/96=95.8%。前者回答全部应检订单里有多少能对上，后者回答能对上的订单里有多少金额一致。两个数都真实，但不能混用。

金额比较可以设容差。分账、汇率换算、四舍五入会带来 0.01 元级别的差异，业务上可以约定容差；结算、退款、分成等关键字段，容差要更小，甚至要求完全相等。容差需要业务、财务和数据团队共同确认，并写进规则。

一致性检查发现问题后，先找权威源。订单金额以订单系统为准，还是以支付流水为准，要在指标口径里写清楚。权威源不定，讨论会停在两个数不一样；权威源定了，才能判断是同步延迟、重复写入、主数据不统一，还是口径差异。

两个系统一致，也可能是同错。一致性检查不能替代准确性检查。

五、把数据质量检查排成可执行流程

三项检查有依赖关系，顺序排错会得到看似正确、实际不可用的结果。

• 建检查卡，写清对象、粒度、时间窗、分子、分母、基准、阈值、频率和责任人。
• 先查完整性和唯一性。主键或业务键重复会让行数虚增，后续分母全错。
• 再查规范性和有效性。枚举、格式、范围不合法，准确性比对会混入噪声。
• 查准确性。能用规则全量比对的先全量跑，需要人工核对的按层抽样。
• 查一致性。按对账键、时间窗、币种和单位对齐后，再做跨表、跨系统对账。
• 查时效性和可访问性。数据按时到达、需要时能查到，才算可用。
• 记录结果、告警、复盘。每次检查留下分母、样本、阈值和结论，方便比较趋势。

GB/T 36344-2018 给出六个一级指标，分别是规范性、完整性、准确性、一致性、时效性和可访问性。唯一性常被团队单列，尤其在订单、支付和埋点事件表里。把六个数据质量维度落成检查卡，可以用下面这张表起步。

这套六维表可以作为数据质量评估的起点。完整性、唯一性、规范性通常可以全量跑；准确性需要人工核对时按层抽样；一致性按对账键全量或按时间片对账。下面是一组起步阈值示例，适合订单、支付这类交易数据，其他场景要按错误后果调整。

阈值要按业务后果定。结算字段错一笔可能造成真实损失，阈值应更严；分析字段缺一部分只影响分群精度，可以放宽。历史基线稳定后，再逐步收紧，避免一开始把阈值定得太高，团队天天处理噪声，最后关掉告警。

检查频率跟着决策节奏走。

质量分可以用来观察趋势，不适合替代维度检查。把六个维度加权成一个分数，权重一改，排名就变；一个核心金额字段失准，也可能被其他高分维度平均掉。更稳妥的做法是保留每个维度的原始指标，质量分只作为管理层看趋势的辅助视图。

六、用演示数据复算三项指标

下面是一组虚构的演示数据，只用来说明算法。数据对象是 2026-10-01 的游戏充值订单，业务系统显示当天应产生 100 笔订单，订单表有 4 个必填字段，order_id、user_id、amount、channel。

这组数字放在一起，能看出单看一个指标会漏掉什么。字段完整率 98.0% 看起来不错，支付记录完整率只有 96.0%，说明有 4 笔订单没有支付记录；金额准确率 93.9%，说明能核对的部分里仍有 3 笔金额不一致；跨系统一致率按应检口径只有 92.0%。这份数据可以用来观察趋势，直接用于结算或预算承诺之前，需要先补齐支付记录并查清金额差异。

演示数据还有两个细节值得注意。第一，如果订单号有重复，唯一性要先查。100 行里若有 2 个重复订单号，去重后只有 98 个订单，按行算的完整率会虚高。第二，准确率和一致率的分子可能相同，含义不同。准确率回答值和真实情况是否一致，一致率回答两个位置是否说同一个数。

把这张表固化成周报，连续看四周，比单次检查更有价值。趋势能区分偶发问题和系统问题，也能验证修复是否有效。

七、把检查前移到采集端

很多质量问题在数据进入数仓之前就产生了。事件没有定义清楚，必填参数没有约束，SDK 版本不一致，测试事件混进生产，都会让后面的检查变成补救。

ThinkingAI 的数据采集 Agent可以把这段工作前移。它根据业务问题生成埋点方案，落成代码埋点，再做 debug 验证，让事件、参数和上报时机在开发阶段就对齐。SDK 支持按业务配置采集范围，对敏感字段做脱敏，出现采集异常时可以降级，有助于减少因为采集端问题造成的字段缺失和事件错报。ThinkingAI 已服务全球超 1500 家企业，接入产品超 8000 款。

这类能力适合行为埋点和事件采集场景，不能自动扩展到工业数据采集，也不能替代任意数据库的实时同步。采集工具解决的是数据怎么进来，质量阈值、业务口径和问题闭环仍然要由数据团队和业务团队共同负责。

埋点校验可以加三道检查。上线前，用测试事件核对事件名、参数名、参数类型和必填项；发布后，盯事件量和关键参数的到达率；版本变更时，回归核心事件，避免新旧版本参数不一致。三道检查做完，后面的完整性、准确性和一致性检查会省很多解释成本。

八、常见问题

完整性 100% 就说明数据质量好吗？

不能。完整性只说明该填的地方有值，值可能填错，也可能和其他系统矛盾。一个渠道字段 100% 有值，如果全部是“未知”，完整率仍然很高，分析价值很低。完整性要跟准确性、一致性一起看。

准确性和一致性有什么区别？

准确性拿真实基准比对，回答值对不对；一致性拿不同位置的数据比对，回答有没有矛盾。两个系统可以一致地记录同一个错误值，所以一致性通过不代表准确性通过。

没有可信基准，怎么检查准确性？

先找源系统、支付流水、人工复核或权威参考数据。确实没有基准时，只能做格式、范围、枚举和逻辑检查，并在报告里说明准确率无法计算。不要用系统内部的自洽代替真实基准。

数据量很大，必须全量检查吗？

规则能全量跑的就全量跑，例如非空、枚举、范围、主键重复。需要人工核对的准确性检查可以分层抽样，但要报告样本量、分层维度和核对覆盖率。结算、分成、合规字段优先全量或高覆盖核对。

三项指标多久检查一次？

按决策节奏和数据新鲜度定。核心交易链路可以实时或小时级监控，字段空值和主键重复每天查，跨系统对账每周做，规则和阈值每月复盘。频率太高会产生大量噪声，频率太低会错过问题窗口。

质量分怎么算才合理？

按业务影响设权重，保留每个维度的原始指标，质量分只用于看趋势。核心金额字段失准应该单独告警，不能被其他维度的平均分掩盖。权重和阈值要有版本记录，口径变了要同步更新。

参考资料

• GB/T 36344-2018《信息技术 数据质量评价指标》
• 中国软件评测中心，《助力夯实数据底座，强化数据质量测评》，2022 年，https://cstc.org.cn/info/1081/245525.htm
• ThinkingAI 官网，https://www.thinkingai.cn