数据治理旅程
“盘、规、治、管、用”用于把不同产品能力串成用户任务路径。它不是强制线性流程，也不代表 License、部署或接口依赖；企业可根据治理目标从任一阶段进入，并在结果不符合预期时返回前序阶段修正。
| 阶段 | 用户目标 | 主要产品能力 | 形成的结果 |
|---|---|---|---|
| 盘 | 识别数据在哪里、是什么、如何流转 | 元数据管理、基础血缘、SQLink | 资源清单、元模型、血缘与采集状态 |
| 规 | 统一名称、定义、口径和结构约束 | 数据标准、指标标准、指标管理；DDM 数据建模、数据架构 | 标准、标准代码、指标、映射关系、数据模型与架构约束 |
| 治 | 发现并闭环处理质量问题 | 数据质量 | 规则、检核结果、问题和整改记录 |
| 管 | 管理资产价值、权属和安全 | 数据资产 DDC、数据安全 DDS、安全网关 | 资产目录、分类分级、策略和审计记录 |
| 用 | 发现、申请和合规使用数据 | 数据市场、数据超市、数据服务、数据上下文 | 数据产品申请与审批留痕；API 发布、授权和调用；经核对的数据上下文 |
先确定业务目标和责任
选择一个范围清楚的治理目标，例如“让某业务主题的数据能够被理解、检查并申请使用”。这是一种实施方法，不要求一次纳入全部系统。
记录业务对象、来源系统、预期使用者及完成标准。按照系统管理的快速开始准备账号、数据源、角色和审批流程。
以下是建议职责，不是系统固定角色名称，应通过角色管理配置：
| 职责 | 主要负责 | 交接给谁 |
|---|---|---|
| 数据所有者 | 确认业务口径、权属及使用要求 | 标准、质量、安全和资产责任人 |
| 数据管家 | 补齐说明、协调映射及问题整改 | 各领域审核人员 |
| 元数据与血缘管理员 | 配置来源、采集和解析 | 标准管理员及业务分析人员 |
| 标准管理员与审核人 | 起草、复核并发布标准 | 字段维护和质量规则人员 |
| 质量管理员与问题责任人 | 检核、分派、整改和核验 | 资产责任人与使用者 |
| 安全与资产管理员 | 分类分级、策略、编目及发布 | 使用审批人和交付部门 |
| 数据使用者 | 提出需求并验收结果 | 反馈给业务责任人 |
同一对象的起草与最终审核宜分离。License、功能权限、目录权限及数据使用权限分别检查，不以管理员可见菜单作为所有用户的授权依据。
盘：把数据资源和关系查清楚
输入：应用系统清单、连接或线下元数据文件、业务负责人，以及实际脚本或报表来源。
- 按应用系统与数据源登记来源并测试连接。
- 按元数据采集限定范围执行，检查日志和采集对象。
- 按表字段维护核对物理结构，补充中文名和描述；报表与文件走对应管理路径，批量维护和对象属性检查参见元数据对象维护。
- 企业特有资产先设计元模型，再导入实际对象。
- 已有血缘结果时，从对象查看基础血缘。需要专业血缘建设时，按 SQLink 的采集与资源同步、任务解析准备链路。
检查点：采集完成与连接成功分开检查；对象来源、Schema、表字段能对应；解析失败与元数据缺失有处理记录。空血缘图不能证明没有业务依赖。
产出与交接：来源清单、可查对象、业务说明和可追溯的上下游关系。交给标准和质量责任人确认口径；资源缺失则返回采集处理。
规：统一业务定义并落实到字段
输入：已盘点元数据、业务制度、词汇、代码值域和指标口径。
数据建模和数据架构属于 DDM 产品线，在本治理旅程中仅用于说明它们与数据标准及结构约束的协同位置。具体概念、功能和操作请查阅 DDM 用户手册。
- 按标准目录与基础标准建立分类与定义，并维护标准代码、域标准和命名词典。
- 需要隔离业务领域或复用通用约束时，使用领域标准、域标准和命名词典。
- 按标准生命周期完成审批并确认已发布。
- 在字段上关联标准；范围较大时使用智能对标和聚合推荐，人工复核后接受。
- 执行自动核标，记录不符合项及处理意见。通过标准引用统计追踪标准所关联的系统、表和字段；不要把标准发布数量当作落标数量。指标定义使用指标标准；需要定义原子、衍生或派生指标并映射查询时进入指标管理。
检查点：名称相似不等于业务同义；标准已发布不等于字段已落标；建立映射不等于源数据已满足值域要求。
产出与交接：已审核标准、代码、指标与字段映射。技术不一致回到映射或标准变更；数据取值问题交给质量检核。
治：从检核规则走到可验证的整改
输入：明确的业务要求、目标数据范围、稳定记录标识、处理责任人。
- 按业务规则描述要求并发布。
- 按技术规则选择当前页面提供的编写方式，落实可执行检查。使用 SQL 时查询异常记录；环境提供正则方式时应表达正常格式，避免判定方向写反。
- 创建检核任务，先在小范围运行并核对报告。
- 在问题清单核对具体数据，分派给具有目录权限的责任人。
- 责任部门整改后关闭问题，再检查核验结果；未通过项按允许操作重新打开。
- 将原因、处理和复核方法沉淀到知识库。
检查点：执行成功、问题已关闭、核验全部通过分别判断。使用自动创建主键的规则无法核验，不适合作为需要持续跟踪同一异常记录的默认方案。
产出与交接：规则、运行记录、问题、整改及核验结论。业务口径不清回到标准；源对象不完整回到盘点。发布资产时向责任人交接质量情况，而不是仅交付一个总分。
管：明确资产归属和安全使用范围
资产编目与安全治理可以并行，最后分别检查发布和访问结果。
编目与发布
检查点：目录完成度衡量属性填写，不证明质量；确认盘点推荐只挂载资产，不等于发布；父目录未发布可能使已发布资产仍不可见。
分类分级与访问控制
- 按安全分类设计建立分类、级别和依据，法规材料参见法规条文。
- 通过协同梳理、分类分级工作台或识别任务获得结果并评审发布；算法维护参见识别算法管理。
- 按访问策略指定访问者、行范围和脱敏规则。
- 使用 JDBC 动态脱敏时，完成服务端网关与客户端配置。
- 以实际业务身份验证结果及审计。
检查点：分类发布不自动代表策略已生效；直连数据库与经网关访问不同；目录浏览权限与真实数据使用权限不同。
产出与交接：可浏览资产、责任归属、已评审分类级别、访问规则和验证记录。交给数据使用审批与交付责任人作为决策依据。
用：从业务发现走到申请与验收
除数据产品和 API 外，“用”阶段还包括数据上下文：围绕业务主题组织并核对相关资产、知识与治理结果，再通过 DIG 的上下文检查与发布供业务查询或智能体使用。
- 在数据市场按业务关键词或目录发现数据产品，详情和购物车操作见数据产品申请。
- 查看定义和范围，详情不可见时先申请目录浏览权限。
- 单个产品立即申请，多个产品加入购物车后一起提交；没有所需产品时新建文字需求。
- 按申请与审批跟踪流程和意见。
- 获批后由 IT 等责任部门在线下完成实际交付。
- 业务使用者对照获批用途与范围验收，问题反馈给相应责任人。
检查点：购物车不是申请单，申请提交不是审批通过，审批通过也不是数据已交付。DAM 在此记录申请与审批，不自动完成数据文件、账号或接口交付。
需要以 API 形式开放数据时，使用数据服务创建、测试和发布接口，再由调用方按API 市场与申请申请。该流程与数据市场的数据产品申请分别管理，不将数据市场的审批记录视作 API 授权。
用 SQLink 贯穿变更分析
需要追溯计算来源时查看算子与血缘；需要评估目标变更的影响时使用应用场景。先确保采集与解析结果可信，再据此组织标准变更、质量规则调整或资产使用方沟通。
源系统变化后，重新采集、查看变更历史、重新解析并抽查链路，然后检查标准映射、质量任务与资产描述是否仍适用。血缘提供影响线索，不代替责任人的业务判断。
首次接触血缘图时，可先做SQLink 在线解析教学样例，认识输入输出关系；它使用虚构对象，不作为当前企业链路覆盖情况的证据。把结果接入其他应用时，查询参数和返回字段见血缘查询接口。
用 DIG 辅助治理与构建上下文
具备 DIG 能力时，可按快速开始让智能体辅助补齐元数据、生成标准和质量规则、分类分级、落标及资产盘点。每类建议通过人工审批后，到相应业务模块检查结果。
围绕一个业务主题可建立数据智能空间，先组织治理，再按上下文检查与发布面向业务查询提供经过核对的上下文。需要从治理现状分析、治理清单、空间例程、主动治理到积分卡和 MCP 发布形成完整闭环时，参见 DIG 的数据智能空间端到端治理。DIG 是可选增强路径，缺少该能力时仍可按各产品操作完成治理。
从实际问题选择起点
不必为了完成治理旅程而先启用全部模块。以下路径以实际任务为起点，只有具备相应模块及前置结果时才继续。
| 当前问题 | 建议操作顺序 | 本次验收重点 |
|---|---|---|
| 不知道数据在哪里、由谁维护 | 登记来源 → 采集 → 检查对象及补说明 | 来源可追溯、对象能定位、业务责任已明确 |
| 同名字段含义不同或代码不统一 | 定义标准 → 发布 → 关联字段 → 核标 | 定义经过确认，映射到的是正确字段，不只是名字相近 |
| 数据不满足业务规则 | 业务规则 → 技术规则 → 检核任务 → 整改核验 | 具体异常有稳定标识，修复后能核验 |
| 资源多但用户找不到可用资产 | 空间与类型 → 盘点推荐 → 确认并发布 → 市场发现 | 普通业务用户能够找到正确对象并理解用途 |
| 不同用户需要看到不同的数据 | 分类分级 → 策略配置 → JDBC 接入 → 验证与审计 | 实际访问身份、范围、脱敏结果与记录对应 |
| 需要通过接口复用数据 | 开发 API → 测试与发布 → 申请授权 → 查看调用 | API、应用和授权一致，调用结果符合定义 |
| 表或指标变化可能影响下游 | 更新采集 → 解析任务 → 查看链路 → 影响场景 | 影响对象有可靠链路依据，相关责任人已经复核 |
用交接记录串起一次完整治理
以下是建议维护的治理交接清单，可用于项目记录或现有工单。它不是 DAM 自动生成的跨产品状态表，也不要求新建一个同名系统对象。
- 记录同一业务对象。 以应用系统、数据源、Schema、表和字段定位，补充业务名称及责任人。同名对象不能只凭名称跨模块关联。
- 交接口径。 标准维护人员提供已发布标准的编码、定义和代码值域；元数据维护人员提供具体字段的关联结果。接收方核对双方所说的是同一含义。
- 交接质量。 质量人员提供规则、任务执行记录、问题范围及核验结论；不能只交一个总分。未解决问题连同责任人和处理计划交给资产负责人。
- 交接安全。 安全人员提供已评审分类与等级、访问用途、策略适用身份及实际验证结果；不能只给策略名称或分类截图。
- 交接资产。 资产人员提供目录位置、权属、发布状态和访问范围；分别核对目录、子目录、资产，不以“挂载完成”代替发布。
- 交接用数。 使用者提交用途和范围，经预定流程审批后，将申请与审批依据交给线下 IT 等责任部门。交付部门执行后，由使用者核对实际内容与获批用途。
- 记录未完成项。 列明缺失关系、未通过核验、未完成审批或未交付内容。某一环节完成不能替代其他环节验收。
发生变化后回到哪一步
| 变化 | 首先回查 | 随后检查 |
|---|---|---|
| 来源表、字段或类型变化 | 元数据采集结果与变更历史 | 标准映射、检核规则、血缘关系及资产说明 |
| 标准定义或代码值域变化 | 标准变更审批与引用信息 | 已关联字段是否仍适用，是否需要调整核标和质量检查 |
| 检核仍有异常 | 问题数据、整改记录及核验结果 | 是数据未修复、规则不适用还是对象定位错误 |
| 分类等级或使用人员变化 | 评审结果、访问策略、人员归属 | 实际 JDBC 身份下的结果及审计；线下交付权限另行处理 |
| 目录或资产下线 | 本次下线范围与审批 | 父子目录和资产可见性；通知相关业务使用者是治理交接工作，不假设平台自动完成 |
每轮治理结束时检查
| 检查项 | 应能找到的证据 |
|---|---|
| 对象准确 | 来源、采集记录、业务说明及关系 |
| 口径一致 | 已发布标准、字段映射、核标结论 |
| 问题闭环 | 检核记录、责任人、整改及核验结果 |
| 可管理可控制 | 资产归属、发布、分类级别、访问验证 |
| 可申请可追溯 | 申请、审批及线下交付验收依据 |
| 可持续维护 | 调度、变更影响、未解决事项及下一轮范围 |