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

DataHub 搜索指南从搜索栏、高级查询到 Elasticsearch 自定义搜索配置的完整实践【免费下载链接】datahubThe Context Platform for your Data and AI Stack项目地址: https://gitcode.com/GitHub_Trending/da/datahubDataHub 的搜索能力是发现数据资产的核心入口本指南以官方文档 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即可进入高级过滤视图。当前高级过滤器支持以下过滤类型过滤维度说明Column Name列名Container容器Domain数据域Description实体级或列级描述Tag实体级或列级标签Glossary Term实体级或列级术语Owner所有者Entity Type实体类型Subtype实体子类型Environment环境如 PROD / DEVSoft-deleted status软删除状态添加高级过滤器点击 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 的属性以keyvalue的形式索引到 Elasticsearch。如果知道精确的键值对可以直接搜索keyvalue如果只记得键名可以用通配符替代值如上例。按非版本化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: latitudefieldPaths是 Dataset 中存放列名的属性。/q fieldPaths: *latitude带前缀通配符可覆盖使用 V2 fieldPaths 格式的列例如[version2.0].[typestring].latitude。按字段描述查找/q editedFieldDescriptions: latitude OR fieldDescriptions: latitudeDataset 有两个属性存放字段描述fieldDescriptions来自SchemaMetadataaspect摄入来源editedFieldDescriptions来自EditableSchemaMetadataaspectUI 编辑来源因此需要同时检索两个属性。按数据集描述查找/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 跳内上游数量大于等于 5upstreamCountFeature/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 及相关 resolverGMS 会使用application.yaml中elasticsearch.search下可配置的默认实体类型列表。各配置键、对应环境变量及用途如下配置键环境变量调用方省略types时用于defaultEntityTypesSEARCH_DEFAULT_ENTITY_TYPESSearch / scroll / aggregateautocompleteEntityTypesSEARCH_AUTOCOMPLETE_ENTITY_TYPES跨实体 AutocompletebrowseEntityTypesSEARCH_BROWSE_ENTITY_TYPESBrowse V2prioritizedSourceEntityTypesSEARCH_PRIORITIZED_SOURCE_ENTITY_TYPESSource-entity 快捷过滤器prioritizedDatahubEntityTypesSEARCH_PRIORITIZED_DATAHUB_ENTITY_TYPESDataHub-entity 快捷过滤器每个列表都支持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_ENABLEDtrue ELASTICSEARCH_QUERY_CUSTOM_CONFIG_FILEsearch_config.yml配置文件可以位于 Java classpath 或本地文件系统。GMS jar 中自带一份默认配置文件search_config.yml。搜索配置结构搜索配置 YAML 是一个配置 profile 的列表通过queryRegex选择生效的 profile如果只需要单一配置可以用全匹配的正则.*。整体分为 4 大部分queryRegex— 根据匹配搜索查询字符串的正则来选择自定义配置Java 正则语义第一个匹配生效。内置查询开关— 有 3 个内置查询可单独启停simple query stringsimpleQuery、match phrase prefixprefixMatchQuery、exact matchexactMatchQuery。启用后它们会进入boolQuery的should子句。boolQuery— Elasticsearchboolean query的基座是调整相关性的主要区域。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且goldAND 关系改用 bool filterqueryConfigurations: - 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结构要点queryRegex— 根据匹配查询串的正则选择配置第一个匹配生效。inheritFunctionScore— 布尔开关控制是否继承普通搜索配置的 function score。注意一旦提供了functionScore段该标志会自动被置为false如果显式设为false且未提供functionScore则使用 Elasticsearch 默认的_score。内置查询开关— autocomplete 有 1 个内置查询defaultQuery默认自动补全查询可启停。boolQuery— 基础 boolean query启用内置查询后其出现在should子句。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 doesnt 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 : [ prop2pikachu, prop1fakeprop ], hasDescription : false, hasOwners : true, owners : [ urn:li:corpuser:jdoe, urn:li:corpuser:datahub ], fieldPaths : [ [version2.0].[typeboolean].field_foo_2, [version2.0].[typeboolean].field_bar, [version2.0].[keyTrue].[typeint].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使用[version2.0].[typeboolean].field_foo_2这类 V2 格式存储列路径这与前文高级查询中fieldPaths: *latitude需要前缀通配符的原因一致customProperties以keyvalue字符串数组存储印证了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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考