共计 2358 个字符，预计需要花费 6 分钟才能阅读完成。
整体架构
火山引擎 DataLeap 的 Catalog 搜寻零碎应用了开源的搜索引擎 Elasticsearch 进行根底的文档检索（Recall 阶段），因而各种资产元数据会被寄存到 Elasticsearch 中。整个零碎包含 4 个次要的数据流程：
- 实时导入。资产元数据变更时相应的平台收回实时变更音讯，Data Catalog 零碎会生产变更音讯，通过 ingestion 服务更新 Elasticsearch 中的文档，以此来达到搜寻实时性秒级的需要。
- 离线导入。实时导入的过程中可能会遇到网络稳定等不可控因素导致更新失败，因而须要定时的工作来检查和增量更新缺失的元数据。
- 用户行为记录。记录用户搜寻点击日志，用来后续进行搜寻的 Badcase review 和模型训练。火山引擎 DataLeap 的 Catalog 零碎这部分采纳了前端埋点和服务端埋点联合的形式。前端埋点有成熟的外部框架，埋点数据流入离线数仓表，毛病是这部分数据要通过离线工作 T + 1 能力应用。服务端埋点数据间接进入 Elasticsearch，即时可用，同时在不反对前端埋点的场景（如 ToB 场景），能够成为次要的埋点数据收集形式。
- 线上搜寻服务。提供搜寻相干的线上服务，在后文具体解释这部分。
服务架构
上图是线上搜寻服务的次要组件图。火山引擎 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），对排好序的后果增加各种不影响程序的后处理。例如：
- 权限查看，暗藏表设置。一些资产不心愿被没有相干权限的用户查看详情，须要在搜寻后果中设置相应字段并返回给前端。
- 高亮，对命中字段进行高亮标注，返回给前端。
