Software Systems Atlas

中文

English

中文

English

主题

13.2 数据产品、平台铺路与联邦治理：自治必须能够互操作 ​

各领域独立发布了数据产品，消费者却要重新学习每一套身份键、时间口径和权限流程，自治开始变成新的孤岛。

首批领域各发布了一张“产品表”，格式、身份键、时间语义和权限申请方式却完全不同。消费者要组合三张表，反而比过去更慢。问题不在领域自治，而在自治没有共同接口，平台也没有把正确路径做成默认路径。

本课目标 ​

  • 定义数据产品的接口、SLO 和生命周期；
  • 设计平台的 self-service paved road；
  • 把联邦规则转成模板、策略和验证证据；
  • 用消费者结果而非产品数量衡量迁移。

1. 数据产品交付的是可消费能力 ​

一份产品规范至少包含：

yaml
id: logistics.confirmed-supply-events
owner: logistics-domain
purpose: confirmed supply movement for operational and analytical use
interfaces:
  batch: table://prod/logistics/confirmed_supply_events/v2
  stream: topic://prod/logistics/confirmed-supply-events/v2
grain: one row/event per confirmed supply movement
keys: [supply_event_id]
event_time: confirmed_at
available_time: ingested_at
schema_contract: registry://logistics/supply-event/v2
quality_slos:
  freshness: consumer-agreed target
  completeness: based on expected outposts
classification: internal-sensitive
support: on-call route and issue tracker
deprecation: notice window and migration policy

具体 SLO 不能从模板复制，要由消费者截止时间、失败成本和生产能力协商。对外 SLA 是否需要违约后果，取决于组织关系。

2. 产品的八类能力 ​

  • 可发现：目录、名称、术语和示例；
  • 可理解：粒度、时间、单位、NULL 和状态语义；
  • 可信：质量结果、事件状态和认证；
  • 可寻址：稳定资产 ID 与接口；
  • 互操作：共同身份、时间、schema 和策略约定；
  • 安全：分类、用途、最小权限和审计；
  • 有价值：明确消费者、决策和反馈；
  • 可维护：owner、支持、版本、成本和退役。

不必把每个内部临时表都提升为产品。产品数量越多，支持、目录和兼容成本越高。

3. Contract 分开语法与语义 ​

schema contract 约束类型、可空、枚举和兼容；semantic contract 说明粒度、单位、时间和业务规则；service contract 说明新鲜度、可用性、支持与变更。

兼容不只看 schema：

  • duration 从分钟改成秒，类型没变但语义已破坏；
  • 状态 done 重新解释为“结算完成”，枚举没变；
  • 历史数据回填改变过去指标，查询仍能运行。

因此变更检测需要机器规则与 owner/消费者评审。

4. 平台也要作为产品经营 ​

平台消费者是领域产品团队。平台团队应观察他们从代码到安全发布需要多少步骤、失败在哪里，而不是只交付一堆基础设施组件。

一条 paved road 可以提供：

text
产品模板与仓库
schema/契约注册和兼容检查
部署、调度与环境隔离
质量 SLI、日志、血缘和目录注册
身份、访问策略和审计
成本、配额和资源建议
事件、回滚与退役工作流

默认路径应安全且低摩擦，同时保留例外扩展点。强制所有场景使用同一计算引擎会把平台变成限制；允许无限自由则失去自助和互操作。

5. 联邦计算治理如何落地 ​

共同规则可以分层：

全局不可协商 ​

身份认证、敏感分类、审计最低字段、重大用途限制和事件响应。

互操作标准 ​

资产 ID、时间格式、schema 版本、通用实体键和契约协议。

领域规则 ​

业务枚举、质量阈值、发布频率、内部模型和支持细节。

把规则实现为：

  • 模板和默认配置；
  • CI 中的 schema/策略检查；
  • 发布时访问与分类门禁；
  • 运行时监控和审计；
  • 带 owner、补偿控制和到期日的例外。

“计算治理”不是所有政策都能自动决定。含糊或价值冲突的情况仍需人裁决，系统负责提供证据和执行决定。

6. 跨域身份与组合 ​

产品可单独正确，却因实体键、事件时间和慢变维不一致而无法组合。优先建立少量共享能力：

  • 全局/可映射实体标识；
  • 主数据与身份解析；
  • 事件时间、可用时间和时区约定；
  • 参考数据版本；
  • 跨域指标的组成与归属。

共享标准要解决真实消费问题，不能为了统一而建立无人采用的企业大模型。

7. 成本与激励 ​

领域承担生产成本，收益却可能落在其他团队。若只按成本考核 owner，他们会减少共享；若平台完全免费且不可见，又会产生浪费。

需要：

  • 显示生产、存储和消费成本；
  • 为跨域公共产品提供共享预算；
  • 把可靠性和消费者结果纳入领域目标；
  • 对低价值、无消费者产品及时退役；
  • 避免用查询量作为唯一价值指标。

8. 衡量是否真的改善 ​

比“有多少数据产品”更有意义的指标：

  • 消费者首次发现到成功使用的时间；
  • 契约变更提前量与破坏性变更率；
  • SLO 达成、事件恢复和重复事件；
  • owner/消费者问题响应时间；
  • 跨域集成所需手工映射数量；
  • 平台 paved road 采用率和逃逸原因；
  • 活跃产品、无消费者产品与退役时间；
  • 每个业务结果的总成本。

指标要与迁移前基线比较，并防止领域通过拆分产品或隐藏事件优化数字。

9. 渐进迁移 ​

text
1. 选一条有消费者的跨域价值流
2. 明确领域 owner、产品接口和当前基线
3. 平台补齐发布最痛的两三个步骤
4. 建立最小全局策略和例外机制
5. 双跑旧/新接口，验证语义与 SLO
6. 消费者迁移并提供反馈
7. 退役旧路径，复盘组织与平台缺口
8. 只在模式可复用后扩展下一领域

不要预设 6、12 或 24 个月的通用阶段。节奏取决于现有平台、团队能力、风险和迁移范围。

常见误区 ​

  • 一张带 owner 的表就是数据产品：还缺接口、语义、SLO、支持和生命周期。
  • 自助意味着没有平台支持：平台负责把复杂控制做成可用能力。
  • 联邦意味着所有规则可选：全局底线和互操作约定仍需执行。
  • 产品越多转型越成功：过度拆分会增加消费与维护成本。

练习 ​

  1. 为补给事件产品补齐语义、服务和安全 contract。
  2. 画出领域团队从提交代码到发布产品的 paved road，并找出人工等待。
  3. 把三条治理政策分成全局、互操作和领域层，再定义执行点。
  4. 为首个试点选择五个消费者结果指标，而不是产品数量。

小结 ​

Data Mesh 的自治必须通过稳定产品接口、共享平台能力和可执行治理变成互操作。真正的成功不是组织图变了，而是领域能更快、更安全地交付，消费者也更少依赖口头知识和人工协调。

最后一章进入隐私工程：无论数据由中央还是领域管理，都要控制收集、链接、访问、保留和发布造成的个人风险。

Built with VitePress | Software Systems Atlas

Copyright 2026 Steven Yang