DataHub 搜索指南：从搜索栏、高级查询到 Elasticsearch 自定义搜索配置的完整实践

DataHub 搜索指南：从搜索栏、高级查询到 Elasticsearch 自定义搜索配置的完整实践

【免费下载链接】datahubThe Context Platform for your Data and AI Stack项目地址: https://gitcode.com/GitHub_Trending/da/datahub

DataHub 的搜索能力是发现数据资产的核心入口，本指南以官方文档 docs/how/search.md 为主线，系统讲解搜索栏用法、过滤器与高级查询语法，并深入剖析基于 YAML 的 Elasticsearch 自定义搜索配置（排名、过滤、字段配置）以及 GraphQL 编程式搜索接口。读完本文，你将掌握 DataHub 搜索的全部使用姿势，并能通过修改search_config.yml定制符合自己团队需求的搜索体验。

搜索入口与基本机制

DataHub 的搜索栏是发现数据资产的最重要机制。在搜索栏中，你可以检索到 Datasets、Columns（列）、Dashboards（仪表盘）、Charts（图表）、Data Pipelines（数据管道）等各类实体，只需输入业务关键词并按回车即可。

搜索对所有用户开放，无需额外授权即可使用。虽然开箱即用，但搜索效果高度依赖元数据的丰富程度——摄入（ingest）的相关数据越多、元数据质量越高，搜索结果越准确。默认情况下，搜索词会匹配数据资产的多个维度，包括：

• 资产名称（asset names）
• 描述（descriptions）
• 标签（tags）
• 术语（glossary terms）
• 所有者（owners）
• 特定属性，如表中列的名称（field paths / column names）

关于如何通过 metadata ingestion 提升元数据质量，可参考 metadata-ingestion 框架指南。

搜索操作符：默认 AND 布尔逻辑

搜索框对文本的默认布尔逻辑是AND。例如，输入information about orders，实际会被解释为：

information AND about AND orders

这意味着返回结果必须同时命中这三个词。若想精确控制多个词的组合关系，可配合下文的高级查询语法（如+、-、|、()）进一步调整。

过滤器：左侧筛选栏与高级过滤

基础 Filters

搜索结果页左侧的**过滤器侧栏（filter sidebar）**支持通过逐层钻取（drill down）缩小结果范围。你可以一键按以下维度过滤：

• Data Platform（如 Snowflake、Hive、Kafka 等）
• Tags（标签）
• Glossary Terms（术语）
• Domain（数据域）
• Owners（所有者）
• 以及其他更多维度

Advanced Filters 高级过滤器

点击过滤面板右上角的Advanced即可进入高级过滤视图。当前高级过滤器支持以下过滤类型：

添加高级过滤器：点击 add filter 菜单，选择过滤器类型，再填入要过滤的取值即可。

匹配模式（all filters / any filter）：默认情况下所有过滤器必须同时满足才会返回结果。例如同时添加 tag 过滤和 platform 过滤时，结果必须同时拥有该标签且属于该平台。点击过滤器旁的all filters下拉框并选择any filter，即可切换为"命中任一过滤器即返回"的模式。

否定过滤器（Negating）：创建过滤器后，可以点击过滤器右上角的操作符，选择否定（negated）操作，使结果不匹配该条件。

结果排序逻辑

搜索结果按**相关度（relevance）**排序：

• 在 **DataHub Core（开源版）**中，排序基于查询与资产文本字段及其元数据的匹配紧密程度（本质是 Elasticsearch 的文本匹配得分）。
• 在DataHub Cloud中，排序综合了文本相关性、使用情况（查询数 / 浏览数）以及变更频率。

可见元数据质量直接影响搜索结果：元数据越完善，相关度计算越精准。

高级查询（Advanced Queries）：/q语法实战

搜索栏支持带模式匹配、逻辑表达式和指定字段匹配的高级查询。这类查询以/q前缀开头，可直接对 Elasticsearch 中的索引字段进行检索。以下用例以 Dataset 为参考实体，且列表并非穷尽。

精确匹配短语

/q "pet profile"

用双引号包围一个或多个词会强制这些词精确匹配，阻止进一步分词（tokenization）。不带引号时则按普通分词匹配。

排除词项

/q logging -snowflake

用-前缀否定某个词，结果中排除包含该词的资产。

带优先级的布尔表达式

/q logging + (-snowflake | os_audit_log)

()用于设置布尔词表达式的优先级，+表示必须包含，|表示或。

按名称字段查找

/q name: *mask*

返回名称中包含mask的实体。名称通常由其他符号连接（如下划线、连字符），因此通常需要在词的前后都加通配符*。

按自定义属性（customProperties）查找

/q customProperties: encoding*

Dataset 的属性以key=value的形式索引到 Elasticsearch。如果知道精确的键值对，可以直接搜索"key=value"；如果只记得键名，可以用通配符替代值，如上例。

按非版本化（unversioned）结构化属性查找

/q structuredProperties.io_acryl_privacy_retentionTime01:60

返回非版本化结构化属性（qualified name 为io.acryl.private.retentionTime01）取值为60的实体。

/q _exists_:structuredProperties.io_acryl_privacy_retentionTime01

_exists_用于判断字段是否存在，此查询返回任何对该结构化属性有任意取值的实体。

按版本化（versioned）结构化属性查找

/q structuredProperties._versioned.io_acryl_privacy_retentionTime.20240614080000.number:365

该查询返回结构化属性 qualified name 为io.acryl.privacy.retentionTime、版本号为20240614080000、类型为number、取值为365的实体。

/q _exists_:structuredProperties._versioned.io_acryl_privacy_retentionTime.20240614080000.number

返回该版本化属性（特定版本与类型）有取值的实体。

/q structuredProperties._versioned.io_acryl_privacy_retentionTime.\*.\*:365

通配符\*可匹配任意版本和类型，此查询返回该属性任意版本、任意类型下取值为365的实体。

按列名（fieldPaths）查找

/q fieldPaths: latitude

fieldPaths是 Dataset 中存放列名的属性。

/q fieldPaths: *latitude

带前缀通配符可覆盖使用 V2 fieldPaths 格式的列，例如[version=2.0].[type=string].latitude。

按字段描述查找

/q editedFieldDescriptions: latitude OR fieldDescriptions: latitude

Dataset 有两个属性存放字段描述：fieldDescriptions来自SchemaMetadataaspect（摄入来源），editedFieldDescriptions来自EditableSchemaMetadataaspect（UI 编辑来源），因此需要同时检索两个属性。

按数据集描述查找

/q editedDescription: *logical* OR description: *logical*

与字段描述同理，数据集描述也存在于两个 aspect 中（摄入的description与 UI 编辑的editedDescription），需要分别检索。

按浏览路径（browsePaths）查找

/q browsePaths: *hive*

BrowsePath 以完整字符串存储，例如/datasets/prod/hive/SampleKafkaDataset，因此需要在词的两端都加通配符才能命中。

查找缺失字段的实体

/q -_exists_:name

-与_exists_组合，返回没有name字段的实体。

按上游血缘是否存在过滤

/q hasUpstreams:true /q hasFineGrainedUpstreams:true

这两个过滤器从 DataHub Cloud 的0.3.13.x版本开始支持。注意：它只判断相关 aspect 的元数据是否被发送过，并不校验上游 URN 是否有效。目前没有对应的下游血缘过滤器，且仅适用于dataset实体。

按使用情况（usage）过滤

/q hasUniqueUserCount:true /q hasTotalSqlQueriesCount:true

这两个过滤器从 DataHub Cloud0.3.14.x版本开始支持。同样地，它只检查元数据是否被发送过，不检查数值是否为零。

按血缘数量（1 hop）过滤

/q upstreamCountFeature:>2 # 1 跳内上游数量大于 2 /q downstreamCountFeature:<3 # 1 跳内下游数量小于 3 /q upstreamCountFeature:<=10 # 1 跳内上游数量小于等于 10 /q upstreamCountFeature:[5 TO *] # 1 跳内上游数量大于等于 5

upstreamCountFeature/downstreamCountFeature的优势在于会校验上游/下游 URN 是否有效（区别于hasUpstreams）；劣势是这些计数每天更新一次，并非像hasUpstreams那样实时。由于血缘一旦写入后对大多数表而言变化不大，该信息对几乎所有表都接近实时，仅有约 24 小时的滞后。这两个过滤器同样从 DataHub Cloud0.3.14.x起支持，且是DataHub Cloud 专属过滤器。

编程式搜索：GraphQL API

驱动 DataHub 搜索 UI 的同一套 GraphQL API 也可用于集成与编程式调用。你可以在 GMS 的 GraphQL 端点（如/api/graphiql）上在线试验。

基础搜索：search

以下示例搜索匹配example_query_text、schema 字段上带有Dimension标签、且来自 looker 数据平台的 Dataset：

# Example query - search for datasets matching the example_query_text who have the Dimension tag applied to a schema field and are from the data platform looker query searchEntities { search( input: { type: DATASET, query: "example_query_text", orFilters: [ { and: [ { field: "fieldTags", values: ["urn:li:tag:Dimension"] }, { field: "platform", values: ["urn:li:dataPlatform:looker"] } ] } ], start: 0, count: 10 } ) { start count total searchResults { entity { urn type ... on Dataset { name platform { name } } } } } }

其中orFilters与and的组合对应 UI 中的过滤逻辑：同一组and内的条件需同时满足，多个orFilters之间为或关系。

大规模搜索：scrollAcrossEntities游标分页

对于返回实体数超过 1 万的查询，官方推荐使用scrollAcrossEntitiesGraphQL API 进行游标式分页：

# Example query { scrollAcrossEntities(input: { types: [DATASET], query: "*", count: 10}) { nextScrollId count searchResults { entity { type ... on Dataset { urn type platform { name } name } } } } }

响应中的nextScrollId必须用于后续请求以获取更多数据：

{ scrollAcrossEntities(input: { types: [DATASET], query: "*", count: 10, scrollId: "eyJzb3J0IjpbMy4wLCJ1cm46bGk6ZGF0YXNldDoodXJuOmxpOmRhdGFQbGF0Zm9ybTpiaWdxdWVyeSxiaWdxdWVyeS1wdWJsaWMtZGF0YS5jb3ZpZDE5X2dlb3RhYl9tb2JpbGl0eV9pbXBhY3QucG9ydF90cmFmZmljLFBST0QpIl0sInBpdElkIjpudWxsLCJleHBpcmF0aW9uVGltZSI6MH0="} ) { nextScrollId count searchResults { entity { type ... on Dataset { urn type platform { name } name } } } } }

重复以上过程，逐批取数，直到返回的nextScrollId为 null 或 undefined，即完成全量遍历。

默认搜索实体类型配置

当 GraphQL 调用方省略types参数时（search、autocomplete、browse V2 及相关 resolver），GMS 会使用application.yaml中elasticsearch.search下可配置的默认实体类型列表。各配置键、对应环境变量及用途如下：

每个列表都支持value/add/remove三种操作（以及对应的*_ADD/*_REMOVE环境变量）。需要注意的语义细节：

• 未设置环境变量时，沿用 YAML 中的默认值；
• 解析后若列表显式为空，则 GraphQL 搜索不会扩展到所有索引，而是不搜索任何实体类型；
• GraphQL 请求上显式传入的非空types始终优先生效；
• 未知的 registry 名称会在启动时以 warn 日志被软丢弃（soft-dropped）。

该配置在源码中由 EntityTypeListConfig 与 SearchConfiguration 建模。完整的环境变量参考见 docs/deploy/environment-vars.md。

自定义搜索：基于 YAML 的 Elasticsearch 定制

DataHub 支持通过一个搜索配置 YAML 文件完全自定义搜索的排名、过滤与查询。这是一种 no-code 方案，用于扩展或替换基于 Elasticsearch 的默认搜索逻辑。唯一限制是：查询/排名/过滤中使用的信息必须存在于实体的文档（index document）中——不过这不构成实际障碍，因为文档中已包含customProperties、tags、terms、domain以及大量其他字段。

多条自定义规则可以作用于不同的查询字符串：系统对搜索查询应用**正则表达式（regex）**来确定使用哪份自定义配置。这意味着可以对"全选"查询（*或空）与真实查询分别应用不同的查询/排名/过滤逻辑。

排名调优的核心原则：搜索结果是相关性（relevancy）与打分函数（scoring function）之间的平衡。通常，提升相关性应重点修改boolQuery部分；而functionScore用于在相关性打平时"抬升"重要性。例如名为orders的数据集在多个位置存在，它们在名称orders上的相关性相同，但某个位置可能更重要、应获得更高的 function score。

重要提示：自定义查询是透传给 Elasticsearch 的，必须符合其 API 规范，存在语法错误风险。生产环境部署前建议先充分测试，且需要具备 Elasticsearch 查询语言知识。

启用自定义搜索

以下 GMS 环境变量控制搜索配置是否启用以及配置文件的位置：

ELASTICSEARCH_QUERY_CUSTOM_CONFIG_ENABLED=true ELASTICSEARCH_QUERY_CUSTOM_CONFIG_FILE=search_config.yml

配置文件可以位于 Java classpath 或本地文件系统。GMS jar 中自带一份默认配置文件search_config.yml。

搜索配置结构

搜索配置 YAML 是一个配置 profile 的列表，通过queryRegex选择生效的 profile；如果只需要单一配置，可以用全匹配的正则.*。整体分为 4 大部分：

1. queryRegex— 根据匹配搜索查询字符串的正则来选择自定义配置（Java 正则语义），第一个匹配生效。
2. 内置查询开关— 有 3 个内置查询可单独启停：simple query string（simpleQuery）、match phrase prefix（prefixMatchQuery）、exact match（exactMatchQuery）。启用后它们会进入boolQuery的should子句。
3. boolQuery— Elasticsearchboolean query的基座，是调整相关性的主要区域。
4. functionScore— 整体查询中的 Elasticsearchfunction score部分，用于调整重要性。

此外，在配置文件中的 boolQuery / functionScore 内部，可以使用{{query_string}}（原始查询串）与{{unquoted_query_string}}（去除引号后的查询串）占位符。实现上，CustomizedQueryHandler 会把配置中的 JSON 片段内的"{{query_string}}"替换为实际查询字符串，再交由 OpenSearch/Elasticsearch 的 XContentParser 构建 BoolQueryBuilder 与 FunctionScoreQueryBuilder，见 toBoolQueryBuilder 与 toFunctionScoreQueryBuilder。

配置文件中的 YAML 结构对应 CustomSearchConfiguration（包含fieldConfigurations、queryConfigurations、autocompleteConfigurations三部分）。单个查询配置的字段由 QueryConfiguration 定义，除文档列出的开关外，还包含structuredQuery布尔项（控制结构化查询逻辑是否在 fullText 标记为 false 时生效）。

示例 1：按标签/术语排名

提升带有primary或gold标签，以及某个示例术语 UUID 的实体的排名（OR 关系）：

queryConfigurations: - queryRegex: .* simpleQuery: true prefixMatchQuery: true exactMatchQuery: true functionScore: functions: - filter: terms: tags.keyword: - urn:li:tag:primary - urn:li:tag:gold weight: 3.0 - filter: terms: glossaryTerms.keyword: - urn:li:glossaryTerm:9afa9a59-93b2-47cb-9094-aa342eec24ad weight: 3.0 score_mode: multiply boost_mode: multiply

如需"同时具备primary且gold"（AND 关系），改用 bool filter：

queryConfigurations: - queryRegex: .* simpleQuery: true prefixMatchQuery: true exactMatchQuery: true functionScore: functions: - filter: bool: filter: - term: tags.keyword: urn:li:tag:primary - term: tags.keyword: urn:li:tag:gold weight: 3.0 score_mode: multiply boost_mode: multiply

示例 2：优先数据平台

提升urn:li:dataPlatform:hive平台的实体：

queryConfigurations: - queryRegex: .* simpleQuery: true prefixMatchQuery: true exactMatchQuery: true functionScore: functions: - filter: terms: platform.keyword: - urn:li:dataPlatform:hive weight: 3.0 score_mode: multiply boost_mode: multiply

示例 3：排除与降权

在 3 个内置查询的基础上，用must_not排除deprecated（已废弃）实体，同时降低materialized（已物化）实体的得分：

queryConfigurations: - queryRegex: .* simpleQuery: true prefixMatchQuery: true exactMatchQuery: true boolQuery: must_not: term: deprecated: value: true functionScore: functions: - filter: term: materialized: value: true weight: 0.5 score_mode: multiply boost_mode: multiply

示例 4：实体类型排名

调整不同实体类型的相对排名。例如希望 dashboard 出现在 chart 之上，可以通过对 URN 的前缀匹配来实现。由于不同实体往往命中多个字段，权重可能需要根据你的数据和实体情况反复调整：

queryConfigurations: - queryRegex: .* simpleQuery: true prefixMatchQuery: true exactMatchQuery: true functionScore: functions: - filter: prefix: urn: value: "urn:li:dashboard:" weight: 1.5 score_mode: multiply boost_mode: multiply

仓库自带的测试配置 search_config_test.yml 展示了更完整的写法：它针对*/空查询（select-all）关闭了全部内置查询、仅做降权打分；对普通查询则开启 3 个内置查询并叠加must字段匹配与 function score，且展示了match_all、materialized、deprecated的组合用法，可作为自定义配置的起点模板。

搜索自动补全（Autocomplete）配置

自动补全的配置选项与搜索配置大体一致，但位于 YAML 中的autocompleteConfigurations下。默认情况下，自动补全会继承上一节搜索配置中定义的打分函数，除非在 autocomplete 段提供了覆盖项。

autocompleteConfigurations结构要点：

1. queryRegex— 根据匹配查询串的正则选择配置，第一个匹配生效。
2. inheritFunctionScore— 布尔开关，控制是否继承普通搜索配置的 function score。注意：一旦提供了functionScore段，该标志会自动被置为false；如果显式设为false且未提供functionScore，则使用 Elasticsearch 默认的_score。
3. 内置查询开关— autocomplete 有 1 个内置查询defaultQuery（默认自动补全查询）可启停。
4. boolQuery— 基础 boolean query，启用内置查询后其出现在should子句。
5. functionScore— 整体查询的 function score 部分。

对应的 Java 模型见 AutocompleteConfiguration，其中inheritFunctionScore与defaultQuery的默认值均为true。

注意：queryRegex对queryConfigurations与autocompleteConfigurations是分别独立应用的，两者不必相同。

示例 1：从自动补全中排除deprecated实体

autocompleteConfigurations: - queryRegex: .* defaultQuery: true boolQuery: must: - term: deprecated: "false"

示例 2：覆盖自动补全的打分

autocompleteConfigurations: - queryRegex: .* defaultQuery: true functionScore: functions: - filter: term: materialized: value: true weight: 1.1 - filter: term: deprecated: value: false weight: 0.5 score_mode: avg boost_mode: multiply

字段配置（Field Configurations）

字段配置允许你自定义哪些字段参与搜索查询以及结果高亮（highlight）。每个配置通过一个 label 标识，并可用三种操作修改默认行为：

• add— 在系统默认字段基础上追加字段
• remove— 从系统默认字段中移除字段
• replace— 完全替换系统默认字段列表

注意：replace操作不能与add/remove组合使用；但add与remove可以同时使用。目前 UI 只使用default这个 label，但对 GraphQL 的调用可以指定其他 label（详见 GraphQL 文档中的searchFlags.fieldConfiguration）。

在源码中，CustomizedQueryHandler.applySearchFieldConfiguration 负责将字段配置应用到搜索结果字段集：它会先校验配置合法性（replace与add/remove互斥，见 SearchFields.isValid），再按 replace 或 add/remove 两种模式处理；仅处理实际存在的可搜索字段，不存在的字段会被忽略并记录 warn 日志。高亮字段的处理逻辑类似，见 applyHighlightFieldConfiguration 与 isHighlightingEnabled。

searchFlags.fieldConfiguration与默认 label 的解析顺序由 resolveFieldConfiguration 实现：若 GraphQL 请求的searchFlags未指定fieldConfiguration，则回落到配置中的默认 label。

字段配置完整示例

fieldConfigurations: # Default configuration - if searchFlags doesn't specify default: searchFields: remove: - fieldPaths highlightFields: enabled: true remove: - fieldPaths # PDL legacy configuration legacy: searchFields: # No modifications - use PDL defaults highlightFields: enabled: true # No modifications - use PDL defaults # Configuration for technical users - adds technical fields technical: searchFields: add: - fieldPaths - platform remove: - customProperties highlightFields: enabled: true add: - fieldPaths - platform # Configuration for business users - simplified field set business: searchFields: replace: - name - description - tags - glossaryTerms highlightFields: enabled: true replace: - name - description # Configuration with no highlighting no-highlight: searchFields: # Uses system defaults highlightFields: enabled: false

此示例展示了 5 种典型用法：default移除列名字段；legacy完全使用 PDL 默认值；technical面向技术用户追加技术字段；business面向业务用户将字段集精简为名称、描述、标签、术语；no-highlight则彻底关闭高亮。

常见问题与排障

结果是如何排序的？

搜索结果的顺序取决于 DataHub 根据其搜索算法赋予的权重。当前 OSS DataHub 的算法基于 Elasticsearch 的文本匹配得分。

如何确认各实体的可搜索字段？

高级查询示例中的字段并非穷尽。要查看 DataHub 中每个实体当前被索引的字段清单，可以查看每个实体上带有Searchable标签的字段（在 demo 实例中通过Searchable标签页浏览）。不过它不会告诉你用于专项搜索的具体属性名。一个直接的办法是检查 Elasticsearch 索引：

curl http://localhost:9200/_cat/indices

该命令返回 Elasticsearch 容器中的全部索引。索引名因实例而异，典型的输出如下（片段）：

yellow open chartindex_v2_1643510690325 bQO_RSiCSUiKJYsmJClsew 1 1 2 0 8.5kb 8.5kb yellow open mlmodelgroupindex_v2_1643510678529 OjIy0wb7RyKqLz3uTENRHQ 1 1 0 0 208b 208b yellow open dataprocessindex_v2_1643510676831 2w-IHpuiTUCs6e6gumpYHA 1 1 0 0 208b 208b yellow open corpgroupindex_v2_1643510673894 O7myCFlqQWKNtgsldzBS6g 1 1 3 0 16.8kb 16.8kb yellow open corpuserindex_v2_1643510672335 0rIe_uIQTjme5Wy61MFbaw 1 1 6 2 32.4kb 32.4kb yellow open datasetindex_v2_1643510688970 bjBfUEswSoSqPi3BP4iqjw 1 1 15 0 29.2kb 29.2kb yellow open dataflowindex_v2_1643510681607 N8CMlRFvQ42rnYMVDaQJ2g 1 1 1 0 10.2kb 10.2kb yellow open dataset_datasetusagestatisticsaspect_v1_1643510694706 kdqvqMYLRWq1oZt1pcAsXQ 1 1 4 0 8.9kb 8.9kb yellow open .ds-datahub_usage_event-000003 YMVcU8sHTFilUwyI4CWJJg 1 1 186 0 203.9kb 203.9kb yellow open datajob_datahubingestioncheckpointaspect_v1 nTXJf7C1Q3GoaIJ71gONxw 1 1 0 0 208b 208b yellow open dataplatformindex_v2_1643510671426 _4SIIhfATy8q_WROufunXA 1 1 0 0 208b 208b yellow open mlmodeldeploymentindex_v2_1643510670629 n81eJIypSp2Qx-fpjZHgRw 1 1 0 0 208b 208b yellow open mlfeaturetableindex_v2_1643510677164 iEXPt637S1OcilXpxPNYHw 1 1 5 0 8.9kb 8.9kb yellow open mlprimarykeyindex_v2_1643510687579 MUcmT8ASSASzEpLL98vrWg 1 1 7 0 9.5kb 9.5kb yellow open glossarytermindex_v2_1643510686127 cQL8Pg6uQeKfMly9GPhgFQ 1 1 3 0 10kb 10kb yellow open mlmodelindex_v2_1643510675399 gk-WSTVjRZmkDU5ggeFSqg 1 1 1 0 10.3kb 10.3kb yellow open dashboardindex_v2_1643510691686 PQjSaGhTRqWW6zYjcqXo6Q 1 1 1 0 8.7kb 8.7kb yellow open datahubpolicyindex_v2_1643510671774 ZyTrYx3-Q1e-7dYq1kn5Gg 1 1 0 0 208b 208b yellow open datajobindex_v2_1643510682977 K-rbEyjBS6ew5uOQQS4sPw 1 1 2 0 11.3kb 11.3kb yellow open schemafieldindex_v2_1643510684410 tZ1gC3haTReRLmpCxirVxQ 1 1 0 0 208b 208b yellow open mlfeatureindex_v2_1643510680246 aQO5HF0mT62Znn-oIWBC8A 1 1 20 0 17.4kb 17.4kb yellow open tagindex_v2_1643510684785 PfnUdCUORY2fnF3I3W7HwA 1 1 3 1 18.6kb 18.6kb

其中datasetindex_v2_*存放 Dataset 的索引信息，可进一步检索具体文档：

curl http://localhost:9200/datasetindex_v2_1643510688970/_search?pretty

单个 Dataset 文档示例（节选）展示了可供高级查询使用的索引字段结构：

{ "_index" : "datasetindex_v2_1643510688970", "_type" : "_doc", "_id" : "urn%3Ali%3Adataset%3A%28urn%3Ali%3AdataPlatform%3Akafka%2CSampleKafkaDataset%2CPROD%29", "_score" : 1.0, "_source" : { "urn" : "urn:li:dataset:(urn:li:dataPlatform:kafka,SampleKafkaDataset,PROD)", "name" : "SampleKafkaDataset", "browsePaths" : [ "/prod/kafka/SampleKafkaDataset" ], "origin" : "PROD", "customProperties" : [ "prop2=pikachu", "prop1=fakeprop" ], "hasDescription" : false, "hasOwners" : true, "owners" : [ "urn:li:corpuser:jdoe", "urn:li:corpuser:datahub" ], "fieldPaths" : [ "[version=2.0].[type=boolean].field_foo_2", "[version=2.0].[type=boolean].field_bar", "[version=2.0].[key=True].[type=int].id" ], "fieldGlossaryTerms" : [ ], "fieldDescriptions" : [ "Foo field description", "Bar field description", "Id specifying which partition the message should go to" ], "fieldTags" : [ "urn:li:tag:NeedsDocumentation" ], "platform" : "urn:li:dataPlatform:kafka" } }

注意fieldPaths使用[version=2.0].[type=boolean].field_foo_2这类 V2 格式存储列路径，这与前文高级查询中fieldPaths: *latitude需要前缀通配符的原因一致；customProperties以key=value字符串数组存储，印证了customProperties: encoding*这类查询的可行性。

相关资源

• Metadata ingestion 框架：了解如何通过元数据摄入提升搜索与发现效果
• 环境变量参考：SEARCH_DEFAULT_ENTITY_TYPES等搜索相关环境变量的完整说明
• 搜索自定义配置的源码入口：SearchRequestHandler（构建自定义查询处理器）、CustomizedQueryHandler（查询/打分/字段配置核心实现）
• 自定义配置模型：CustomSearchConfiguration 及其下属的 QueryConfiguration、AutocompleteConfiguration、SearchFields
• 测试样例：search_config_test.yml（开箱即用的完整配置模板）、CustomizedQueryHandlerTest（字段配置、高亮配置、boost 保留等行为的单元测试）

【免费下载链接】datahubThe Context Platform for your Data and AI Stack项目地址: https://gitcode.com/GitHub_Trending/da/datahub