在一次数据治理平台选型评估会上，三家厂商依次展示了各自的“数据质量管理”能力——规则数量、质量报表、告警看板，演示效果都相当不错。但真正让台下架构师感到困惑的问题，其实隐藏在这些功能的外壳之下：那些规则究竟从何而来？能否与数据标准有效对应？发现问题后，是否能够一路追溯到源头系统、源表字段？修复完成后，平台能否自动执行复验？

这背后反映的，其实不是功能多寡的问题，而是一个架构层面的关键事实：数据质量管理的完整性，取决于平台在标准关联、监测链路、元数据血缘和质量反馈四个维度上的架构设计深度。

一、标准锚定：DCMM衡量管理能力，GB/T 36344界定质量指标

先来看两个国家标准的分工定位。DCMM 2.0（GB/T 36073-2025）从企业级管理视角出发，评估数据管理的成熟度水平。对数据质量而言，它关注的是企业是否已经建立了一套完善的质量管理机制——发现、分析、改进的闭环是否真正运转起来。

GB/T 36344-2018《信息技术 数据质量评价指标》则更聚焦于指标层面，定义了六个评价维度：规范性、完整性、准确性、一致性、时效性和可访问性。

从架构角度来看，这套分工其实非常清晰：DCMM评估的是管理流程的成熟度，GB/T 36344评估的是质量指标体系的完整性。平台设计时应实现双轨对齐——管理流程要覆盖DCMM的能力域，规则体系要覆盖GB/T 36344的六维指标。

需要特别强调的是，GB/T 36344明确包含六个维度。在AI或业务分析场景下，除了可访问性，其他五个维度确实直接影响分析可信度，但绝不能将标准简化成“五个维度”。

DCMM 2.0将数据管理成熟度划分为五个等级：初始级（1级）、受管理级（2级）、稳健级（3级）、量化管理级（4级）和优化级（5级）。从架构设计角度看，产品不必宣称自己能支撑最高等级，但至少应确保基础能力覆盖到三级（稳健级）——这是一个合理的架构目标。五级递进结构，对应的是管理精细化程度的逐级提升，而不是功能模块的有无。

二、评估模型设计：六维指标×六段流程

基于上述标准，数据治理平台的质量能力可以拆解为一个“六维指标×六段流程”的矩阵模型。

六维指标（规范性、完整性、准确性、一致性、时效性、可访问性）回答的是“查什么”，这是对GB/T 36344的工程化落地。六段流程回答的是“怎么管”，定义了从定义到复验的完整闭环：

这个模型的架构价值在于，它把“数据质量管理”从一个功能模块，拆解成了可独立验证的能力链。选型阶段可以逐项POC验证，运维阶段可以逐项监控。

三、架构原则一：标准与规则应建立关联映射

质量规则不应是孤立存在的配置项。从架构设计角度看，一条“手机号格式校验”规则，应该关联到客户数据元标准；一条“行政区划代码值域校验”规则，应该关联到代码集；一条“企业名称不能为空”规则，应该关联到业务对象的关键字段定义。

如果规则与标准脱钩，会产生两个架构债务：一是规则来源不清，导致业务参与度低；二是标准更新后，规则没有同步更新，导致质量检查滞后。

有效的POC验证方法：现场创建一个数据元标准，基于该标准配置非空、格式、值域或长度规则，然后检查平台是否维护了标准与规则的关联关系、版本一致性以及执行记录。

华东某数据局的实践提供了一个很好的参考：他们不只做问题修复，还编制了公共数据标准管理制度、公共数据元标准、自然人数据元标准、综合法人库数据元标准，并推动关键标准落实到核心数据表中。这本质上是用标准体系驱动质量治理，而不是用规则堆砌功能。

四、架构原则二：旁路监测架构支撑常态化扫描

质量监测在架构层面有两种模式。少数关键链路可以采用前置强校验——数据入库前通过质量门，不合规直接拦截。但在大规模公共数据、企业经营数据和多源归集场景下，旁路监测架构是更稳妥的选择。

旁路监测的架构特点：数据正常入仓（不阻塞主链路），质量模块并行扫描，发现问题打标记、发告警、生成工单。这种模式的工程优势在于，业务链路不受质量扫描影响，适合在不改造业务系统的前提下建立常态化治理机制。

从架构对比角度，强校验是“同步阻断”模式——数据在入库路径上被质量规则拦截，不合规数据无法写入。旁路监测是“异步扫描”模式——数据正常写入后，质量引擎并行拉取数据进行分析，问题以标记和告警形式产出，不侵入数据主链路。两者的工程取舍在于：强校验牺牲吞吐量换取数据洁净度，旁路监测牺牲实时拦截能力换取业务连续性。实践中多数架构采用分层策略——关键链路强校验，全量数据旁路监测。

江苏某大数据中心的实践验证了这套架构：围绕高频共享数据建立归集、治理、应用三层监测机制，累计评测高频共享资源超300个，处理数据量达10亿条，定位近1000万个数据质量问题，修复率95%，沉淀了5000个覆盖各维度的质量规则。

五、架构原则三：问题定位依赖元数据与血缘链路

质量问题如果只能定位到“某张表异常”，治理闭环就无法形成。架构上需要支持从问题记录逐级下钻：系统→表→字段→规则→责任部门。这依赖两个基础能力：元数据和血缘。

元数据提供数据对象的基本描述——字段含义、类型、来源系统、责任人、更新频率。血缘提供数据流转的可追溯路径——数据从哪里来、经过哪些加工节点、最终去了哪里。

需要指出架构边界：平台内的集成、归集、开发、共享环节可以自动采集血缘；但外部脚本直写、历史任务或未纳入平台的处理链路，仍需支持手动维护节点和连线。这是现实工程中的合理取舍，不应该被包装成“全自动血缘”。

华东某数据局建立了问题台账和修复知识库，将典型问题归纳为业务操作、业务规范、信息化技术、共享交换等类型。从架构层面看，这是将单次排查经验转化为可复用的治理资产。

六、架构原则四：质量结果应反馈到资产目录层

质量管理如果只停留在治理后台，架构上就割裂了治理与使用。一个成熟的数据治理平台，应该在架构上将质量结果回流到资产目录和数据服务层。

具体体现：业务人员在资产目录中搜索数据资源时，应该能看到质量评分、更新时间、责任部门、申请条件和可用状态。高风险数据要给出提示，或者要求额外审批。高频共享数据要持续跟踪调用情况和质量趋势。

可访问性维度就在这里落地：数据质量不光是“数据本身准不准”，还包括授权用户能否在合理流程下找到和获取数据。

华东某数据局治理前，资源目录初始合格率只有6.34%，标准化整改后提升到了94.74%，整体合格率99.93%。治理之后，更多的业务开始申请共享——高质量目录实实在在地提升了数据使用意愿。

七、理采存管用：质量治理在全链路架构中的定位

数据质量主要落在“管”阶段，但架构上它贯穿全链路。

• 理阶段：定义数据标准、质量目标和责任机制，是质量判断的基准层。
• 采阶段：记录数据来源、采集频率和方式，是时效性和准确性评估的输入层。
• 存阶段：通过模型分层和主题域建设统一口径，是跨系统一致性的保障层。
• 管阶段：标准、元数据、主数据、质量规则、安全管控形成治理闭环。
• 用阶段：质量结果进入资产目录、API服务、报表和AI用数入口。

从架构分层角度看，“理采存管用”五阶段模型天然映射为五个子系统：治理域（理）、集成域（采）、存储域（存）、管理域（管）、应用域（用）。各子系统通过定义良好的接口耦合，而非紧密集成。这种架构模式有几个工程优势：模块可按需独立部署，从最紧迫的模块起步；质量管控支持旁路监测架构，不侵入数据主链路；原生支持多租户工作空间模型，适配集团管控场景的治理组织分层。

所以，质量评估模型不是一个孤立模块的评估，而是对数据治理平台全链路架构的一次检验。

八、评估清单：架构验证的六个关键节点

这张清单不追求全量功能验证，而是抓住质量管理最关键的架构闭环。如果平台能在真实数据上跑通这条链路，质量能力的可信度远比演示报表高。

九、常见问题解答

Q1：质量规则越多越好吗？

并非如此。规则要覆盖核心业务对象和高频共享数据，并形成修复闭环。没有责任人和复验机制的规则，只会制造告警堆积。

Q2：GB/T 36344和DCMM是什么关系？

DCMM评估管理流程成熟度，GB/T 36344定义质量评价指标。进行平台评估时，可以用DCMM审视管理机制，用GB/T 36344检查规则覆盖。

Q3：旁路监测在架构上是否不如强校验严格？

适用场景不同。旁路监测适合不改业务系统、不阻断数据流的持续治理架构；强校验适合少数关键链路的前置控制。多数架构采用分层组合策略。