Jiayun's Blog

引言：MLOps 的钟摆

ML 平台工程的钟摆正在发生新一轮摆动。

第一代（2016-2019）：各团队自建。每个数据科学团队有自己的训练脚本、特征管道和部署方式。Facebook FBLearner Flow、Google TFX 是内部先驱。

第二代（2019-2024）：大一统平台。Uber Michelangelo、LinkedIn Pro-ML、Airbnb Bighead——用一个端到端平台取代所有团队的自研方案。标准化带来了效率，但也带来了迁移成本和灵活性损失。

第三代（2024-）：元数据覆盖层。Netflix 2026 年 5 月发布的"Model Lifecycle Graph"（模型生命周期图谱）代表了这个新方向——不替换现有工具，而是在它们之上构建一层跨系统的元数据网络。

问题：ML 工具的孤岛化

Netflix 的 ML 生态系统庞大且多元。个性化推荐、内容制作（Studio）、广告、支付等不同业务域，各自发展出了成熟但相互隔离的 ML 工具链。

核心痛点是：

• 发现困难：一个数据科学家想知道"公司里有没有人训练过类似的模型？"——没有统一的搜索入口
• 血缘断裂：模型 A 依赖特征 B，特征 B 来自数据集 C，数据集 C 正在被改造——但没有人知道这条依赖链
• 所有权模糊：一个生产环境中运行了 3 年的模型，当初训练它的工程师已经离职，没人知道该由谁维护
• 跨域关联缺失：模型 → 训练管道 → A/B 测试 → 业务指标的关联需要手动追踪

架构：Metadata Service（MDS）

Netflix 的解决方案是 Metadata Service（MDS）——一个事件驱动的元数据服务，它不存储 ML 实体本身，而是索引和关联散落在各个系统中的 ML 实体。

核心抽象

1

Component → Entity → Entity Type → Domain → Provider

• Domain（域）：模型、管道、特征、A/B 测试、数据集、所有权
• Provider（提供者）：每个域可以有多个数据源（如模型注册表 A 和模型注册表 B 都是"模型域"的 provider）
• Entity（实体）：具体的 ML 对象（如某个特定的推荐模型 v3.2）

URI 统一寻址

每个 ML 实体都有一个全局唯一的 URI：

1

aip://<componentType>/<platformId>/<resourceId>

这使得跨系统引用和关联成为可能——你可以用一个 URI 精确指向"推荐团队的模型注册表中的 v3.2 模型"。

事件摄取与自愈

MDS 通过 Kafka 和 AWS SNS/SQS 接收"变更通知"事件。关键设计决策是：事件是瘦事件（只包含 ID 和事件类型），MDS 收到事件后主动调用源系统 API 获取最新状态。

这种"变更通知 + 主动拉取"的模式有一个重要优势：顺序无关、自愈。即使事件乱序到达，MDS 始终拉取的是最新状态，不会出现数据不一致。

存储层

• Datomic：不可变事实模型的图数据库，用于存储实体关系和支持图遍历查询
• Elasticsearch：全文搜索、发现和相关性排名

知识丰富化

最精巧的部分是异步后台知识丰富化（Knowledge Enrichment）：

MDS 运行后台任务，通过多跳推理发现跨系统关系。例如：

1. 模型 A 由管道 B 训练
2. 管道 B 使用特征集 C
3. 特征集 C 基于数据集 D
4. 模型 A 被部署到 A/B 测试 E

MDS 不需要任何系统显式声明这些关系——它通过图遍历自动推断，然后在 Datomic 中物化这些隐式边，并在 Elasticsearch 中重新索引。

API 与 UI

• GraphQL API 用于程序化查询
• AIP Portal 提供统一搜索 + 实体页面 + 关系导航的可视化界面

与前代 ML 平台的范式对比

Netflix 的方法之所以独特，是因为它承认了一个现实：在大型组织中，让所有团队迁移到同一个 ML 平台是不切实际的。不同业务域有不同的技术选择和历史包袱。与其强制统一，不如在异构工具之上编织一张元数据网络，让信息自由流动。

Netflix 自述的开放挑战

• 工具增殖：新的 ML 工具不断涌现，MDS 需要持续开发新的连接器
• 元数据质量：如何检测和处理过期/不一致的元数据
• 领域专属可视化：不同类型的 ML 实体需要不同的展示方式
• 高级关系推理：隐式关联发现、跨域推荐（“训练过类似模型的同事”）

核心判断

1. 元数据覆盖层是 MLOps 3.0 的范式。大一统平台的迁移成本太高、灵活性太低；元数据层保留了团队的工具自由度，同时解决了发现、血缘和治理的核心需求。

2. Datomic 的不可变事实模型非常适合 ML 元数据场景。ML 实体的生命周期是不可逆的（你不会"取消训练"一个模型），不可变存储天然匹配这种语义。

3. 图数据库在 ML 平台中被低估了。ML 实体之间的关系本质上是图结构——模型依赖特征、特征来自数据集、模型被部署到实验——关系型数据库在这种多跳查询上效率低下。

4. “瘦事件 + 主动拉取"模式值得借鉴。它解决了事件驱动架构中最头疼的顺序一致性问题，代价是对源系统 API 的额外调用——但在元数据场景中，这个代价通常可以接受。

5. ML 治理将成为监管焦点。当 EU AI Act 要求 AI 系统的可追溯性和可审计性时，像 MDS 这样的元数据图谱将从"效率工具"变成"合规必需品”。

对从业者的启示

• 中大型团队：不要急于构建 Michelangelo 级别的一体化平台。先从元数据层开始——索引你已有的东西，建立跨系统的可发现性。
• 小团队：开源的 MLflow + Feast + 简单的元数据表可能就够了。Netflix 的方案是为数百个 ML 团队的组织规模设计的。
• 架构师：考虑将 ML 元数据服务作为平台工程的一等公民——它对 ML 团队的价值类似于服务目录（Service Catalog）对微服务团队的价值。

参考来源

1. Democratizing Machine Learning at Netflix: Building the Model Lifecycle Graph - Netflix Tech Blog (2026-05)
2. Meet Michelangelo: Uber’s Machine Learning Platform - Uber Engineering (2017-09) — 第二代 ML 平台代表
3. Building a Platform for AI and ML at LinkedIn - LinkedIn Engineering (2021) — Pro-ML 架构参考
4. Datomic Architecture — 不可变事实模型数据库
5. EU AI Act - Official Text — ML 可追溯性监管要求