事实核验：2026-08-26 · 状态：现行内容
记录仅说明核验时间与维护状态，不保证适用于所有环境；使用前请留意正文中的版本、适用条件与风险提示。
数据治理项目库导览
数据治理项目容易出现两个极端：一端只讲框架、制度和委员会，另一端只讲平台、扫描器和规则配置。真正可交付的项目必须把业务问题翻译成治理对象，再把治理对象落到责任、流程、数据和工具上。本项目库围绕三类高频项目，提供从立项到验收、从交付到求职表达的完整工作样本。
学习目标
完成本项目库后，你应该能够：
- 区分数据标准、主数据和数据血缘三类项目解决的问题，不再把它们笼统描述为“建治理平台”。
- 把“口径不一致”“客户重复”“改表不敢上线”等业务原话翻译为可排期、可验收的治理需求。
- 为项目建立范围、角色、里程碑、交付物和验收证据，而不是只提交制度文档或系统截图。
- 识别组织机制与技术能力之间的边界：工具可以发现问题，但不能替代业务认责和变更决策。
- 将项目经历组织成可信的简历要点与三分钟面试表达，并能回答方案取舍、冲突处理和效果验证问题。
项目库地图
| 项目 | 主要矛盾 | 核心治理对象 | 最小可用范围 | 关键验收证据 |
|---|---|---|---|---|
| 数据标准与数据字典落地 | 同一概念多种定义，字段难理解 | 术语、指标、代码、字段、标准映射 | 一个主题域与一条消费链路 | 标准发布记录、字段映射、差异整改、使用抽查 |
| 主数据 MDM 建设 | 同一对象多套编码，跨系统无法识别 | 客户、供应商、商品、组织等核心实体 | 一个主数据域及关键系统 | 黄金记录、匹配准确性、分发回执、存量迁移对账 |
| 数据血缘与影响分析 | 来源不清，变更影响不可预判 | 表、字段、任务、报表、指标及依赖关系 | 一条关键数据链路 | 血缘覆盖、抽样准确、影响清单、变更演练 |
三类项目存在递进关系。数据标准回答“这个数据是什么意思、应该长什么样”；MDM 回答“这个业务对象的权威身份与属性是什么”；血缘回答“数据从哪里来、经过什么处理、变化会影响谁”。它们可以共享元数据、责任人和变更流程，但不应被合并成一个无法验收的“大治理项目”。
统一项目结构
每个项目都按同一套工作骨架展开，便于学习者复刻，也便于面试官判断经历是否真实。
1. 项目卡片
项目卡片先固定场景、角色、周期、边界与成功标准。卡片中的数字是项目计划口径，不是为了包装效果而虚构的业绩。实际复刻时，应替换为所在组织能核验的基线与结果。
2. 需求翻译
业务方通常不会直接提出“建设标准映射”或“实现字段级血缘”。治理人员要把原话拆为现象、风险、治理对象、控制点和验收证据。例如“两个报表销售额不同”不能直接翻译成“统一指标平台”，应先判断是统计范围、时间口径、维度归属、数据延迟还是数据错误。
3. 角色协作
治理办公室不是所有数据的最终负责人。业务 Owner 决定业务含义和使用规则，Data Steward 维护标准与质量，系统 Owner 负责源端改造，数据团队负责加工与技术元数据，安全与合规角色约束访问和留痕。项目经理负责推进，但无权替业务部门裁决定义。
4. 交付物与实施步骤
每个项目同时包含管理交付物和技术交付物。管理交付物包括范围清单、RACI、评审纪要、例外台账和运营机制；技术交付物包括模型、映射、规则、接口、血缘关系和监控。实施步骤遵循“选域试点—盘点现状—形成规则—技术落地—迁移验证—运营闭环”，避免先采购工具再寻找问题。
5. 验收
验收必须可重复。制度“已发布”不是业务已经采用，血缘“有连线”不是关系准确，MDM“有主表”也不代表消费系统真正使用。项目必须同时检查覆盖率、正确性、流程执行、消费采用和异常闭环，并保留抽样记录、系统日志、对账结果、审批记录等证据。
6. 简历与面试表达
简历采用“背景—动作—范围—结果—机制”结构；面试表达补充关键冲突、方案取舍和验证方式。不能把团队工作全部写成个人独立完成，也不能使用无法解释来源的提升比例。更可信的表达是说明覆盖了哪些对象、建立了什么控制、用什么证据证明上线有效。
推荐学习顺序
路线一：治理实施与咨询
先学习数据标准项目，掌握对象盘点、责任认定和评审发布；再学习 MDM，理解跨系统协同、匹配合并和分发；最后学习血缘，将标准、主数据和质量问题连接到技术链路。建议同步阅读 数据治理组织架构 与 数据治理项目管理。
路线二：数据开发转治理
先学习血缘项目，将熟悉的 SQL、调度和元数据能力转化为治理交付；再学习数据字典与标准映射；最后补齐 MDM 的业务建模、权威源和数据服务知识。可搭配 Apache Atlas 数据血缘追踪 和 元数据管理。
路线三：数据产品与业务分析
先学习标准项目，理解业务术语、指标与字段之间的映射；再学习 MDM，掌握客户、商品等公共实体；最后学习血缘，用影响分析支撑需求评审与版本上线。建议关联 数据字典管理 和 OneID 统一身份。
项目复刻方法
- 选真实场景：优先选择一个有明确使用方、数据责任人和错误成本的主题域。
- 保留原始证据：保存需求原话、字段样例、冲突记录和上线前基线，后续效果才能验证。
- 缩小第一阶段：标准先做一个主题域，MDM 先做一个实体，血缘先做一条关键链路。
- 建立决策台账：定义冲突、合并冲突、血缘歧义都要记录决策人、依据、日期和影响范围。
- 技术与流程同步上线：目录、接口或扫描任务上线时，同步发布责任、变更、例外和运营流程。
- 用消费端验收：确认报表、服务、任务和业务人员真正使用治理结果，而不只检查后台配置。
- 形成运营节奏：以新增、变更、质量、使用和例外指标持续复盘，治理项目才不会在验收后失效。
决策边界
- 需要先做标准，不一定需要 MDM：字段含义混乱但不存在跨系统同一实体识别问题时，先解决定义和字典。
- 需要 MDM，不能只做数据仓库拉链表：多个业务系统共同创建或修改核心对象，且需要统一身份、权威属性与分发回写时，应建立主数据治理。
- 需要血缘，不能只靠文档画图：链路变化频繁、系统复杂、变更风险高时，应自动采集技术血缘，并以人工确认补充业务语义。
- 不宜同时全面铺开：若责任体系尚未建立、源系统频繁重构或关键业务无负责人，应先完成范围治理与试点，而不是追求全域覆盖率。
练习：为一个主题域选择项目
假设公司出现三个问题：商品字段在 ERP 与电商平台含义不一致；同一供应商在采购和财务系统有不同编码；财务月报依赖一张即将改名的明细表。请分别回答：
- 每个问题首先对应哪一类项目？
- 第一阶段治理对象和系统边界是什么？
- 谁拥有定义权、谁执行技术改造、谁确认验收？
- 至少需要保留哪三类验收证据？
- 如果只能启动一个项目，如何基于业务风险、改造依赖和可交付性排序？
建议先独立写一页项目卡片，再对照三个项目正文中的模板修订。不要直接套用文中的计划数字，也不要把练习案例包装成真实工作经历。