企业如何选数据中台？必须关注的5层架构能力

本文适合谁读：正在或即将进行数据中台（Data Middle Platform）选型的技术负责人、CDO（Chief Data Officer）、企业架构师；对数据治理（Data Governance）能力评估有需求的IT管理者。

阅读收获：你将获得一套基于 DCMM 2.0 和“理采存管用”五阶段方法论的选型评估框架，覆盖数据集成（Data Integration）、数据质量（Data Quality）、元数据管理（Metadata Management）、主数据管理（Master Data Management, MDM）、数据安全（Data Security）、数据资产目录（Data Catalog）与共享服务五大维度，附带可直接使用的选型检查清单。

一、问题的起点：功能列表两百项，业务还是用不起来

这是一个很典型的场景。

一家制造企业，CDO 带着团队花了四个月对比厂商、两个月部署上线。演示时功能列表拉出来两百多项，覆盖了你能想到的几乎所有数据场景。但半年过去，业务部门依然用不起来。

根本原因只有一句话：功能全都有，但数据不可信。

字段口径对不齐，物料编码不统一，同一个指标在不同报表里数值不同——业务部门谁敢用？

缺的不是功能，缺的是一套以治理能力为核心的系统化评估框架。

二、选型前的自我评估（Self-Assessment）

在接触任何厂商之前，先回答三个问题：

Q1：你要解决什么核心问题（Core Problem）？

是数据孤岛（Data Silo）打不通？是数据质量太差影响了报表可信度（Report Credibility）？还是缺少统一的数据服务层（Data Service Layer）让业务部门自己找数用数？

不同答案指向完全不同的选型侧重点。

Q2：你的团队能力（Team Capability）和投入预期（Investment Expectation）是怎样的？

有没有专职的数据治理人员？预算是项目制一次性采购还是按年持续投入？这决定了你能接住多重的平台。

Q3：你的 IT 环境有多复杂？

涉及多少套业务系统（ERP、MES、CRM、SRM）？有没有信创（XinChuang, 国产化替代）要求？是单体企业还是集团多组织？

DCMM 2.0（GB/T 36073-2025）将“数据战略”列为九大能力域之一，明确要求组织先厘清数据管理的目标和优先级——选型前的自我评估，本质上就是这一步。

三、评估框架：为什么是这五个维度

中国信通院《数据治理产业图谱 3.0》指出，数据中台市场已从“单一产品”向“平台化、组件化、可组装”（Platformization, Componentization, Composable）方向演进。

龙石数据中台采用的“理、采、存、管、用”五阶段方法论，恰好提供了一个评估尺度：

• 理（规划 Planning）：定战略、建体系、摸家底

• 采（采集 Collection）：多源异构数据归集

• 存（存储 Storage）：数据模型与仓库分层

• 管（治理 Governance）：标准 / 质量 / 元数据 / 主数据 / 安全

• 用（应用 Utilization）：资产目录 / 共享 / 分析 / 智能用数

方法论的价值在于提供一个评估标尺——脱离方法论谈功能列表，很容易变成“你有一百个功能我有一百零一个”的军备竞赛。反过来，以方法论为尺，看产品在每个环节能做到什么深度——这才是选型评估该做的事。

四、维度一：数据集成与标准管理（Integration & Standardization）

核心问题：能不能把散落在各系统的数据归集起来，同时确保大家说的是同一种“数据语言”？

4.1 集成能力考察要点

数据中台的第一道坎是“接进来”。企业的 ERP、MES、CRM 等系统动辄运行了五到十年，数据库类型不一、接口标准不一、数据格式不一。

考察时重点关注：

4.2 标准管理：数据的“通用语言”

数据进来了，字段名叫cust_name还是“客户名称”？“销售额”含不含税？不同系统的口径对不齐，接进来的只是一堆看不懂的数字。

数据标准管理能力——能否定义字段级的业务标准（Field-Level Business Standard）和校验规则（Validation Rule）——决定了数据的可用性下限。

4.3 案例

华东某大型化工企业，MES 里的生产数据与 ERP 里的经营数据长期割裂，物料编码在三个系统中各不相同，销售预测与生产排产完全脱节。

团队做的第一件事不是接数据，而是建立企业级数据标准体系——统一物料、产品、工序等核心业务对象的编码规则和指标口径。

标准先行，集成才有意义。

五、维度二：数据质量与元数据管理（Quality & Metadata）

核心问题：数据进来之后，怎么保证它是可信的？

这是区分“数据汇聚工具”和“数据管理平台”的关键分水岭。

5.1 数据质量管理（Data Quality Management, DQM）

考察要点：

• 质量规则能否可视化配置（而非写 SQL）？

• 业务人员能否参与规则定义？

• 质检模式：旁路并行扫描（Sidecar Monitoring）还是拦截入库？

值得关注的设计理念是旁路监测——数据正常入库，质检系统并行扫描，发现问题打标记、发告警、生成整改工单，但不阻断数据流转。

这种设计在保障数据流动性的同时实现了质量管控，相比“不过检不入库”的强拦截模式，更容易被业务部门接受。龙石数据中台的质量管理系统采用旁路监测方式，将质量规则配置从纯技术操作变为可视化拖拽，非技术人员也能上手。

5.2 元数据管理（Metadata Management）

考察时问几个具体问题：

• 元数据采集：全自动还是需要大量手工录入？

• 血缘分析（Data Lineage）：能不能跨系统追踪——从报表字段一路追溯到原始业务系统的源表？

这决定了出问题时能否快速定位根因（Root Cause Analysis），以及数据变更的影响范围能否提前预判（Impact Analysis）。

5.3 标准与案例

DAMA-DMBOK 2.0 将数据质量和元数据管理列为核心知识领域。DCMM 2.0 同样将数据质量列为九大能力域之一，要求问题能追溯到源头。

江西某国控集团建立了覆盖完整性（Completeness）、准确性（Accuracy）、一致性（Consistency）、及时性（Timeliness）、唯一性（Uniqueness）五个维度的自动化质量稽核体系——对应 GB/T 36344-2018《信息技术 数据质量评价指标》的核心维度。系统实时检测财务数据填报错误、投资项目信息缺失等问题，自动预警、精准整改。项目落地后，业务人员数据相关工作量明显下降。

六、维度三：主数据管理机制（Master Data Management, MDM）

核心问题：同一物料三种叫法、同一供应商多个编码——你选的产品能搞定吗？

主数据混乱是绝大多数数据问题的源头。物料、供应商、客户、项目部——这些跨系统共享的核心实体（Core Entity），一旦编码不统一、名称不一致，上面所有分析、报表、数据共享都建立在错误的根基上。

考察 MDM 能力时，不要只看“支持主数据管理”这句宣传语，要追问：

• 能不能制定统一的编码规范（Coding Standard）？

• 历史数据清洗（Data Cleansing）：手工还是半自动化？

• 主数据变更后能不能自动分发到各下游系统（Downstream System）？

• 合并冲突处理逻辑（Merge Conflict Resolution）能不能灵活配置？

案例

华东某建筑装饰集团，旗下两百余家区域子公司。同一装饰材料：苏州叫“大理石A级”，南京叫“A类石材”，总部采购系统里叫“石材_01”。

三种叫法 → 跨公司调拨、结算频繁出错 → 每月对账需要大量人工干预。

通过统一物料、供应商、项目部编码并建立主数据分发服务后：跨公司对账时间从五天缩短至一天，数据纠纷大幅减少。

DCMM 2.0 将“数据标准”列为独立能力域，MDM 的本质正是数据标准在核心实体上的集中落地。

七、维度四：数据安全与合规保障（Security & Compliance）

核心问题：数据安全不是装个防火墙就完了——从采集到使用的全链路，有没有兜底机制？

在信创环境日益普及、《数据安全法》等法规日趋严格的背景下，安全合规已从“加分项”变成“一票否决项”。

7.1 两层考察

第一层：基础安全能力

• 是否具备数据分类分级（Data Classification & Grading）功能？

• 敏感数据（Sensitive Data）能不能自动识别？

• 脱敏策略（Data Masking）能否覆盖全链路（采集→存储→计算→输出）？

第二层：信创适配（XinChuang Compatibility）

• 有没有完整的国产化兼容性认证？覆盖操作系统（麒麟、统信）、数据库（达梦、人大金仓、OceanBase）、芯片（华为鲲鹏、飞腾）等多个层面。

⚠️ 认证列表长 ≠ 适配好。务实的做法：POC 阶段就在实际信创环境上全链路跑一遍，而不是只看厂商提供的兼容性列表。

7.2 分权分域（RBAC & Workspace Model）

数据安全还有一个容易被忽视的维度：组织权限的精细化管控。

对于集团型企业，“总部要统一管、子公司要自治”的诉求天然存在。好的中台产品应支持分权分域的工作空间模型——总部制定统一的数据标准和安全策略，子公司或部门在独立空间内管理自己的数据资产，权限隔离但逻辑归集。

八、维度五：数据资产目录与共享服务（Data Catalog & Sharing Service）

核心问题：中台建好了，业务人员能不能自己找到数据、用上数据？还是换了一个地方继续提申请、等排期？

这可能是五个维度中最容易被忽略的一个。很多企业精力全放在“怎么把数据管好”上，忘了问一句：“管好之后，怎么让人用上？”

8.1 数据资产目录

数据资产目录不是 IT 人员看的元数据列表，而是业务人员的“数据地图”。好的资产目录应做到：

• 业务人员能用业务语言搜索数据，而非技术表名（如dw_dwd_sales_order_m）

• 能看到数据的含义和来源

• 能自助申请使用——从申请到审批到获取，全程在线（Online Self-Service）

8.2 数据共享服务（Data Sharing Service）

考察重点：

• 是否支持 API 服务化发布（API-as-a-Service）？

• 是否支持多种共享方式（API、文件、数据库视图）？

• API 网关（API Gateway）有没有流量控制（Rate Limiting）、鉴权（Authentication）、监控（Monitoring）能力？

8.3 案例

江西某国控集团除了数据质量稽核体系，还建立了可视化的数据资产目录和 API 共享服务。监管应用无需再做定制化接口开发，通过标准 API 即可获取数据。

这带来的深层变化是数据供给模式的转变：从“业务提需求 → IT 定制开发”的项目制，转向“数据资产上架 → 业务自助获取”的服务制。

国家数据局等十七部门发布的《“数据要素×”三年行动计划（2024—2026年）》明确提出推动数据跨部门、跨层级共享流通，资产目录与共享服务体系正是实现这一目标的技术基础设施。

九、选型清单（Selection Checklist）

9.1 隐藏维度：服务模式（Service Model）

数据中台不是买个软件装上就完了——它涉及组织变革和团队能力建设。

龙石数据中台的“产品 + 培训 + 陪跑”模式提供了一个参照：

• 理论培训：让团队知道“为什么做”

• 实施培训：让团队知道“怎么做”

• 实战陪跑：让团队在真实项目中“动手做”

判断标准很简单——项目结束一年后，你的团队能不能脱离厂商独立运营这个平台？

十、FAQ

Q1：功能多少算够？

不是越多越好。数据中台的核心价值在治理深度（Governance Depth），不在功能列表长度。当前主要需求是集成和基础报表，治理模块可后续扩展。但要建长期数据底座，标准、质量、主数据、元数据一个不能少。

Q2：开源方案能不能用？

取决于团队能力。如果有五人以上的专职数据工程团队，愿意投入半年做二次开发，开源方案可纳入评估。但团队以业务人员为主、希望尽快见效的场景，商用产品省的不仅是 License 费，更是时间成本和试错成本。

Q3：中小企业预算有限怎么选？

不看总价，看首年投入和见效速度。优先选模块化程度高的产品，先上最紧迫的模块（如数据集成 + 质量监测），跑通后再逐步扩展。

龙石数据中台支持功能模块独立部署、按需装配，单台服务器即可起步，部署周期约一周。这种轻量化启动模式（Lightweight Deployment）适合不想一次性大投入的团队。

Q4：信创环境怎么选？

确认厂商有完整的信创适配认证。但认证列表长不等于适配好——POC 阶段就在实际信创环境上全链路跑通，从安装部署到核心业务流程完整验证，这才是最可靠的做法。

参考来源

[1] DAMA International.DAMA-DMBOK2: Data Management Body of Knowledge (2nd ed.). Technics Publications, 2017.

[2] GB/T 36073-2025《数据管理能力成熟度评估模型（DCMM 2.0）》

[3] 中国信通院，《数据治理产业图谱 3.0》，2023年12月

[4] 国家数据局等十七部门，《“数据要素×”三年行动计划（2024—2026年）》，2024年1月

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

[6] 《中华人民共和国数据安全法》，2021年6月10日通过，2021年9月1日起施行