Software Systems Atlas

中文

English

中文

English

主题

第 12 卷 / 第 13 章 / 第 2 课

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

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

本课目标 ​

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

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

一份产品规范至少包含：

以下 YAML 是教学用自定义描述，不是某产品可直接执行的配置。table://、topic:// 和 registry:// 是示意标识，需要实际平台解析器与对应发布、策略和检查实现。

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
ingestion_time: ingested_at
available_time: published_at
schema_contract: registry://logistics/supply-event/v2
quality_slos:
  freshness: consumer-agreed target
  completeness: based on expected sites
classification: internal-sensitive
support: on-call route and issue tracker
deprecation: notice window and migration policy

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

采集时间不等于可消费时间：记录到达平台后，可能仍在质量检查或等待事务提交，所以另设 published_at。该产品定义为不可变确认事件，纠正用新事件引用原事件；若接口改为可修改的状态快照，主键、版本和撤销规则也必须相应改变。

2. 产品的八类能力 ​

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

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

3. Contract 分开语法与语义 ​

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

兼容不只看 schema：

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

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

一个具体兼容检查是：批表 v2 使用整数克，流接口 v1 使用十进制千克；在同一来源进度点比较事件集合与数值。以下标准库例子处理重放、排除进度点后的事件，并拒绝同 ID 冲突：

python
from decimal import Decimal

stream_v1 = [
    {"offset": 1, "event_id": "logistics:1", "quantity_kg": "2.5"},
    {"offset": 2, "event_id": "logistics:2", "quantity_kg": "0.5"},
    {"offset": 2, "event_id": "logistics:2", "quantity_kg": "0.5"},
    {"offset": 3, "event_id": "logistics:3", "quantity_kg": "9"},
]
batch_v2 = {"logistics:1": 2500, "logistics:2": 500}

def snapshot_in_grams(events, high_water):
    result = {}
    for event in events:
        if event["offset"] > high_water:
            continue
        grams = Decimal(event["quantity_kg"]) * 1000
        if not grams.is_finite() or grams <= 0 or grams != grams.to_integral_value():
            raise ValueError("positive whole grams required")
        key, value = event["event_id"], int(grams)
        if key in result and result[key] != value:
            raise ValueError("same event ID with conflicting content")
        result[key] = value
    return result

normalized = snapshot_in_grams(stream_v1, high_water=2)
assert normalized == batch_v2
print(sum(normalized.values()))
# 3000

示例只有一个来源分区。真实批流对账需要每个分区的进度、快照提交 ID、修订与删除规则；不同时间各查一次“最新值”不能证明接口一致。单位适配也不应悄悄舍入，无法用整数克表示时要拒绝或明确精度契约。

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

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

一条 paved road 可以提供：

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

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

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

共同规则可以分层：

全局不可协商 ​

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

互操作标准 ​

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

领域规则 ​

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

把规则实现为：

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

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

例如禁止未分类敏感字段发布：CI 校验字段分类是否齐全，发布器检查目标位置策略，运行时审计新写入与访问，例外控制验证到期。只在模板里放一个 classification 字段，无法阻止绕过模板的直接写入。平台需要把执行点放在实际发布和访问路径上。

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

小结 ​

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

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

Built with VitePress | Software Systems Atlas

Copyright 2026 Steven Yang