第2章 核心架构与运行机制
第2章 · 核心架构与运行机制
章节摘要：本章把 DataHub 拆开看个明白：整体上它是一个以元数据服务 GMS 为中枢、由文档存储、图存储、搜索索引三种存储协同支撑的系统；对内，一次元数据写入要经过变更提案、消息队列、索引更新的完整链路；对外，它通过 REST 与 GraphQL 两套 API 服务人机两类消费者。理解这些机制不是出于架构审美，而是出于实际需要——第 4 章的接入排错、第 6 章的性能调优，全部建立在本章的运行模型之上。读完本章，你应当能对着组件图说出每一条数据流的来龙去脉。
学习目标
读完本章，你应当能够：
- 画出 DataHub 的分层架构图，说明 GMS、前端、搜索服务、图服务各自承担的职责；
- 解释为什么 DataHub 要同时维护文档库、图库、搜索索引三种存储，以及各存储分别服务哪类查询；
- 完整描述一条元数据变更从提交到可被搜索的全链路，指出链路上每个环节可能出的问题；
- 区分变更提案与元数据审计事件这两个概念，说明事件流在架构中的作用；
- 用 REST 接口完成一次元数据读写，并用 GraphQL 完成一次带血缘的联合查询；
- 根据 API 的能力边界，判断哪些运维动作适合走接口、哪些必须操作底层存储。
核心概念速览
DataHub 的架构可以用一句话概括：一个服务中枢，三种存储，两类 API，一条事件流。下图给出全景——前端服务面向浏览器，GMS 是唯一有权写主存储的服务，搜索与图服务各管一类查询，所有变更经消息队列广播保证各存储最终一致。
一句金句概括本章：元数据平台的所有架构决定，本质上都是在回答"属性查询、关系查询、全文检索这三件事，凭什么共用一份数据"。 读完本章后回来重读这句金句，你应该能顺着它说出三种存储各自的位置、事件流串联它们的方式，以及两套 API 分别把哪类消费者接进来——说不全，就回到对应小节再过一遍。
子章节导航
- 2.1 整体架构：从 GMS 到存储层——分层拆解平台组件，重点解释"三存储并存"的设计理由与各存储的选型逻辑。
- 2.2 核心组件剖析：GMS、搜索与图服务——逐一打开关键组件，看它们的接口契约与协作方式，这是排错时的"部件手册"。
- 2.3 元数据的数据流：写入与查询——沿一条变更的生命周期走完全链路，把 MCE、MAE、索引双写等概念串成故事。
- 2.4 API 层：REST 与 GraphQL——两套接口的能力分工、典型用法与选型建议，附可直接套用的请求示例。
子章节之间的逻辑关系
四节构成"总—分—动—用"的递进：先看全景（2.1），再拆部件（2.2），然后让部件动起来看数据怎么流（2.3），最后站在使用者角度调用它们（2.4）。读 2.3 时若对某个组件的职责有疑问，回到 2.2 对应小节即可：
[2.1 全景分层] ──> [2.2 部件职责] ──> [2.3 数据流] ──> [2.4 API消费] 看结构 认部件 懂过程 会使用
前置知识与后续延伸
本章需要基本的分布式系统常识（服务、消息队列、索引），不需要图数据库经验——涉及的存储概念都会在使用场景里就地解释。建议先读不必深究存储实现细节，第一遍抓住"谁写、谁存、谁查"的主干即可。
第二遍的读法是带着问题回来。值班遇到"搜不到刚写入的数据"，翻 2.3 的查询分流；评审扩容方案，翻 2.1 的三存储职责；接到外部系统要调接口的需求，翻 2.4 的选路原则。本章的每个小节都对应一类真实的运维与开发场景，值得当手册反复查。
本章是第 3 章的前置：元数据模型如何存储、Aspect 如何被索引，都依赖本章的运行模型。也是第 6 章的底层依据：扩容哪个组件、监控哪个队列、排查哪种不一致，答案都藏在这条数据流里。
读不动整章时，最低限度掌握一个模型：谁有权写入（GMS）、数据存成几种样子（三种存储）、变更怎么传播（事件流）——这三问答得出来，本章及格。
顺带一提，本章的组件名会在全册反复出现，第一遍阅读不必记名字，记住每个部件回答的那一类问题即可。