数据中台数据治理怎么做？标准、元数据、质量与安全管理

数据中台数据治理可以拆成四类可执行的控制点：数据标准统一字段、事件和指标的定义，元数据记录数据在哪里、怎么流转、由谁负责，数据质量规则拦截不完整、不一致、不及时的数据，数据安全管理分类分级、权限、脱敏、审计和删除。四类工作共用一条数据链路，需要在标准定义、信息登记、质量验证与使用控制之间保持衔接。

一期建议只选一条已经影响经营决策的业务链路，比如注册转化、订单履约或退款结算。先把这条链路上的四类控制点跑通，形成标准卡、血缘图、质量规则、权限矩阵和验收记录，再复制到其他数据域。这样做的成本可控，也更容易让业务部门看到治理结果。

2026年7月1日，GB/T 36073-2025《数据管理能力成熟度评估模型》实施，也就是 DCMM 2.0。全国标准信息公共服务平台显示，该标准于2025年12月31日发布。新版标准把数据资产纳入能力域，并强化面向 AI 的多模态数据治理和高质量数据集要求。企业可以用它做自评，落到中台时仍要按自己的业务链路裁剪。

一、数据中台治理从哪里开始

四类治理对象的分工可以用一张表看清：

四类工作有先后依赖。标准没有定义清楚，元数据只能记录一堆含义不明的字段；元数据没有血缘，质量问题很难定位到源头；安全没有字段级分类分级，权限和脱敏就只能粗放处理。

1. 四类治理对象各管什么

数据标准解决“同名不同义”。同一个客户编号在订单系统、客服系统和财务系统里可能各有一套长度和编码规则，中台把它们汇到一起时，先要确认哪一套是权威定义。

元数据解决“看不见”。表名、字段名、任务依赖、接口调用和报表取数关系散落在不同工具里，没有一张统一地图，改一个字段就像在黑暗里拆线。

数据质量解决“不敢用”。报表上的数字对不上，业务人员就会回到 Excel 手工合并，中台的数据资产随之闲置。

数据安全解决“不能随便用”。中台汇聚了跨系统数据，权限一旦过宽，泄露影响会比单个业务系统更大。

2. 从哪里开始

一期范围可以由四类信号触发：

• 同一个指标在多个部门有不同口径，已经影响经营会议。
• 关键报表或接口出现过数据错误，业务方开始自行取数。
• 客户、监管或合作方要求提供数据处理记录和安全证明。
• 新系统、新渠道或新业务上线，旧的数据标准无法覆盖。

范围说明至少写清六件事：业务问题、涉及的数据对象、涉及的系统、下游报表或接口、责任人、时间窗。范围之外的需求进入待办清单，不占用一期评审。治理最怕一开始铺满所有主题域，评审会越开越长，系统改造却迟迟不开始。

图1：治理对象与数据链路

二、数据标准如何落到系统

数据标准常被写成一份字段字典，执行时仍然各说各话。常见原因是把字段、事件和指标混在一张表里管理，评审时业务、开发和分析各说一段，最后没有人对完整链路负责。

1. 字段、事件、指标分开管

三类标准要分开维护。字段标准解决存储约束，事件标准解决行为采集，指标标准解决汇总口径。字段标准可以复用到多个事件，事件标准又会成为多个指标的取数基础。

2. 一张标准卡写清什么

标准卡是制定工作的最小交付物。它要能让业务人员判断含义，让开发人员直接实现，让分析人员据此取数，让审计人员追溯版本。

一张可执行的标准卡至少包含这些内容：

• 标准名称、标准编码、业务定义、责任人和版本号。
• 生效日期、状态、来源系统、下游报表或接口。
• 正例和反例，用具体场景说明哪些算、哪些不算。
• 字段标准补充数据类型、长度、是否必填、值域或代码集、安全等级。
• 事件标准补充触发时机、触发条件、事件属性、去重键、上报端和测试用例。
• 指标标准补充计算公式、分子、分母、统计周期、时间窗口、维度和排除条件。

指标标准要写到能直接计算。以订单履约率为例，可以定义为统计周期内按承诺时间完成履约的订单数除以应履约订单数，分子排除取消单、测试单和重复单，分母按订单号去重，时间窗口按承诺履约时间计算。正例和反例比一段抽象定义更有用，评审时先看反例，分歧会暴露得更快。

字段、事件、指标三类标准卡的完整模板，可以参考数据标准怎么制定和执行。

3. 需求、开发、上线三道关口

标准执行失败，常见原因是标准没有进入研发流程。数据团队在季度末做一次检查，发现新系统又产生了一批不合规字段，再去推动改造，成本已经发生。

需求关口：新增数据需求进入排期前，需求方补充数据影响说明，写清新增哪些字段、事件或指标，是否复用已有标准，是否改变现有口径，影响哪些报表和接口。没有标准编码的需求，数据团队可以退回补充，暂不进入开发排期。

开发关口：数据模型按字段标准设计，事件上报按事件标准实现，指标 SQL 按指标标准计算。字段类型、枚举值、非空、长度、事件去重和指标对账要进入测试用例。能自动化的检查尽量自动化，工具不能替代评审，却可以把重复检查从人手里拿走。

上线关口：上线前确认标准、系统和报表三处一致。上线后观察一个完整统计周期，确认数据量、空值率、枚举分布和指标结果没有异常，再把旧口径下线。存量系统不适合一次性大改，先做字段映射和差异清单，按影响范围分批改造。

4. 变更先做影响分析

标准发布后一定会变。业务新增渠道、口径调整、监管要求变化，都会触发变更。变更分三类：澄清是补充说明，扩展是新增兼容的取值，破坏性变更是改变分子分母、统计范围或排除条件。

破坏性变更要先做影响分析，至少覆盖下游报表、数据模型、接口、分析 Agent、历史数据和外部报送。每一项写清影响方式、责任人和处理计划。上线时保留旧口径双轨运行，确认差异原因后再切换；不能重算的历史数据，要在报表中标注口径版本。

三、元数据与血缘如何管理

元数据管理要回答三个问题：数据在哪里，怎么流转，谁负责。它同时是标准、质量和安全的共同索引，缺少这一层，另外三类治理都会变成分散的台账。

1. 元数据采什么

采集以自动为主，手工补业务语义。自动采集可以拿到表、字段、任务和接口关系，业务含义、责任人和安全等级通常需要人工确认。一期先覆盖核心链路，不追求一次采全量；全量采集很容易变成一张没人维护的清单。

2. 血缘要能回答三个问题

血缘关系至少要在表级、字段级和指标级可用。它要能回答：

• 这个指标依赖哪些源表、字段和加工任务。
• 修改这个字段会影响哪些报表、接口、模型和分析 Agent。
• 质量问题发生在哪一环，应该找哪个系统或哪位责任人。

表级血缘解决范围，字段级血缘解决定位，指标级血缘解决口径追溯。只画到表级的血缘图，遇到字段口径争议时仍然不够用。

3. 元数据自己也要有责任人

每条核心元数据至少要有业务定义、责任人、来源系统、更新频率、安全等级和生命周期状态。新表、新字段、新指标上线即登记，变更时同步更新血缘。每季度巡检一次孤儿资产、无责任人资产、长期未更新资产和已下线但仍被引用的接口。

元数据的质量也要有规则。业务定义为空、责任人缺失、血缘断点、安全等级未标注，都应该像数据质量问题一样进入整改清单。元数据不准，影响分析和问题定位就会失真。

四、数据质量规则与整改如何运行

质量规则要跟着数据链路走。只在报表层做校验，问题发现得太晚；只在入库层做校验，又覆盖不了加工过程中的口径变化。

1. 入库、加工、服务三层规则

入库规则优先放在数据接入环节，能拦住的错误不要留到报表层。加工规则重点检查跨表、跨系统的一致性，比如订单表和支付表的金额是否对得上，指标汇总和明细是否能还原。服务规则面向使用方，告诉业务人员这批数据能不能用、什么时候更新、质量评分是多少。

2. 监控按影响分级

质量监控要按影响分级，避免所有异常都触发最高级别告警。可以按影响范围分三级：影响经营报表、对外接口或合规报送的，立即阻断并通知责任人；影响单个业务线分析的，当天处理；只影响探索性分析的，进入周度整改清单。

分级标准由企业根据业务节奏设定，不需要套用统一阈值。告警要带上下文：哪张表、哪个字段、哪个任务、影响哪些下游、最近一次正常时间。只发一句“数据异常”，接收人还要自己排查，告警很快会被忽略。

3. 问题闭环到人

质量问题可按六步处理：发现、定级、定位、修复与复验、复盘、规则更新。每一步留下记录，包括问题编号、影响范围、根因、修复人、修复时间、是否新增或调整规则。

定位环节要调用血缘，找到问题发生在源系统录入、采集、加工还是服务输出。修复环节要明确责任系统，不能所有问题都由中台团队兜底。复盘环节要判断同类问题是否会再次发生，必要时补充入库规则或修改源系统流程。

质量评分要跟使用场景绑定。经营报表、对外接口和 Agent 取数可以设不同门槛；评分低的数据可以限制使用范围，并标注风险，不必一律禁用。所有数据都追求满分，治理成本会迅速失控。

质量问题的根因经常在源系统。录入规范不统一、埋点设计缺失、主数据变更没有审批，中台只能拦截和补救，无法替代源头治理。数据开发与治理如果分属两套流程，质量问题往往在发布后才暴露，把质量规则前置到开发环节的做法，可以参考数据开发与治理双引擎。

五、数据安全与使用权限如何管理

安全治理从盘点开始。中台汇聚了跨系统数据，先要知道有哪些数据、哪些字段涉及个人信息或重要数据、哪些接口对外提供数据，再谈权限和脱敏。

1. 先分类分级，再谈权限

分类分级结果要落到字段级，不能只停留在系统级。个人信息要单独标识，敏感个人信息还要满足更高的处理条件。重要数据按行业主管部门发布的目录识别；目录尚未明确时，先按业务影响做初步评估，并保留评估记录。

2. 权限、脱敏、加密落到字段

权限控制可以采用角色权限加属性权限。角色决定能访问哪类数据，属性决定能看哪些行、哪些列。行列级权限要覆盖报表、SQL 查询、API 和 Agent 取数，不能只控制中台界面。

最小必要要落到申请、审批、使用和回收四个环节。权限申请写清用途和期限，审批人确认数据范围和敏感级别，使用过程留日志，到期自动回收。共享账号、服务账号和临时账号要单独管理，避免权限长期沉淀。

脱敏分静态和动态。静态脱敏用于测试、开发和数据外发，动态脱敏用于查询、报表和接口返回。加密用于存储和传输，密钥管理不能和业务数据放在同一权限域。脱敏规则要版本化，规则变更后要验证下游报表和接口是否仍然可用。

3. 审计、删除与出境

访问日志、导出日志、权限变更日志和异常查询日志要留存到可追溯的期限。审计不只是查“谁看过”，还要能查“谁改过权限、谁导出过数据、谁调用过接口”。发现异常时，能定位到账号、时间、数据范围和下游去向。

处理删除请求时，应核对主表、备份、派生数据、下游接口和Agent缓存中的关联信息。是否需要删除、何时删除以及备份如何处理，要结合适用法律、法定保留义务和数据是否仍可识别个人确定；不能把所有汇总结果一概认定为必须删除，也不能只处理主表而忽略仍受约束的副本。数据归档、销毁和跨境提供要有流程和记录，涉及出境时先按数据出境规则做评估。

《数据安全法》确立数据分类分级保护制度，《个人信息保护法》要求处理个人信息具备合法性基础，履行告知义务，遵循最小必要，敏感个人信息还要满足单独同意等条件。2025年起施行的《网络数据安全管理条例》进一步细化了重要数据识别、风险评估和事件报告要求。具体义务要结合行业重要数据目录、个人信息处理场景和业务所在地区判断，由法务与安全团队确认。

安全治理的可验证性来自记录。制度说明要求，记录证明执行，技术保证控制点生效，三条线要同时具备。更完整的数据安全与合规治理方法，可以参考数据安全与合规治理。

六、四类治理工作如何协同

四个模块如果各自建一套台账，治理就会变成四份互不对应的文档。更可行的做法是让它们共用一张标准卡、一份血缘和一套上线清单。

1. 一个订单履约率的例子

以订单履约率为例，从定义到上线可以拆成七步：

任何一步缺失，后面都会出问题。没有标准，订单履约率的口径会在部门之间反复争议；没有元数据，指标异常时找不到来源表和加工任务；没有质量规则，报表出错只能等业务发现；没有安全分级，订单明细可能被过宽权限访问。

这张联动表可以直接作为一期模板。每新增一个核心指标，就按七步填一遍；每个季度抽查一次，确认标准、血缘、规则和权限没有脱节。治理由此从四套台账变成一条可执行链路。

七、治理职责与实施节奏如何安排

治理需要明确角色，不一定要先建一个大团队。以下五类角色可以兼职，但要有具体名字。

1. 五类角色

业务数据 owner 不能由数据团队代替。订单取消算不算履约失败、测试订单是否计入，这些是业务规则，技术只能实现，不能替业务决定。数据管家可以是兼职，但要有一个明确的名字，不能写成某个部门。

2. 30天、60天、90天

以下90天安排为一期排期示例，不是固定建设周期；具体以接入难度、人员投入和阶段验收结果调整。

图2：治理试点的阶段安排（示例）

3. 验收看五组指标

目标值按企业现状基线设定，不需要套用统一的行业数字。一期验收看数据是否被敢用、被复用，文档数量和规则条数不能说明治理有效。

4. 工具选型看六件事

工具要能承载规则，不能只做展示。选型时优先看六件事：

• 是否以元数据为底座，能自动采集表、字段、任务和接口关系。
• 是否支持标准卡、映射表和变更记录，能把标准落到开发流程。
• 是否支持血缘追溯和影响分析，能定位问题并评估变更范围。
• 是否支持质量规则配置、监控告警和问题闭环。
• 是否支持字段级分类分级、行列级权限、脱敏和审计。
• 是否能与现有数据开发、调度、服务和身份体系集成，是否支持私有化部署。

先有规则和流程，再选工具。工具上线后仍要有人维护标准、处理告警和复盘问题，否则治理平台会变成另一个展示系统。

八、治理成果如何用于Agent

AI 分析 Agent 和业务 Agent 取数时，会放大三类问题：口径不一致、血缘不清、权限过宽。Agent 不会因为接入了大模型就自动理解业务，它依赖企业提供清晰、可追溯、可执行的语义和边界。

治理交付物要多一层机器可读性：指标定义、业务语义、版本、责任人、质量评分、安全等级和可用范围。指标只有一处定义，Agent 才能在不同业务线得到一致答案；血缘完整，Agent 才能解释数据来源；权限落到字段和场景，Agent 才不会越权取数。

ThinkingAI的企业级知识库可以把指标定义、业务口径和变更记录沉淀为可被 Agent 调用的知识资产。指标定义应由业务负责人确认并持续维护；具体知识更新、版本、审批及回滚能力，需要按实际部署逐项核对。Agentic Engine 支持私有化部署，已服务全球超过1500家企业、接入产品超过8000款。这类工具适合承载口径和知识的一致性；字段级落标、系统改造、质量规则和权限控制仍要由元数据、质量与安全模块配合。

AI 用数会把口径、质量和权限问题放大，治理成果需要提前准备好。希望把模型、知识库和 Agent 运行留在企业自有环境的团队，可以了解私有化部署的适用条件。

理解企业智能体的能力与责任边界，可参阅什么是企业级AI Agent。

常见问题

1. 数据中台数据治理先做标准还是先做安全？

如果业务链路已经出现口径争议，先做标准和指标；如果涉及个人信息、重要数据或客户审计，先做分类分级和权限。多数企业可以并行启动，标准负责定义，安全负责边界，两者共用同一份元数据。

2. 没有专职数据治理团队，最小配置是什么？

至少明确三类名字：业务数据 owner、数据管家、平台负责人。数据管家可以兼职，但不能写成部门名称。跨部门争议由数据治理委员会或现有的数据管理会议裁决。

3. 治理规则会不会拖慢开发上线？

短期会增加评审和配置工作，长期会减少返工。做法是把检查自动化，按影响分级，先管核心指标和敏感字段，不对所有数据设同一套门槛。

4. 数据中台和业务系统各自负责什么？

业务系统负责源头录入规范、埋点设计、主数据变更和一线数据质量；数据中台负责跨系统标准、统一模型、质量监控、服务输出和安全控制；业务数据 owner 对数据含义和使用结果负责。

5. 历史数据没有元数据和血缘，怎么补？

先补核心链路，不追求全量。用自动采集拿到表、任务和接口关系，再手工补业务含义、责任人和指标口径。历史血缘可以从最近一次任务运行和报表取数关系反推，无法确认的部分标注未知，不要编造。

6. 怎么判断一期治理是否有效？

看四件事：口径争议是否减少，问题定位是否更快，核心数据能否被更多业务复用，敏感数据权限是否可审计。文档数量和规则条数不能说明治理有效。

参考资料

• 国家市场监督管理总局、国家标准化管理委员会. GB/T 36073-2025 数据管理能力成熟度评估模型. 2025-12-31 发布，2026-07-01 实施. https://openstd.samr.gov.cn/bzgk/std/newGbInfo?hcno=22559F9C7BF9EAC6A3927223FE33CE20
• 中国工业新闻网. 标准发布，新版DCMM国标7月1日实施. 2026-01-16. https://www.cinn.cn/2026/01-16/zDPp7aoD.html
• 华为云. 数据中台及数据治理服务解决方案概述. https://support.huaweicloud.com/idms-dma/idms_01.html

数据中台专题相关阅读

• 什么是数据中台
• 一文读懂数据中台架构
• 数据中台和数据仓库有什么区别？
• 数据中台的作用是什么？企业哪些问题适合用它解决
• 数据中台包含哪些功能？