数据质量不过关，数据中台就是垃圾进垃圾出：从评价指标到治理闭环的技术拆解

本文适合谁读

  • 后端开发工程师 / 数据工程师：正在建设或接手数据中台项目，面临「数据不准、业务方不买单」的困境

  • 技术架构师：需要建立数据质量保障体系，从架构层面设计质量监测和治理闭环

  • 数据治理从业者：关注数据质量评价标准（GB/T 36344-2018）的工程化落地

核心观点：数据中台的核心价值是让数据可复用（Data Reusability），但如果数据质量（Data Quality）在源头没有保障，复用的不是资产，而是被放大的错误。本文从 GB/T 36344-2018 六个维度出发，拆解数据脏乱差的典型表现、根因以及从旁路监测（Side-channel Monitoring）到治理闭环的技术落地方案。

一、背景：中台建好了，为什么业务不买单？

一个典型场景：数据中台一期上线半年，数据集成（Data Integration）链路全部跑通——ERP、MES、CRM 的数据定时入湖，离线报表每天产出，可视化大屏如期亮起。但业务方的反馈是：「数据不准，不敢用。」

财务说中台的利润汇总和 ERP 对不上；销售说客户主数据（Master Data）里几百条重复记录；运营团队一言不发退回到 Excel 手工台账。技术团队也很委屈：ETL 任务没有报错、数据量级没有丢失、上下游依赖全部正常——问题出在哪？

答案：数据集成解决了「通不通」的问题，但没解决「对不对」的问题。数据质量治理，是中台从「能跑」到「能用」的最后一公里。

二、问题拆解：数据脏乱差的五种典型表现

在进入根因分析之前，先用对照表将数据质量问题的典型表现梳理清楚：

问题类型典型表现质量维度映射业务影响
字段缺失订单表的客户名称字段大量为 NULL，关键维度缺失导致聚合结果偏差完整性（Completeness）报表维度不全，无法按客户分组统计
数据错误结案时间（close_time）早于立案时间（open_time），逻辑上不可能准确性（Accuracy）时效指标计算错误，误导管理层决策
口径不一致同一物料在 ERP 中叫「碳钢 Q235B」，在 MES 中叫「Q235B-碳钢板」，在 WMS 中叫「CS_Q235B_10mm」一致性（Consistency）跨系统数据无法关联，物料成本核算失败
重复记录同一张采购订单在同步过程中产生了两条入湖记录唯一性（Uniqueness）订单金额重复汇总，财务对账偏差
数据滞后库存表上次更新时间是上周五，实际库存已在周一调整时效性（Timeliness）供应链决策基于过期数据，备货策略失误

这五类问题不是偶发的，而是系统性的。它们的共同特征是：不影响数据集成任务的执行成功状态，但让集成后的数据丧失可用性。而这恰恰是当前大多数数据中台项目验收体系里的盲区——验收只看「任务成功率」，不看「数据含金量」。

问题的普遍性远超大多数人的预期。华东某数据局在引入数据质量管理服务之前做过一次摸底：各部门提交到数据资产平台的目录，初始合格率只有6.34%。业务数据里的问题更触目惊心——教育系统里「同一个学籍号对应多个学生姓名」，司法系统里「结案时间早于立案时间」。制造企业中，同一物料在不同系统里有三个叫法，订单表客户名称字段有几百条空值，BOM 版本号和 ERP 里的对不上——这些都是系统性地存在，而非偶发。

三、根因：为什么建中台的时候没发现？

三个核心原因。

第一，集成阶段关注点错位。数据集成（Data Integration）的工作逻辑是抽取-转换-加载（ETL / ELT），核心验收指标是吞吐量和任务成功率。数据只要「搬过来了」就算完成。至于搬过来的数据是否完整、准确、一致——不在集成阶段的职责范围内。

第二，缺少元数据（Metadata）追溯链路。当业务方反馈数据不准时，技术团队往往无法快速定位问题来源。这条数据是从哪个源系统来的？经过哪些转换逻辑？被谁在什么时间修改过？因为缺少元数据血缘（Data Lineage），问题排查变成「猜谜游戏」。

第三，数据质量问题具有滞后性和放大效应。脏数据写入中台后并不会立刻暴露。它在下游任务中被引用、计算、聚合，经过若干轮流转后，才会以「报表数字对不上」的形式表现出来。届时，一份脏数据已经污染了多个下游数据集，修复成本成倍增加。

四、方案：从数据剖析到治理闭环

4.1 诊断：数据剖析（Data Profiling）

在治理之前，先要知道问题在哪。数据剖析（Data Profiling）是质量治理的起点，其核心动作是扫描目标数据集，统计基础指标。以一张订单表为例，剖析过程会逐字段计算以下维度：

  • 空值率（Null Ratio）：统计每个字段中 NULL 或空字符串的比例。例如customer_name字段的空值率反映了客户信息录入的完整程度

  • 唯一值数量（Distinct Count）：评估字段的基数特征，判断是否存在异常重复

  • 值分布（Value Distribution）：观察字段值的分布形态，识别离群值

  • 格式模式（Pattern Frequency）：检测字段值是否符合预期格式（如手机号、日期、编码格式）

  • 最小值 / 最大值 / 均值（Min / Max / Mean）：对数值型字段的范围和中心趋势做快速校验

这些指标不依赖复杂工具——对核心业务表做一轮基础扫描，就能快速量化数据质量的基线水平。关键是先看到问题在哪，再决定治理策略。

4.2 评价体系：GB/T 36344-2018 六维度

国标 GB/T 36344-2018《信息技术 数据质量评价指标》（Information Technology — Data Quality Evaluation Indicators）[1] 定义了六个评价维度。除可访问性（Accessibility）侧重权限控制外，其余五个维度直接决定数据是否可用：

  • 完整性（Completeness）：必填字段是否存在、记录数是否符合预期

  • 准确性（Accuracy）：数据值是否真实反映客观事实

  • 一致性（Consistency）：同一实体在不同系统中的值是否一致

  • 唯一性（Uniqueness）：是否存在重复记录

  • 时效性（Timeliness）：数据是否在可接受的时间范围内更新

  • 可访问性（Accessibility）：授权用户能否在需要时获取数据

实践中，对这些维度的检查可以通过旁路监测（Side-channel Monitoring）来做。下面详细展开这种模式。

4.3 监测：旁路监测模式（Side-channel Monitoring）

推荐采用旁路监测的架构模式，而非强校验拦截。

核心设计：数据从源系统（ERP / MES / CRM 等）经由集成管道正常写入中台存储层，写入完成后触发质量监测引擎进行并行扫描。质量监测引擎负责四件事：规则执行、问题标记、告警推送、工单生成。关键是这四条线全部异步、非阻塞——数据流转路径和质量检测路径是两条并行的管道，互不干扰。

核心原则：质检规则不对数据入库做任何拦截。数据正常写入，质检任务并行扫描，发现问题后打标记（Tagging）、发告警（Alerting）、生成整改工单（Remediation Ticket）。这保证了数据流转效率不受质量检查影响，同时确保问题可发现、可追溯、可度量。

以一个典型的质检规则配置为例——假设需要检查订单金额字段（order_amount）是否存在负值，属于准确性（Accuracy）维度的范围检查。配置时指定：目标表和字段、检查类型和参数（最小值为 0）、调度策略（每天凌晨执行 + 数据入库后立即触发）、告警渠道和阈值（错误率超过 5% 时推送通知）、以及自动生成整改工单并分配给数据负责人。所有这些配置通过可视化界面完成，无需编写 SQL 或脚本，降低了质量规则的维护门槛。

4.4 闭环：从发现到修复的工程化流程

质量治理最忌讳「打地鼠」——发现一个问题修一个问题，永远疲于奔命。必须建立工程化闭环：

  1. 常态化扫描（Scheduled Scanning）：质量监测引擎按周期对全域数据进行扫描，自动生成问题台账，问题按严重程度（Severity Level）分级

  2. 精准派发（Targeted Dispatch）：将问题定位到「哪个数据源、哪个表、哪个字段、什么问题、责任人是谁」，点对点推送整改工单

  3. 自动复验（Auto Re-verification）：责任方修复后，系统自动触发复验——运行同一质检规则，验证问题是否已消除，通过后归档

  4. 知识沉淀（Knowledge Accumulation）：将修复过程记录沉淀为问题知识库（Knowledge Base），同类问题再次出现时自动推荐修复方案

华东某数据局的实际案例表明：经过多轮治理闭环，各部门数据修复率超过 93%，数据目录合格率从初始的 6.34% 提升至 94.74%，累计沉淀质量监测规则 1000 余项。关键在于，这套机制不是一次性运动，而是融入了日常运维流程。

五、轻量起步：不要一上来就上重型平台

对于中小规模团队，数据质量治理不需要重型平台起步。推荐的策略是先体检、再决策。

具体做法：用轻量工具扫描核心业务表（财务、销售、库存等），快速生成数据剖面报告（Data Profile Report），回答三个问题：有多少字段缺失？有多少格式错误？有多少重复记录？——知道答案之后，再决定是加大治理投入还是维持现状。

轻量工具的核心能力要求：

  • 内置常用质检规则（空值检查、唯一性检查、格式规范性检查、一致性检查、逻辑检查等），可视化配置，降低门槛

  • 自动采集元数据，减少手工梳理工作量

  • 提供问题统计面板，让管理者直观看到数据质量水位

典型使用流程只需四步：接入数据源 → 自动采集元数据 → 配置评测规则 → 查看问题统计。从部署到跑出第一份质量报告，可以在几十分钟内完成。内置 12 类常用质检规则，覆盖空值检查、唯一性检查、格式规范性检查、一致性检查、逻辑检查等场景，全部可视化配置。

先做一次体检，摸清底数再决定后续投入——这条路不重，但它能让团队第一次真正看清自己的数据到底有多「脏」。

六、总结

数据质量问题普遍存在且被严重低估，但它不是不可解决的。

关键认知有三个层面：

  • 诊断层面：数据剖析（Data Profiling）+ GB/T 36344-2018 六维度评价，建立量化的质量基线

  • 架构层面：旁路监测（Side-channel Monitoring）模式，在不阻塞数据流转的前提下确保问题可发现

  • 流程层面：从扫描到复验的工程化闭环，把治理融入日常运维而非一次性项目

目录合格率从 6.34% 做到 94.74% 的真实案例证明：只要方法和机制对，数据的「脏乱差」是可以治的。关键是先迈出第一步——知道问题在哪，就成功了一半。

参考来源

[1] GB/T 36344-2018《信息技术 数据质量评价指标》，国家市场监督管理总局、中国国家标准化管理委员会，2018 年 6 月 7 日发布，2019 年 1 月 1 日实施。标准全文

延伸阅读

  • DCMM 国家标准：国家标准全文公开系统搜索 GB/T 36073，查阅数据管理能力成熟度评估模型完整文本，其中数据质量域定义了数据质量需求、数据质量检查、数据质量分析、数据质量提升四个能力项

  • DAMA-DMBOK 知识体系：DAMA International 官方发布的《数据管理知识体系指南》第十一章「数据质量管理」，系统性地覆盖了数据质量管理方法论、数据质量维度、数据剖析与清洗技术

  • 数据质量评价指标：GB/T 36344-2018 的六个维度（完整性、准确性、一致性、唯一性、时效性、可访问性），是数据质量工程化落地最实用的标准参考框架