火山引擎 DataLeap 的 Catalog 系统搜索实践 （二）：整体架构

整体架构

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

1. 实时导入。资产元数据变更时相应的平台发出实时变更消息，Data Catalog 系统会消费变更消息，通过 ingestion 服务更新 Elasticsearch 中的文档，以此来达到搜索实时性秒级的需求。

2. 离线导入。实时导入的过程中可能会遇到网络波动等不可控因素导致更新失败，因此需要定时的任务来检查和增量更新缺失的元数据。

3. 用户行为记录。记录用户搜索点击日志，用来后续进行搜索的 Badcase review 和模型训练。火山引擎 DataLeap 的 Catalog 系统这部分采用了前端埋点和服务端埋点结合的方式。前端埋点有成熟的内部框架，埋点数据流入离线数仓表，缺点是这部分数据要经过离线任务 T+1 才能使用。服务端埋点数据直接进入 Elasticsearch，即时可用，同时在不支持前端埋点的场景（如 ToB 场景），可以成为主要的埋点数据收集方式。

4. 线上搜索服务。提供搜索相关的线上服务，在后文详细解释这部分。

服务架构

上图是线上搜索服务的主要组件图。火山引擎 DataLeap 的 Catalog 系统的整个搜索服务分为三个大的服务：搜索推荐服务、聚合服务和搜索服务。

• 搜索推荐服务（Type as you search）。搜索推荐服务对性能有一定的要求，通常来说补全的请求完成时间不能超过 200ms，超过了用户就会有比较明显的延迟感。因此不能直接使用搜索接口实现，我们的系统里是基于 Elasticsearch 的 Context suggester 实现的。除此之外，还有两个问题需要重点考虑：

  基于浏览的热度排序。页面上能够推荐的词数是有限的，通常是 10 个，在输入较短时，候选的推荐词通常会超过这个限制，因此通过资产的浏览热度来排序可以提高搜索推荐的准确率，改善用户的搜索体验。

  时序问题。一次搜索过程中会有一连串的搜索推荐请求，服务端会并行的处理这些请求，通常更长的输入由于候选推荐词更少服务端响应反而更快，在用户输入较快的时候（比如连续的删除字符），前端先发出的请求可能会后返回，因此可能造成输入停止后推荐的词与输入不匹配。我们的方案是前端在根据服务端响应刷新数据时需要检查返回的输入与当前输入框内容是否一致，从而保持最终一致性。

• 聚合服务。火山引擎 DataLeap 的 Catalog 系统的聚合服务根据输入和筛选项提供搜索过程中需要用到的统计数字。例如用户希望知道搜索结果总共有多少条，每个筛选项下有多少个候选结果等统计信息，从而指导用户对搜索结果进行筛选，缩小搜索范围。同时，每个筛选项下的可选项需要根据输入和其它关联的筛选值动态生成，这部分也需要聚合服务提供。

• 搜索服务。支持核心的搜索过程，通过输入，返回对应的资产作为搜索结果。分为 4 个主要的部分。

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

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

  对用户信息的预处理。用户是否为超级用户，是否为 API 用户等，可以借此判断用户常搜索的资产类型或从未搜索的资产类型。

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

  自然召回。对经过预处理的输入进行不同资产类型的召回，使用 best field 的策略，对资产的不同字段设置不同的权重，例如命中名称的资产应当比命中描述的资产优先级高。这里的权重通常根据经验设置，可以根据搜索结果的 Badcase review 得到，这个权重数值的精度要求不高，确保期望的结果能召回回来即可。

  强规则召回。可以定制一些规则，作为自然召回的补充，涵盖精确表名的召回，或者从用户的常用资产列表进行召回。

      除此之外，还需要做好多租户的隔离，避免当前租户的用户召回其它租户的资产。

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

  机器学习模型在线预测，负责主要的排序工作。加载离线训练得到的 PMML 模型文件，提供预测功能。

  基于强规则的调整，包含排序的各种兜底策略，比较常用的有：

  精确匹配的结果排在第一位。

  添加 Tie-breaker，保证分数相同的结果多次搜索的排序一致。

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

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

  高亮，对命中字段进行高亮标注，返回给前端。