摘要

火山引擎大数据研发治理套件 DataLeap的Data Catalog系统通过汇总和组织各种元数据，解决了数据生产者梳理数据、数据消费者找数和理解数的业务场景，其中搜索是Data Catalog的主要功能之一。本文详细介绍了火山引擎DataLeap的Data Catalog系统的搜索功能的设计与实现。

(相关资料图)

背景

Data Catalog能够帮助大公司更好地梳理和管理自己的资产，是Data-drvien公司的重要平台。一个通用的Data Catalog平台通常包含元数据管理，搜索，血缘，标签，术语等功能。其中，搜索是Data Catalog的入口功能，承担着让用户“找到数”的主要能力。在火山引擎DataLeap的Data Catalog系统中，每天有70%以上的用户会使用搜索功能。

功能要求

业界主要的Augmented Data Catalog需要支持Google一样的搜索体验来搜索数据资产，以满足不同角色的用户的找数需求。火山引擎DataLeap的Data Catalog系统也一样，搜索需要支持的主要功能包括：

支持多种不同类型资产的搜索 。目前系统中已经包含15+种数据源，可以分为几大类：数仓表比如Hive，看板，数据集，实时表，Topic，对象存储，分布式文件系统如LasFS等。带来的主要挑战是不同类型的资产，搜索的字段和权重有明显差异。 支持个性化 。目前系统的用户遍布整个公司，角色涵盖数据工程师，数据分析师，产品经理，项目经理，销售和数据科学家等等，需要完成的数据工作任务差异也比较大，比如数据开发，数据治理，BI，数据分析和机器学习等等，因此个性化对Data Catalog的搜索尤为重要。 支持各种业务元数据的高级筛选 。数据资产除了名称/别名/描述等字段，通常还会有一些业务元数据，如项目/业务域/负责人/负责人部门/标签/业务术语/生命周期状态等。通过支持指定业务元数据进行筛选，帮助用户减小搜索范围，更快搜到对应资产。 支持秒级的实时性 。这里的实时性是指元数据的变更需要在秒级别反映到Data Catalog的搜索里，例如新建表需要在操作完成后1～2秒内即能搜到相应的表，删除表需要不再显示在搜索结果中。原因是用户新建或更新资产后通常会到我们的系统上查看相应的变更是否生效。用户手动在浏览器操作搜索的时间通常是秒级，超过这个时间会给用户带来困惑，降低整个Data Catalog的使用体验。 支持Google类似的搜索推荐(Type as you search)功能 。搜索补全功能是搜索的一个导航功能，可以在用户键入内容时提示他们可以输入的相关内容，从而提高搜索精度。这个功能对响应速度有一定的要求，同时由于数据资产的特殊性，前缀相同的资产数量较多，因此也需要根据资产的热度进行一定的排序。 支持多租户 。我们的系统不仅供公司内部使用，也提供公有云服务，因此支持多租户也是搜索的一个P0需求。 支持多语言 。数据资产的名称/描述/标签/术语等需要支持多种语言，搜索的输入也可能是不同的语言，最常用的比如英文和中文。不同语言的分词，专有名词字典，文本特征等都会带来一些挑战。

个性化的综合搜索

为了满足上述需求，火山引擎DataLeap的Data Catalog的系统采用了个性化综合搜索的方案。区别于联合搜索（federated search），用户需要指定搜索的具体资产类型或在搜索结果页对不同的资产分栏显示，综合搜索（unified search）允许用户在一个搜索框中进行搜索输入而无需指定搜索的资产类型，同时，搜索服务会在同一个搜索结果页返回不同类型的相关资产，并根据匹配程度和用户的个性化数据进行混合排序。优势是能给不同的用户针对不同资产的搜索需求提供统一的搜索体验，同时提供了用户跨类型圈定资产的能力。另外，综合搜索使得我们可以在页面上进行标准化透出，从而我们可以从技术上进行搜索标准化，达到新数据源接入即可搜索。

架构

整体架构

火山引擎DataLeap的Data Catalog的搜索系统使用了开源的搜索引擎Elasticsearch进行基础的文档检索（Recall阶段），因此各种资产元数据会被存放到Elasticsearch中。整个系统包括4个主要的数据流程：

实时导入 。资产元数据变更时相应的平台发出实时变更消息，Data Catalog系统会消费变更消息，通过ingestion服务更新Elasticsearch中的文档，以此来达到搜索实时性秒级的需求。 离线导入 。实时导入的过程中可能会遇到网络波动等不可控因素导致更新失败，因此需要定时的任务来检查和增量更新缺失的元数据。 用户行为记录 。记录用户搜索点击日志，用来后续进行搜索的Badcase review和模型训练。这部分采用了前端埋点和服务端埋点结合的方式。前端埋点有成熟的内部框架，埋点数据流入离线数仓表，缺点是这部分数据要经过离线任务T+1才能使用。服务端埋点数据直接进入Elasticsearch，即时可用，同时在不支持前端埋点的场景（如ToB场景），可以成为主要的埋点数据收集方式。 线上搜索服务 。提供搜索相关的线上服务，在后文详细解释这部分。

服务架构

上图是线上搜索服务的主要组件图。整个搜索服务分为三个大的服务：搜索推荐服务、聚合服务和搜索服务。

搜索推荐服务 （Type as you search）。搜索推荐服务对性能有一定的要求，通常来说补全的请求完成时间不能超过200ms，超过了用户就会有比较明显的延迟感。因此不能直接使用搜索接口实现，我们的系统里是基于Elasticsearch的Context suggester实现的。除此之外，还有两个问题需要重点考虑：基于浏览的热度排序。页面上能够推荐的词数是有限的，通常是10个，在输入较短时，候选的推荐词通常会超过这个限制，因此通过资产的浏览热度来排序可以提高搜索推荐的准确率，改善用户的搜索体验。时序问题。一次搜索过程中会有一连串的搜索推荐请求，服务端会并行的处理这些请求，通常更长的输入由于候选推荐词更少服务端响应反而更快，在用户输入较快的时候（比如连续的删除字符），前端先发出的请求可能会后返回，因此可能造成输入停止后推荐的词与输入不匹配。我们的方案是前端在根据服务端响应刷新数据时需要检查返回的输入与当前输入框内容是否一致，从而保持最终一致性。 聚合服务 。聚合服务根据输入和筛选项提供搜索过程中需要用到的统计数字。例如用户希望知道搜索结果总共有多少条，每个筛选项下有多少个候选结果等统计信息，从而指导用户对搜索结果进行筛选，缩小搜索范围。同时，每个筛选项下的可选项需要根据输入和其它关联的筛选值动态生成，这部分也需要聚合服务提供。 搜索服务 。支持核心的搜索过程，通过输入，返回对应的资产作为搜索结果。分为4个主要的部分。

预处理过程 （Preprocess），主要包含对输入的预处理和用户信息的预处理。

对输入的预处理主要包括分词，停用，词性还原等基本的文本处理。分词主要包含英文分词和中文分词。英文分词需要处理-_等链接符分词，中文分词主要是用IK分词器。停用主要包含各种词如“的”，“了”，“我”和各种特殊符号“》〉？”等无意义的词语。词性还原是一把双刃剑，因为Data Catalog中的词语不同于一般的自然语言，有比较多的专有名词，比如live listing不应当被还原为live list，避免文本匹配的分数不准。同时这部分也包含对输入中的强pattern进行识别，如\"数据库名.表名”等。 对用户信息的预处理。用户是否为超级用户，是否为API用户等，可以借此判断用户常搜索的资产类型或从未搜索的资产类型。

召回过程 （Recall），负责通过输入和筛选项根据文本相关度从Elasticsearch查询一定数量的搜索候选结果，供下一步精排使用。召回过程需要保证用户期望的结果包含在召回结果中，否则后续排序优化都是徒劳。同时，召回的数量需要限制在合理的数值。主要原因有两点：一是排序靠后的搜索结果几乎没有用户会查看。二是召回过多的候选结果会影响性能，尤其是排序性能消耗比较大时。我们的召回主要分为两种方式：自然召回和强规则召回。

自然召回。对经过预处理的输入进行不同资产类型的召回，使用best field的策略，对资产的不同字段设置不同的权重，例如命中名称的资产应当比命中描述的资产优先级高。这里的权重通常根据经验设置，可以根据搜索结果的Badcase review得到，这个权重数值的精度要求不高，确保期望的结果能召回回来即可。 强规则召回。可以定制一些规则，作为自然召回的补充，涵盖精确表名的召回，或者从用户的常用资产列表进行召回。 除此之外，还需要做好多租户的隔离，避免当前租户的用户召回其它租户的资产。

精排过程 （Rank），负责对召回的结果进行最终的排序。精排过程依次包含机器学习模型预测（Learning to rank）和基于规则调整两部分。Learning to rank部分详细介绍见后文。

机器学习模型在线预测，负责主要的排序工作。加载离线训练得到的PMML模型文件，提供预测功能。 基于强规则的调整，包含排序的各种兜底策略，比较常用的有： 精确匹配的结果排在第一位。 添加Tie-breaker，保证分数相同的结果多次搜索的排序一致。

后处理过程 （Postprocess），对排好序的结果添加各种不影响顺序的后处理。例如：

权限检查，隐藏表设置。一些资产不希望被没有相关权限的用户查看详情，需要在搜索结果中设置相应字段并返回给前端。 高亮，对命中字段进行高亮标注，返回给前端。

点击跳转 了解更多

关键词：