DataHub 搜索索引GMA Search Index完全指南索引映射、Search DAO 与零停机切换机制【免费下载链接】datahubThe Context Platform for your Data and AI Stack项目地址: https://gitcode.com/GitHub_Trending/da/datahub每个搜索文档类型即实体类型都会在 Elasticsearch 中对应一个独立搜索索引DataHub 的搜索能力正是建立在这一一类一索引的映射模型之上。本文围绕 DataHub 文档体系中的搜索索引专题完整讲解其三大核心特性索引文档部分更新、多值字段成员测试、索引零停机切换、搜索文档的 PDL 建模方式、Search DAO 查询抽象以及 Index Builder 的索引构建与自动化演进路径并结合当前仓库源码给出可验证的实现依据帮助读者从模型到实现吃透 DataHub 的搜索索引机制。一、什么是 GMA 搜索索引在 DataHub 的元数据架构中每个搜索文档类型Search Document或实体类型Entity Type都会被映射到 Elasticsearch 中一个相互独立的搜索索引Search Index。这意味着索引与实体一一对应例如User实体对应一个userindexDataset实体对应另一个独立索引彼此物理隔离、互不干扰每个索引内的文档Document承载该实体的可搜索属性字段值由各类元数据 aspect 派生而来搜索请求按实体类型路由到对应的索引执行。这种设计让 DataHub 可以充分利用 Elasticsearch 提供的标准搜索引擎能力——分词器analyzer、tokenizer、过滤查询filter queries、分面faceting、分片sharding等而无需自己实现全文检索内核。在此基础上GMAGeneralized Metadata Architecture进一步支持以下三个区别于通用搜索引擎的特定能力索引文档的部分更新Partial update of indexed documents——修改某个元数据 aspect 后无需重建整个文档只需更新索引文档中对应的字段多值字段的成员测试Membership testing on multi-value fields——可以对数组类型的字段执行是否包含某成员的查询例如哪些文档包含标签 X索引之间的零停机切换Zero downtime switch between indices——可以同时维护新旧两个版本索引切换时业务无感知。这三个特性正是 DataHub 搜索索引设计的核心骨架后文将逐一展开其原理与实现。二、为什么需要独立的搜索文档模型要理解搜索索引先要理解它的输入——搜索文档Search Document。在 DataHub 中搜索文档同样使用 PDLPegasus Data Language显式建模其模型在很多方面与实体和关系模型相似每个属性/字段的值都由各种元数据 aspect 派生而来。但搜索文档有一个关键差异它允许拥有只包含原始类型primitive或枚举enum成员的数组类型属性。这是因为绝大多数全文检索引擎都支持针对数组字段做成员测试——例如一个文档中所有词项的数组字段这在全文检索场景下极其常用。字段的核心用途有二搜索过滤filtering例如找出所有姓或名与 Joe 相似、且向userFoo汇报的User搜索摘要snippet格式化由于搜索文档本身是搜索 API 的主要返回接口其属性可以直接用来格式化搜索结果的摘要展示。也正因如此设计者可能会倾向于添加尽可能多的属性。文档明确表示这是可接受的——底层检索引擎本身就被设计为支持海量字段的索引。搜索文档的 PDL 建模示例以下示例展示User搜索文档的 schema取自 docs/what/search-document.md其中有几个值得注意的设计约定每个搜索文档必须包含一个类型特定的urn字段一般映射到元数据图中的一个实体与Entity类似每个文档包含可选的removed字段用于软删除与Entity类似其余字段全部设为optional以支持部分更新management展示了字符串数组字段的写法ownedDatasets展示了如何从其他实体类型此例为Dataset关联的元数据 aspects 派生字段。首先是一个公共基类BaseDocument存放所有文档通用的字段namespace com.linkedin.metadata.search /** * Common fields that may apply to all documents */ record BaseDocument { /** Whether the entity has been removed or not */ removed: optional boolean false }然后是具体的UserDocumentnamespace com.linkedin.metadata.search import com.linkedin.common.CorpuserUrn import com.linkedin.common.DatasetUrn /** * Data model for user entity search */ record UserDocument includes BaseDocument { /** Urn for the user */ urn: CorpuserUrn /** First name of the user */ firstName: optional string /** Last name of the user */ lastName: optional string /** The chain of management all the way to CEO */ management: optional array[CorpuserUrn] [] /** Code for the cost center */ costCenter: optional int /** The list of dataset the user owns */ ownedDatasets: optional array[DatasetUrn] [] }可以看到urn是必填字段作为文档主键通常与图索引graph中的实体 URN 一一对应management、ownedDatasets这类array[...]字段正是第一节提到的多值字段成员测试的载体——Elasticsearch 天然支持对数组字段做 term 查询与过滤所有业务字段均声明为optional这为部分更新提供了模型层面的前提更新一个字段时不需要同时提供其余字段。三、核心特性一索引文档的部分更新传统做法中当某实体的元数据变化时通常需要删除旧文档并用新文档整体重建。DataHub 的搜索索引则支持对已索引文档进行部分更新只更新发生变化的字段其余字段保持不变。这一能力与搜索文档模型中所有字段均可选optional的设计相辅相成。从架构链路看元数据变更被提交为 Metadata Change ProposalMCP由 mce-consumer-job 消费并写入 DataHub Metadata Service服务端成功提交后通过 Kafka 发出Metadata Change LogMCL事件由另一个 Spring 任务 mae-consumer-job 消费 MCL调用对应的搜索索引构建器Search Index Builder把变更应用到搜索索引同时也会更新图索引。在 docs/architecture/metadata-serving.md 中明确说明mae-consumer-job是实体无关entity-agnostic的它会执行对应的 graph 与 search index builders当某个具体 metadata aspect 发生变化时builder 会告诉任务如何基于该变更去更新图与搜索索引。为了保证元数据变更按正确的时序处理MCL 会以实体 URN 为 key 进行分区——这意味着同一个实体产生的所有变更事件会由同一线程串行处理从而避免并发乱序导致的索引状态错乱。部分更新的落地点在 metadata-io 模块 的 Elasticsearch 数据访问层Search DAO 的实现索引文档的写入与更新均经由该层封装执行。四、核心特性二多值字段的成员测试正如搜索文档模型所强调的数组字段只含 primitive 或 enum 成员是搜索文档的特权结构而支撑它的正是检索引擎对数组字段的原生支持成员测试例如某文档是否包含标签PII在索引中体现为对数组字段的 term 过滤分面统计多值字段可以方便地做 faceting例如按标签、按平台统计各维度的文档数量词项索引全文检索场景下一个文档的全部词项构成数组字段用于相关性匹配。这种能力让 DataHub 的搜索过滤表达式可以直接落在多值字段上例如第一节中找出姓或名与 Joe 相似且向userFoo汇报的 User这类组合查询就同时用到了单值字段的相似匹配与多值字段management的成员测试。从源码看该能力由 ESSearchDAO.java 将 GMA 的查询模型翻译为 Elasticsearch 查询 DSL多值字段被映射为 ES 中的数组字段并参与过滤与聚合对应的行为在 SearchDAOElasticSearchTest.java 等测试中有系统验证。五、核心特性三索引之间的零停机切换当索引 schema 演进或构建逻辑发生变化时DataHub 并不要求直接原地修改正在服务的索引而是支持双索引并行 原子切换的机制保证搜索服务零停机当构建逻辑Index Builder变化时创建一个新版本的索引新索引从历史 MAEMetadata Audit Event即历史元数据变更事件流中回放、重建并逐步填充完整待新索引完全就绪后通过 GMS 侧的一次简单配置变更将查询流量切到新版本索引如果新版本出现问题可以随时回滚rollback到旧版本索引。这种版本化索引 配置切换的设计把 schema 演进与 reindexing 从夜间停机窗口式的运维操作变成了可随时执行、可随时撤销的日常操作也是搜索自动化愿景的核心支撑详见第七节。六、Search DAO搜索查询的抽象层GMA 将搜索查询抽象为Search DAOSearch Data Access Object把上层搜索逻辑与底层检索引擎实现解耦。在 docs/architecture/metadata-serving.md 中Search DAO 被定位为 GMA 搜索查询的核心抽象主键读取基于主键例如按dataset-urn读取 schema 元数据的读取路由到文档存储如 MySQL、Postgres、Cassandra 等 RDBMS 文档库二级索引读取基于二级索引的读取路由到搜索索引全文与高级搜索路由到搜索索引复杂图查询如血缘 lineage路由到图索引。也就是说搜索索引不仅承载全文检索还承担了二级索引的职责与主存储共同组成 Metadata Query Serving 的完整路径。在实现层面Elasticsearch 的实现位于 ESSearchDAO.java它负责将 GMA 的查询请求翻译成 Elasticsearch 查询 DSL 并执行对应的查询抽象测试见 SearchDAOTestBase.javaElasticsearch 与 OpenSearch 两个实现各有独立的测试类SearchDAOElasticSearchTest.java 与 SearchDAOOpenSearchTest.java这从侧面印证了 Search DAO 抽象带来的可移植性。七、Index Builder 与搜索自动化Search AutomationIndex Builder 的角色在 docs/architecture/metadata-ingestion.md 中搜索索引构建器Search Index Builder被描述为将特定 metadata aspect 的变更翻译为搜索索引更新的关键逻辑。它与图索引构建器一起由实体无关的mae-consumer-job在 MCL 到达时按需触发职责边界非常清晰Builder 决定哪些变更、如何更新搜索索引任务job只负责按 URN 顺序串行执行 builder。从当前仓库源码看索引的物理构建与版本管理实现在 ESIndexBuilder.java它负责 Elasticsearch 索引的创建、mapping 设置与版本化管理是独立索引 版本切换落地的关键一环。搜索自动化的目标TBD原文档中搜索自动化Search Automation被标注为TBD待实现其愿景是自动化索引创建、schema 演进与 reindexing让团队只需聚焦于搜索文档模型与自定义 Index Builder 逻辑。具体来说期望的自动化流程包括自动创建索引当新增搜索文档模型或实体类型时无需手工执行索引创建脚本自动 schema 演进模型变化后自动推导并应用新版本的索引 mapping自动 reindexing当构建逻辑变化时自动创建新版本索引并从历史 MAE 事件流回放数据将其填充完整配置切换索引填充完毕后团队通过 GMS 的一次简单配置变更切换到新版本索引随时回滚任何时刻都可以回滚到旧版本索引。结合前文已经落地的机制独立索引、版本化、部分更新、mae-consumer-job 消费事件流重建可以推断搜索自动化的积木——事件驱动重建基于历史 MAE 回放与配置化版本切换——在架构上已经具备TBD 部分主要是将索引创建、schema 演进与 reindexing 的编排过程产品化、自动化。八、与周边文档的衔接搜索索引在 DataHub 文档体系中并非孤岛它与以下主题紧密关联搜索文档Search Document索引中文档的 PDL 模型即索引里存什么元数据模型Metadata Model实体与 aspect 的定义方式即字段值从哪来GMS承载配置切换的元数据服务即切索引的操作入口MCL/MAE 事件模型驱动索引更新的元数据变更事件流Metadata Serving 架构Search DAO 与查询路由的完整链路Metadata Ingestion 架构Index Builder 在摄取/消费链路中的位置。九、总结DataHub 的搜索索引机制可以概括为三句话一类一索引每个搜索文档/实体类型对应 Elasticsearch 中一个独立索引标准检索引擎能力开箱即用三特性加持部分更新让索引随元数据增量演进多值字段成员测试让过滤与分面灵活高效零停机切换让 schema 演进与回滚不再依赖停机窗口自动化在路上Index Builder 与事件流回放机制已经就位索引创建、schema 演进与 reindexing 的自动化编排Search Automation是明确的演进方向TBD。无论是二次开发自定义实体搜索还是排查搜索性能与索引状态问题都可以从搜索文档模型 → Index Builder → Search DAO → Elasticsearch 索引这条链路入手这也是本专题文档给出的最佳切入点。【免费下载链接】datahubThe Context Platform for your Data and AI Stack项目地址: https://gitcode.com/GitHub_Trending/da/datahub创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 DataHub 搜索索引（GMA Search Index）完全指南：索引映射、Search DAO 与零停机切换机制
DataHub 搜索索引GMA Search Index完全指南索引映射、Search DAO 与零停机切换机制【免费下载链接】datahubThe Context Platform for your Data and AI Stack项目地址: https://gitcode.com/GitHub_Trending/da/datahub每个搜索文档类型即实体类型都会在 Elasticsearch 中对应一个独立搜索索引DataHub 的搜索能力正是建立在这一一类一索引的映射模型之上。本文围绕 DataHub 文档体系中的搜索索引专题完整讲解其三大核心特性索引文档部分更新、多值字段成员测试、索引零停机切换、搜索文档的 PDL 建模方式、Search DAO 查询抽象以及 Index Builder 的索引构建与自动化演进路径并结合当前仓库源码给出可验证的实现依据帮助读者从模型到实现吃透 DataHub 的搜索索引机制。一、什么是 GMA 搜索索引在 DataHub 的元数据架构中每个搜索文档类型Search Document或实体类型Entity Type都会被映射到 Elasticsearch 中一个相互独立的搜索索引Search Index。这意味着索引与实体一一对应例如User实体对应一个userindexDataset实体对应另一个独立索引彼此物理隔离、互不干扰每个索引内的文档Document承载该实体的可搜索属性字段值由各类元数据 aspect 派生而来搜索请求按实体类型路由到对应的索引执行。这种设计让 DataHub 可以充分利用 Elasticsearch 提供的标准搜索引擎能力——分词器analyzer、tokenizer、过滤查询filter queries、分面faceting、分片sharding等而无需自己实现全文检索内核。在此基础上GMAGeneralized Metadata Architecture进一步支持以下三个区别于通用搜索引擎的特定能力索引文档的部分更新Partial update of indexed documents——修改某个元数据 aspect 后无需重建整个文档只需更新索引文档中对应的字段多值字段的成员测试Membership testing on multi-value fields——可以对数组类型的字段执行是否包含某成员的查询例如哪些文档包含标签 X索引之间的零停机切换Zero downtime switch between indices——可以同时维护新旧两个版本索引切换时业务无感知。这三个特性正是 DataHub 搜索索引设计的核心骨架后文将逐一展开其原理与实现。二、为什么需要独立的搜索文档模型要理解搜索索引先要理解它的输入——搜索文档Search Document。在 DataHub 中搜索文档同样使用 PDLPegasus Data Language显式建模其模型在很多方面与实体和关系模型相似每个属性/字段的值都由各种元数据 aspect 派生而来。但搜索文档有一个关键差异它允许拥有只包含原始类型primitive或枚举enum成员的数组类型属性。这是因为绝大多数全文检索引擎都支持针对数组字段做成员测试——例如一个文档中所有词项的数组字段这在全文检索场景下极其常用。字段的核心用途有二搜索过滤filtering例如找出所有姓或名与 Joe 相似、且向userFoo汇报的User搜索摘要snippet格式化由于搜索文档本身是搜索 API 的主要返回接口其属性可以直接用来格式化搜索结果的摘要展示。也正因如此设计者可能会倾向于添加尽可能多的属性。文档明确表示这是可接受的——底层检索引擎本身就被设计为支持海量字段的索引。搜索文档的 PDL 建模示例以下示例展示User搜索文档的 schema取自 docs/what/search-document.md其中有几个值得注意的设计约定每个搜索文档必须包含一个类型特定的urn字段一般映射到元数据图中的一个实体与Entity类似每个文档包含可选的removed字段用于软删除与Entity类似其余字段全部设为optional以支持部分更新management展示了字符串数组字段的写法ownedDatasets展示了如何从其他实体类型此例为Dataset关联的元数据 aspects 派生字段。首先是一个公共基类BaseDocument存放所有文档通用的字段namespace com.linkedin.metadata.search /** * Common fields that may apply to all documents */ record BaseDocument { /** Whether the entity has been removed or not */ removed: optional boolean false }然后是具体的UserDocumentnamespace com.linkedin.metadata.search import com.linkedin.common.CorpuserUrn import com.linkedin.common.DatasetUrn /** * Data model for user entity search */ record UserDocument includes BaseDocument { /** Urn for the user */ urn: CorpuserUrn /** First name of the user */ firstName: optional string /** Last name of the user */ lastName: optional string /** The chain of management all the way to CEO */ management: optional array[CorpuserUrn] [] /** Code for the cost center */ costCenter: optional int /** The list of dataset the user owns */ ownedDatasets: optional array[DatasetUrn] [] }可以看到urn是必填字段作为文档主键通常与图索引graph中的实体 URN 一一对应management、ownedDatasets这类array[...]字段正是第一节提到的多值字段成员测试的载体——Elasticsearch 天然支持对数组字段做 term 查询与过滤所有业务字段均声明为optional这为部分更新提供了模型层面的前提更新一个字段时不需要同时提供其余字段。三、核心特性一索引文档的部分更新传统做法中当某实体的元数据变化时通常需要删除旧文档并用新文档整体重建。DataHub 的搜索索引则支持对已索引文档进行部分更新只更新发生变化的字段其余字段保持不变。这一能力与搜索文档模型中所有字段均可选optional的设计相辅相成。从架构链路看元数据变更被提交为 Metadata Change ProposalMCP由 mce-consumer-job 消费并写入 DataHub Metadata Service服务端成功提交后通过 Kafka 发出Metadata Change LogMCL事件由另一个 Spring 任务 mae-consumer-job 消费 MCL调用对应的搜索索引构建器Search Index Builder把变更应用到搜索索引同时也会更新图索引。在 docs/architecture/metadata-serving.md 中明确说明mae-consumer-job是实体无关entity-agnostic的它会执行对应的 graph 与 search index builders当某个具体 metadata aspect 发生变化时builder 会告诉任务如何基于该变更去更新图与搜索索引。为了保证元数据变更按正确的时序处理MCL 会以实体 URN 为 key 进行分区——这意味着同一个实体产生的所有变更事件会由同一线程串行处理从而避免并发乱序导致的索引状态错乱。部分更新的落地点在 metadata-io 模块 的 Elasticsearch 数据访问层Search DAO 的实现索引文档的写入与更新均经由该层封装执行。四、核心特性二多值字段的成员测试正如搜索文档模型所强调的数组字段只含 primitive 或 enum 成员是搜索文档的特权结构而支撑它的正是检索引擎对数组字段的原生支持成员测试例如某文档是否包含标签PII在索引中体现为对数组字段的 term 过滤分面统计多值字段可以方便地做 faceting例如按标签、按平台统计各维度的文档数量词项索引全文检索场景下一个文档的全部词项构成数组字段用于相关性匹配。这种能力让 DataHub 的搜索过滤表达式可以直接落在多值字段上例如第一节中找出姓或名与 Joe 相似且向userFoo汇报的 User这类组合查询就同时用到了单值字段的相似匹配与多值字段management的成员测试。从源码看该能力由 ESSearchDAO.java 将 GMA 的查询模型翻译为 Elasticsearch 查询 DSL多值字段被映射为 ES 中的数组字段并参与过滤与聚合对应的行为在 SearchDAOElasticSearchTest.java 等测试中有系统验证。五、核心特性三索引之间的零停机切换当索引 schema 演进或构建逻辑发生变化时DataHub 并不要求直接原地修改正在服务的索引而是支持双索引并行 原子切换的机制保证搜索服务零停机当构建逻辑Index Builder变化时创建一个新版本的索引新索引从历史 MAEMetadata Audit Event即历史元数据变更事件流中回放、重建并逐步填充完整待新索引完全就绪后通过 GMS 侧的一次简单配置变更将查询流量切到新版本索引如果新版本出现问题可以随时回滚rollback到旧版本索引。这种版本化索引 配置切换的设计把 schema 演进与 reindexing 从夜间停机窗口式的运维操作变成了可随时执行、可随时撤销的日常操作也是搜索自动化愿景的核心支撑详见第七节。六、Search DAO搜索查询的抽象层GMA 将搜索查询抽象为Search DAOSearch Data Access Object把上层搜索逻辑与底层检索引擎实现解耦。在 docs/architecture/metadata-serving.md 中Search DAO 被定位为 GMA 搜索查询的核心抽象主键读取基于主键例如按dataset-urn读取 schema 元数据的读取路由到文档存储如 MySQL、Postgres、Cassandra 等 RDBMS 文档库二级索引读取基于二级索引的读取路由到搜索索引全文与高级搜索路由到搜索索引复杂图查询如血缘 lineage路由到图索引。也就是说搜索索引不仅承载全文检索还承担了二级索引的职责与主存储共同组成 Metadata Query Serving 的完整路径。在实现层面Elasticsearch 的实现位于 ESSearchDAO.java它负责将 GMA 的查询请求翻译成 Elasticsearch 查询 DSL 并执行对应的查询抽象测试见 SearchDAOTestBase.javaElasticsearch 与 OpenSearch 两个实现各有独立的测试类SearchDAOElasticSearchTest.java 与 SearchDAOOpenSearchTest.java这从侧面印证了 Search DAO 抽象带来的可移植性。七、Index Builder 与搜索自动化Search AutomationIndex Builder 的角色在 docs/architecture/metadata-ingestion.md 中搜索索引构建器Search Index Builder被描述为将特定 metadata aspect 的变更翻译为搜索索引更新的关键逻辑。它与图索引构建器一起由实体无关的mae-consumer-job在 MCL 到达时按需触发职责边界非常清晰Builder 决定哪些变更、如何更新搜索索引任务job只负责按 URN 顺序串行执行 builder。从当前仓库源码看索引的物理构建与版本管理实现在 ESIndexBuilder.java它负责 Elasticsearch 索引的创建、mapping 设置与版本化管理是独立索引 版本切换落地的关键一环。搜索自动化的目标TBD原文档中搜索自动化Search Automation被标注为TBD待实现其愿景是自动化索引创建、schema 演进与 reindexing让团队只需聚焦于搜索文档模型与自定义 Index Builder 逻辑。具体来说期望的自动化流程包括自动创建索引当新增搜索文档模型或实体类型时无需手工执行索引创建脚本自动 schema 演进模型变化后自动推导并应用新版本的索引 mapping自动 reindexing当构建逻辑变化时自动创建新版本索引并从历史 MAE 事件流回放数据将其填充完整配置切换索引填充完毕后团队通过 GMS 的一次简单配置变更切换到新版本索引随时回滚任何时刻都可以回滚到旧版本索引。结合前文已经落地的机制独立索引、版本化、部分更新、mae-consumer-job 消费事件流重建可以推断搜索自动化的积木——事件驱动重建基于历史 MAE 回放与配置化版本切换——在架构上已经具备TBD 部分主要是将索引创建、schema 演进与 reindexing 的编排过程产品化、自动化。八、与周边文档的衔接搜索索引在 DataHub 文档体系中并非孤岛它与以下主题紧密关联搜索文档Search Document索引中文档的 PDL 模型即索引里存什么元数据模型Metadata Model实体与 aspect 的定义方式即字段值从哪来GMS承载配置切换的元数据服务即切索引的操作入口MCL/MAE 事件模型驱动索引更新的元数据变更事件流Metadata Serving 架构Search DAO 与查询路由的完整链路Metadata Ingestion 架构Index Builder 在摄取/消费链路中的位置。九、总结DataHub 的搜索索引机制可以概括为三句话一类一索引每个搜索文档/实体类型对应 Elasticsearch 中一个独立索引标准检索引擎能力开箱即用三特性加持部分更新让索引随元数据增量演进多值字段成员测试让过滤与分面灵活高效零停机切换让 schema 演进与回滚不再依赖停机窗口自动化在路上Index Builder 与事件流回放机制已经就位索引创建、schema 演进与 reindexing 的自动化编排Search Automation是明确的演进方向TBD。无论是二次开发自定义实体搜索还是排查搜索性能与索引状态问题都可以从搜索文档模型 → Index Builder → Search DAO → Elasticsearch 索引这条链路入手这也是本专题文档给出的最佳切入点。【免费下载链接】datahubThe Context Platform for your Data and AI Stack项目地址: https://gitcode.com/GitHub_Trending/da/datahub创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考