从"谁生产数据"到"谁对数据负责"，拆解数据网格最难的那一环。
一、原则很美，落地很痛
上一篇文章中，我们详细拆解了数据网格的四大原则------领域数据所有权 、数据即产品 、自服务基础设施 和联邦治理，并指出数据网格的核心价值在于"重构数据责任体系，实现全局标准与领域自治的平衡"。
但原则归原则，落地归落地。
当我的团队在和一家大型制造企业讨论数据网格方案时，一位数据架构师提出了一个非常现实的问题："每个业务域自己管自己的数据产品，听起来挺好，但我们到底该不该解散现有的集中式治理团队？如果各域用自己的标准做数据产品，跨部门分析的时候口径对不上谁来仲裁？"
这恰好是所有走向数据网格的企业都会遇到的核心困境。原则提出了一个美好的愿景------联邦治理是平衡集中控制与领域自治的"黄金中间态"。但在实践中，两个问题始终无法回避：全球标准与领域自治之间的边界划在哪里？联邦治理团队究竟应该做什么、不做什么？
联邦治理之所以被奉为数据网格的第四大原则，是因为没有它，领域自治就会退化成零散的数据孤岛。但这篇博文将聚焦一个更实际、更棘手的问题------联邦治理到底怎么"联"？
而华为的实践，或许是目前能看到的最完整的答案。
二、联邦治理的"两顶帽子"：谁做什么、谁说了算
在数据网格的语境中，联邦治理并非"一半集中一半自治"的模糊地带，而是一套边界清晰的责任分工模型------我将它称为"两顶帽子"模型。
理解这个模型的关键，是要先认清一个基本事实：集中式治理和数据网格并非完全对立的选择，而是可以找到中间地带------控制过强会扼杀业务敏捷性，控制过松又会导致标准混乱和数据孤岛。
水平职责：联邦治理团队
联邦治理团队的定位，是一个规则制定者+赋能者，而不是传统意义上的"管控者"或审批中枢。它的核心工作不是审批每一张表、每一条数据，而是建立能够让各域自主运转却又保持一致的游戏规则。
具体而言，联邦团队负责制定以下"全局框架"：
- 标准制定与维护 ：制定全局性的数据标准，如数据产品规范、元数据命名规则、安全分级策略等。这些标准并不包罗万象，而是被精心剪裁到"最少必要标准"的规模------只解决跨域协作中最痛的问题。
- 数据产品认证与准入：建立数据产品的"准入门槛"。联邦团队设立认证标准，包括必须有明确的产品负责人、SLA承诺、元数据文档和血缘追溯，但具体的认证执行可以交由自动化平台完成。
- 跨域争议仲裁：当业务域之间对数据口径、共享权限等问题产生分歧时，联邦团队以"中立裁判"的角色介入。这个角色与国内企业架构实践中架构评审委员会的定位高度一致------裁定标准冲突，而非逐条审批。
- 跨域协同规则的制定：仅强制约定少量关键的全局标准（例如核心业务对象ID格式、时间戳规范、安全等级标签等），其余的大多数数据治理事项交给各域在自治框架内自行解决。
- 自服务平台的规划与演进：确保自助服务平台能够服务于所有业务域的数据产品构建和使用需求，降低自治的数据产品团队的技术门槛。
垂直职责：业务域团队
每个业务域的数据产品团队则扮演着数据产品的"主人"角色，他们对自己的数据产品拥有完整的自治权。
具体职责包括：
- 数据产品的全生命周期管理：负责本域数据产品的设计、开发、质量保障和SLA承诺。消费方是否能够得到高质量的数据服务，直接取决于域团队的责任意识。
- 符合全局标准：在联邦团队制定的框架内，确保自己的数据产品符合安全、质量和元数据规范。
- 跨域协作的义务：当其他业务域需要访问本域的数据产品时，域团队应当以标准化接口提供访问通道，而不是筑起人为的数据围墙。
权责一目了然
| 职责领域 | 联邦治理团队 | 业务域团队 |
|---|---|---|
| 标准制定 | 制定全局框架 | 基于框架细化领域标准 |
| 数据产品认证 | 设定准入标准 | 建设并维护数据产品 |
| 跨域争议仲裁 | 裁定冲突 | 接受仲裁结果并调整 |
| 跨域数据访问 | 制定访问协议模板 | 提供标准化访问接口 |
| 质量监督 | 监控SLA并预警 | 对自身SLA负责 |
| 安全合规 | 定义全局安全策略 | 执行领域安全控制 |
华为的映射：强联邦式治理如何落地
上述模型并非纸上谈兵。根据华为公开的数据治理实践，我们可以看到一个完整的"强联邦式治理"组织映射：
| 通用联邦治理角色 | 华为对应角色/组织 | 职责要点 |
|---|---|---|
| 联邦治理团队（水平） | 公司数据管理部 + 信息架构专家组(IA-SAG) | 制定公司数据管理总纲、政策框架、仲裁跨域争议 |
| 业务域团队（垂直） | 各领域/BG实体化数据管理部 + 领域数据Owner | 负责本领域数据架构、质量、入湖及数据产品运营 |
| 跨域协作仲裁 | 跨领域数据联合工作组 | 解决数据质量、架构、服务等跨域冲突 |
| 平台赋能 | 集团数字平台项目组 | 建设数据湖、数据主题联接、数据服务架构 |
华为的特别之处在于：各领域的数据管理部是实体化组织，拥有独立的编制、预算和考核，而非兼职的"数据管家"。这正是"强联邦"区别于"弱联邦"的核心标志。
三、三个最关键的落地设计点
如果说"两顶帽子"模型划清了谁该做什么的边界，那么以下几个设计点则决定了联邦治理能否真正运转起来。
1. 数据产品认证机制：不是所有表格都能叫"数据产品"
数据网格中最核心的资产是"数据产品"，但如果没有明确的认证标准，"数据产品"很快会被滥用------任何一个业务域生产的一张表、一份报表都自称为"数据产品"，整个网格就会混乱不堪。
认证机制的关键在于：联邦团队只需要定义认证标准，不必亲自认证每一张表。具体的策略可以包括：
- 自动化认证流程：基于元数据平台（如DataHub、Collibra）自动评估数据产品是否符合标准------包括是否有明确的owner、是否完整地记录了元数据、是否建立了数据血缘等。
- 分级认证：不同的认证等级对应不同的信任级别。核心业务数据（如客户主数据、交易记录）需要严格认证，而辅助性或临时性的数据集只需要通过基础门槛。
华为的实践：华为通过"数据入湖标准"实现了类似的认证机制。各业务域必须完成数据清洗，使其符合公司信息架构与数据质量标准，才能将数据入湖。这一过程不仅是技术门槛，更是责任边界------各域数据Owner必须对入湖数据的质量终身负责。
2. 跨域数据访问的"代理式仲裁"模式
在传统集中式治理中，任何跨域的数据访问都需要中央团队审批，这成为瓶颈的根源之一。数据网格中的联邦治理必须打破这种模式，但不能走向另一个极端------没有任何约束。
解决方案是：联邦团队不介入每一次访问审批，而是制定访问协议模板和仲裁机制。当A域需要访问B域的敏感数据时，不经过B域同意就无法获取访问权------联邦治理团队在这里的角色不是每一单都审批，而是制定清晰的"访问协议模板"，以及当A域和B域无法达成一致时的"法庭式"仲裁程序。
华为的实践：华为设立了跨领域数据联合工作组（如信息架构建设工作组、数据质量执行组、元数据工作组等）。这些小组由各领域代表共同组成，跨域争议优先在工作组层面通过协商解决，重大问题才上升至公司数据管理部或信息架构专家组仲裁。同时，华为的数据服务架构提供了标准化的数据访问接口，使得跨域访问可以自助完成，只有争议才上升到工作组层面。
3. 全局一致性的最小集：少即是多
这是联邦治理中最容易被忽视的设计原则。许多企业在实施数据网格时，第一反应是"必须统一所有数据标准"，结果导致标准过重、无法执行，最终各域绕道而行。
正确的做法是：联邦团队只强制约定3-5个至关重要的全局标准。例如：
- 核心业务对象的ID格式：确保"同一个客户"在不同域中有唯一标识。
- 时间戳规范：统一使用UTC时间或企业标准时区。
- 安全等级标签：确保数据产品的安全分级清晰可查。
- 数据产品的"合同"标准：每个数据产品都必须提供SLA承诺、元数据文档和使用说明。
华为的实践：华为的顶层治理框架被称为"3+1数据政策"------数据质量管理政策、信息架构管理政策、数据源管理政策，再加上数据安全政策。这四条政策构成了公司级"最少必要标准"，而各业务域在此基础上可以制定更细化的执行细则。公司数据管理总纲明确："数据是企业的战略资产"，但如何实现这一战略，则由各域自主设计。
四、从集中式到联邦式的迁移路径
联邦治理的落地不是一个"一夜切换"的过程。对于长期依赖集中式数据治理模式的企业来说，突然解散中央团队只会在组织内部引发"权力真空"和治理混乱。
以下是一个分阶段的渐进迁移路径：
阶段一：集中式团队继续存在，同时孵化域负责人
在起步阶段，集中式数据治理团队保持原状，但开始有意识地培养各业务域的数据产品负责人。这个阶段的目标不是削减集中式团队的工作，而是将"自治"的种子植入各域中。
阶段二：设立联邦治理委员会，集中式团队转变为教练+平台赋能角色
当各域开始具备一定自治能力后，组织可以成立联邦治理委员会，由各业务域代表和原有集中式团队成员共同组成。联邦治理委员会负责：持续优化全局标准、仲裁跨域争议、推动自服务平台演进。此时，原有的集中式治理团队的定位需要调整为"教练"和"平台赋能者"------不再是审批者，而是帮助各域更好地遵守框架、提供技术支持和工具保障的角色。
阶段三：集中式团队完成"分化"------解散或重组为平台工程团队
随着联邦治理运行成熟，原有的集中式治理团队可以完成战略转型。一种可行的路径是：大部分成员融入各业务域，成为域内数据产品团队的核心力量；另一部分成员重组为专门的"数据平台工程团队"或"治理赋能中心"，持续打磨自服务平台，帮助各域以更低成本、更高效率遵守全局标准。
华为作为阶段三的成熟形态
经过多年变革，华为已经处于阶段三的成熟状态：
- 各业务域拥有实体化的数据管理部：每个领域/BG都有自己的数据管理组织，独立负责本域的数据架构、质量、入湖和运营。
- 公司级数据管理部转型为规则制定者与平台赋能者：不再审批具体数据，而是制定政策框架，并通过集团数字平台项目提供数据湖、数据服务架构等基础设施。
- 跨领域工作组成为常态化协作机制：虚拟团队持续运转，确保跨域问题有制度化的解决场所。
以Monzo为例的另一种路径
英国数字银行Monzo的转型过程同样印证了这一路径。Monzo在最近一年内重建了数据平台，最终支撑了超过100个团队管理着12000多个dbt模型。按照他们的原则，每个团队拥有和维护自己的数据模型，但Monzo通过自动化的护栏和共享工具支持这种分布式所有权。
关键的机制在于：Monzo通过定义清晰的建模层次、声明跨团队数据依赖的接口模型，以及通过CI/CD强制验证数据结构、命名规范和访问模式，实现了"人人可以贡献数据，但输出的质量必须一致"的目标。最终的成果也是相当显著的------仓库成本降低了约40%，数据交付速度提升了25%。
五、组织博弈中的"水面之下"
联邦治理的架构设计虽然复杂，但它的落地阻力往往来自技术之外------组织博弈才是真正的"水面之下"。
在推行联邦治理时，以下几类阻力最为常见：
存量权力与责任的重构。集中式数据治理团队长期以来掌控着数据标准的最终解释权。将这种权力"下放"给业务域，自然会引发抵触情绪。解决问题的关键不在于否定历史贡献，而在于为集中式团队找到新的价值定位------从"管控者"变为"赋能平台的设计者"。
业务域能力不足时的"甩锅"风险。如果某个业务域缺乏相应的技术能力或人员配置，联邦自治很容易变成"把球踢给业务"------最终的结果是没有人对数据负责。企业需要为业务域提供充分的培训和技术支持，甚至设立治理教练角色，帮助能力不足的团队跟上整体节奏。
跨域协作的"囚徒困境"。当A域需要访问B域的数据来满足自身业务需求时，B域可能缺乏合作意愿，因为这种协作只能为A域创造价值，却给B域增加工作负担。联邦治理委员会在此时需要扮演"激励设计者"的角色------建立数据共享的激励机制，让"贡献数据产品"成为可量化的绩效指标。
标准过度的陷阱。当标准制定者倾向于把所有细节都统一起来，标准本身就会成为落地最大的阻碍。这要求联邦治理团队成员具备"克制力"------始终铭记目标不是追求100%的全局一致性，而是保证各域数据产品能够"在一起工作"。
华为的实践再次验证了这一点：联邦治理的核心难题不在于"技术能不能实现"，而在于"人愿不愿意协作"。华为之所以能够成功，很大程度上依赖于其变革管理体系------将数据治理作为公司级变革项目，有自上而下的强制推进力，同时建立了跨领域工作组的制度化的协商平台。
六、华为启示：强联邦式治理的六个关键成功要素
从华为的案例中，我们可以提炼出六个可复制的关键成功要素：
1. 实体化组织是联邦治理的骨骼
各域数据管理部不是兼职，而是有编制、有考核的实体。领域数据Owner承担"全生命周期质量与安全"责任，并与个人绩效挂钩。
2. 治理政策要有"总纲"但不要"细则"
公司只定3-4条顶层政策（华为的"3+1"），执行细则由各域自行制定。这既保证了全局一致性，又避免了标准过重。
3. 跨领域工作组是粘合剂
常设虚拟团队，覆盖架构、质量、服务、分析、底座、元数据。这些工作组是跨域争议的"法庭"，也是标准演进的"孵化器"。
4. 数据Owner与流程Owner联动
数据治理嵌入业务变革和流程运营，而非孤立存在。华为的数据治理与流程管理、IT建设在同一个变革管理体系下协同推进。
5. 平台是自治的前提
没有自服务的数据湖、数据服务架构，领域自治就无从谈起。华为通过集团数字平台项目，建设了统一的数据底座，降低了各域的技术门槛。
6. 从"管控"到"赋能"的文化转型
公司数据管理部的定位从审批者变为规则设计者+教练。华为的质量与流程IT部不再审批每一张表，而是提供方法论、平台和仲裁服务。
七、从AI看联邦治理：不止于组织设计
联邦治理的设计初衷是为了平衡集中控制与领域自治，但在AI时代，这一平衡正从"组织优选"升级为"技术刚需"。
AI Agent（智能体）正在成为数据的新一代核心消费者。与传统BI不同，AI Agent要求数据具备三个新特征：场景就绪 （针对特定AI用例证明适用性）、实时信任 （毫秒级数据新鲜度而非T+1批处理）、以及可被机器理解（语义清晰、无歧义、有完整血缘）。这些要求对传统集中式治理构成了巨大挑战：
- 场景就绪意味着各业务域需要能够针对自己的AI用例自主定义"什么是好数据"------这正是领域自治的核心要义。
- 实时信任要求数据访问路径不能经过中央ETL的处理延迟，否则Agent的决策将基于过时信息。
- 代理式自治则指向治理本身的自动化：让AI系统自动执行政策监控、异常检测和修复建议，而非等待人工介入。
这三重挑战共同指向了同一个底层架构方向：联邦化。
联邦治理模式天然适配AI Agent的需求：各域自主定义数据产品的"AI就绪标准"；跨域数据访问通过自服务架构实时完成，无需中央审批；治理政策的执行可以下沉到边缘，通过代理式治理实现自动化。这已经不是组织设计层面的"可选项"，而是AI规模化落地的"必选项"。
这并非某一特定专家的个人看法，而是已成为行业共识。许多企业将海量数据一股脑地灌入庞大的数据湖或数仓，幻想通过'大爆炸'式的项目一步到位。然而，无数教训表明，这种模式最终只会导致项目周期冗长、成本失控，且产出的价值与实际的业务需求严重脱节。
联邦治理，正在从一个优雅的组织设计，演变为AI时代数据治理的生存底线。
八、结语：联邦治理的真正考验
数据网格的核心价值在于重构数据责任体系，而联邦治理正是这一重构的枢纽。
它的考验不在于技术实现难度，而在于一个更根本的命题：组织是否真的准备好将数据的"最终解释权"下放给业务域，同时又能确保企业整体在数据上保持可信、可协作、可创新。
这不是一个非此即彼的选择题，而是一个动态平衡的艺术。正如一位数据治理专家的总结------联邦治理就是要在个人自治与自上而下的集中控制之间、在责任下放与制定总体规则以保持一致性和秩序之间找到适当的平衡。与任何形式的有效政府一样，需要参与、代表、辩论和协作行动，才能真正完成任务。
从集中式到联邦式，不是一次架构升级，而是一次责任革命。
而华为告诉我们：这场革命可以成功------只要你有实体化的组织、制度化的跨域协作，以及从"管控"到"赋能"的决心。
参考资料：华为数据之道、数据网格原理论述、KPN/FlixBus/Monzo行业案例