深入理解 DataHub 的广义元数据架构GMA多存储引擎背后的统一后端基础设施【免费下载链接】datahubThe Context Platform for your Data and AI Stack项目地址: https://gitcode.com/GitHub_Trending/da/datahub导读GMAGeneralized Metadata Architecture广义元数据架构是 DataHub 的后端基础设施它摒弃了单库打天下的传统设计通过组合文档存储、图数据库与全文检索引擎分别服务文档 CRUD、复杂查询、图遍历和全文搜索/自动补全四类最常见的元数据访问模式。本文以 docs/what/gma.md 为核心结合仓库内的服务架构、元数据事件定义与 metadata-io 源码实现为你完整拆解 GMA 的设计动机、分布式部署模型、标准化访问层以及从写入到索引的完整数据通路帮助你理解 DataHub 元数据平台既能快读、又能深查、还能追关系的底层原理。GMA 是什么DataHub 的元数据后端GMA 是 DataHub 的后端基础设施backend infrastructure承载着整个平台元数据的存储、访问与索引。它区别于传统架构的关键点在于GMA 不复用单一存储技术而是利用多种专门的存储技术来高效服务四种最常见的查询模式面向文档的 CRUDDocument-oriented CRUD按主键读取/写入一个实体的一条或多条元数据记录复杂查询Complex queries包括跨分布式表的 join 查询用于在元数据之间进行关联分析图遍历Graph traversal沿实体间的边如血缘、所有权、成员关系进行多跳遍历全文搜索与自动补全Fulltext search and autocomplete对元数据做关键字检索与输入提示。这种按需选型、多存储协同的思路与 docs/architecture/metadata-serving.md 中描述的服务层路由策略完全一致主键读取路由到文档存储RDBMS 如 MySQL、Postgres 或 Cassandra全文与高级搜索路由到搜索索引复杂图查询如血缘路由到图索引。分布式模型每个团队拥有自己的 GMSGMA 还拥抱了一种分布式模型每个团队各自拥有、开发并运维属于自己的元数据服务即 GMSGeneralized Metadata Service。这些分散的元数据会被自动聚合填充到中央的 元数据图 和 搜索索引 中。这一设计之所以可行完全依赖于标准化的元数据模型与标准化的访问层。从 docs/what/gms.md 可以看到 GMS 的定位元数据通过名为 GMS 的微服务对外提供GMS 通常暴露 Rest.li API并必须通过 GMA DAO 访问元数据DAO 抽象详见 metadata-serving。GMA 在设计上支持一组分布式的 GMS 集群每个 GMS 只服务 GMA 图的一个子集不过为了简化部署当前仓库实际采用的是单一的集中式 GMS由它服务所有实体类型。分布式带来的实际收益GMA 团队相信这套架构能给任何需要存储和访问元数据的团队带来巨大杠杆tremendous leverage。具体体现在组织边界清晰不同团队可以独立演进自己的 GMS 服务互不阻塞数据自动汇聚团队本地写入的元数据通过标准化事件流自动汇入全局图与索引模型先行model-first标准化元数据建模推动了一种先定义模型、再开发功能的开发方式最终形成一个更简洁、更一致、高度互联的元数据生态惠及所有 DataHub 用户。标准化的元数据模型GMA 的基石GMA 之所以能让不同团队的 GMS 数据自动聚合前提是大家都遵循同一套元数据模型。DataHub 采用 schema-first模型优先方式使用 LinkedIn 开源的 Pegasus schema 语言PDL并扩展自定义注解来建模概念上由四类抽象构成详见 docs/modeling/metadata-model.md实体Entity元数据图中的主节点由类型如dataset、唯一标识URN和一组元数据属性分组即方面构成方面Aspect描述实体某一特定侧面的属性集合是 DataHub 中最小的原子写入单位同一实体的多个方面可被独立更新详见 docs/what/aspect.md关系Relationship两个实体之间的命名边通过在方面内以外键字段配合Relationship注解声明支持双向遍历详见 docs/what/relationship.md标识Key 与 UrnKey 是包含实体唯一标识字段的特殊方面可序列化为字符串形式的 URN 用于主键查找。模型定义集中在entity-registry.yml见 metadata-models/src/main/resources/entity-registry.ymlGMS 启动时校验该注册表并确保每个方面名都能找到对应的 PDL schema。这种以 YAML 配置登记实体/方面的方式使元数据模型的演进从新建 Snapshot/Aspect 文件简化为修改配置这正是 GMA 标准化模型能够长期演化的关键。GMA 的图以 Neo4j 承载实体与关系所有实体与关系都存储在图数据库中——当前仓库实现为Neo4j图相关实现位于 metadata-io/src/main/java/com/linkedin/metadata/graph其中neo4j/与elastic/两个子包分别对应图存储与基于 Elasticsearch 的图查询后端。图始终代表世界的当前状态本身不直接支持版本化或历史记录。但正如 docs/what/graph.md 所指出的图本质上只是所有元数据方面的派生视图因此永远可以从历史的 MAEMetadata Audit Event/MCL 事件流直接重建。由此引出一个强大能力通过把事件流回放到某个时间点就能构建该时刻图的特定快照。从理论上讲GMA 图可以替换为任何支持以下操作的通用 OLTP 图数据库节点与边的动态创建、修改与删除为每个节点和边动态附加键值属性对特定节点或边属性的事务性部分更新基于 ID 的节点与边快速检索同时高效支持图遍历 属性值过滤的查询支持高效的双向图遍历。这六项要求界定了 GMA 图存储的最小能力集也是评估能否作为 GMA 图后端的准入标准。GMA 的搜索索引以 Elasticsearch 承载全文与自动补全每一种搜索文档类型即实体类型都会映射到 Elasticsearch 中一个独立的搜索索引search index。除了搜索引擎的标准能力analyzer、tokenizer、filter queries、facet、sharding 等之外GMA 还额外支持以下特性详见 docs/what/search-index.md索引文档的部分更新partial update of indexed documents多值字段上的成员测试membership testing on multi-value fields索引间的零停机切换zero downtime switch between indices。搜索查询的抽象层由 Search DAO 提供详见 metadata-serving.md 的 Search DAO 一节对应源码可查看 metadata-io/src/main/java/com/linkedin/metadata/search 下的SearchService、LineageSearchService与elasticsearch/子包。搜索自动化TBDGMA 的长期目标文档中标注为 TBD是自动化索引创建、schema 演化与重建reindexing让团队只需关注搜索文档模型和自定义的 Index Builder 逻辑。具体设想是当逻辑发生变化时自动创建新版本的索引并从历史 MAE 回放填充待填充完毕后团队只需在 GMS 中做一次简单配置切换即可上线新版本需要时还能随时回滚到旧版索引。这与图从事件流重建的思路一脉相承——事件流是事实来源所有索引视图皆可派生。端到端数据通路从 MCP 提案到图与索引要理解 GMA 如何把分布式 GMS 的写入汇聚为中央图与索引需要看清其事件驱动的主链路。DataHub 依赖几类关键 Kafka 事件详见 docs/what/mxe.mdMetadata Change ProposalMCP对元数据图提出变更请求是摄入的中心环节。可通过 Kafka 异步发布也可直接调用服务层 HTTP 端点获得同步成功/失败响应见 docs/architecture/metadata-ingestion.md。默认 topic 为MetadataChangeProposal_v1。Metadata Change LogMCL分 Versioned 与 Timeseries 两类写入持久化存储成功后立即发出的提交事件。默认 topic 分别为MetadataChangeLog_Versioned_v1与MetadataChangeLog_Timeseries_v1。Platform EventPEDataHub 自身产生的业务逻辑事件如 Entity Change Event默认 topic 为PlatformEvent_v1。整条链路的消费端由两个 Spring job 承担见 metadata-jobsmce-consumer-job消费 Metadata Change Proposal通过/ingest端点写入 DataHub Metadata Servicedatahub-gmsmae-consumer-job消费 Metadata Change Log将变更应用到图与搜索索引。该 job 是**实体无关entity-agnostic**的会按需执行对应的图与搜索索引 builderbuilder 负责根据元数据变更告诉 job 如何更新图与索引。为确保变更按正确的时序处理MCL 按实体 URN 分键——同一实体的所有 MCL 会由单个线程顺序处理详见 docs/architecture/metadata-serving.md 的 Metadata Index Applier 一节。MCP 的一个完整示例下面是一个请求更新 Dataset 的ownership方面的 MCP 示例来自 docs/what/mxe.md展示了方面载荷如何以 JSON 字符串形式嵌在aspect.value字段中{ entityType: dataset, entityUrn: urn:li:dataset:(urn:li:dataPlatform:hdfs,SampleHdfsDataset,PROD), changeType: UPSERT, aspectName: ownership, aspect: { value: {\owners\:[{\type\:\DATAOWNER\,\owner\:\urn:li:corpuser:datahub\}],\lastModified\:{\actor\:\urn:li:corpuser:datahub\,\time\:1651516640488}}, contentType: application/json }, systemMetadata: { lastObserved: 1651516640493, runId: no-run-id-provided, registryName: unknownRegistry, registryVersion: 0.0.0.0-dev, properties: null } }注意changeType支持CREATE、UPSERT、DELETEPATCH对特定方面有有限支持contentType目前仅支持application/jsonentityType与实体注册表中的实体名一一对应如dataset。MCL 与 MCP 结构几乎一致只是额外增加了previousAspectValue、previousSystemMetadata与created审计戳字段用于描述变更前后的完整状态——这正是重建索引视图所必需的事件事实。查询路径GMA 四类模式在服务层的落地把四种查询模式映射到 docs/architecture/metadata-serving.md 的元数据查询服务一节可以看到清晰的路由分工查询类型路由目标典型场景主键读取文档存储RDBMS按dataset-urn获取数据集 schema 元数据次级索引读取搜索索引或强一致次级索引按属性过滤的元数据查询全文/高级搜索搜索索引关键字搜索、自动补全复杂图查询图索引血缘lineage、所有权、成员关系多跳遍历这也解释了为什么 GMA 需要多存储协同没有任何单一数据库能在文档读写、复杂 join、图遍历和全文检索四个维度上同时达到最优而 GMA 通过标准化模型 事件流 索引 applier让每个存储各司其职同时通过 MCL 事件流这是一个公开 API可被 Actions Framework 等外部系统订阅实时响应元数据变化。从源码看 GMA 的实现落点图存储抽象图查询与存储实现集中在 metadata-io/src/main/java/com/linkedin/metadata/graphneo4j/子包是文档所描述的 Neo4j 后端elastic/子包则提供了基于 Elasticsearch 的图查询实现JavaGraphClient、SiblingGraphService等类封装了图客户端与聚合服务。搜索服务抽象metadata-io/src/main/java/com/linkedin/metadata/search 中的SearchService、LineageSearchService以及elasticsearch/子包落实了独立索引 部分更新 零停机切换等 GMA 搜索特性。事件消费任务mae-consumer-job与mce-consumer-job两个 Spring job见 metadata-jobs分别实现了 MCL 的索引应用与 MCP 的写入是 GMA 分布式写入、集中式汇聚物理实现的关键一环。模型标准化metadata-models 模块含 693 个 PDL 文件与entity-registry.yml共同定义了 GMA 之上的统一模型层所有 GMS、DAO、索引 builder 均建立在这一模型之上。总结GMA 的核心设计可以浓缩为三句话多存储按需选型文档、图、搜索索引各司其职、事件流驱动视图派生图与索引都可从 MCL/MAE 重建支持时间点快照与索引零停机切换、模型与访问层标准化统一的 PDL 模型与 Rest.li/DAO 抽象让分布式 GMS 的元数据得以自动汇聚。对任何打算深入 DataHub 二次开发或自建元数据平台的团队而言理解 GMA 就等于掌握了这套系统的地基——它解释了为什么 DataHub 既能高效支撑文档式读写又能胜任血缘图遍历与全文检索同时还能在索引损坏时从事件流中一键重建。延伸阅读GMS 微服务层 · GMA 图 · GMA 搜索索引 · 元数据事件MCP/MCL/PE · 服务层架构 · 元数据模型 · 方面Aspect · 关系Relationship【免费下载链接】datahubThe Context Platform for your Data and AI Stack项目地址: https://gitcode.com/GitHub_Trending/da/datahub创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考