字节跳动数据中台的 Data Catalog 系统搜索实践

,Data Catalog 能够帮助大公司更好地梳理和管理自己的资产，是 Data-drvien 公司的重要平台。一个通用的 Data Catalog 平台通常包含元数据管理，搜索，血缘，标签，术语等功能。其中，搜索是 Data Catalog 的入口功能，承担着让用户“找到数”的主要能力。在字节跳动数据中台的 Data Catalog 系统中，每天有 70% 以上的用户会使用搜索功能。,业界主要的 Augmented Data Catalog 需要支持 Google 一样的搜索体验来搜索数据资产，以满足不同角色的用户的找数需求。我们的系统也一样，搜索需要支持的主要功能包括：,为了满足上述需求，我们的系统采用了个性化综合搜索的方案。区别于联合搜索（federated search），用户需要指定搜索的具体资产类型或在搜索结果页对不同的资产分栏显示，综合搜索（unified search）允许用户在一个搜索框中进行搜索输入而无需指定搜索的资产类型，同时，搜索服务会在同一个搜索结果页返回不同类型的相关资产，并根据匹配程度和用户的个性化数据进行混合排序。优势是能给不同的用户针对不同资产的搜索需求提供统一的搜索体验，同时提供了用户跨类型圈定资产的能力。另外，综合搜索使得我们可以在页面上进行标准化透出，从而我们可以从技术上进行搜索标准化，达到新数据源接入即可搜索。,3.1.1 整体架构​,,我们的搜索系统使用了开源的搜索引擎 Elasticsearch 进行基础的文档检索（Recall 阶段），因此各种资产元数据会被存放到 Elasticsearch 中。整个系统包括 4 个主要的数据流程：,,上图是线上搜索服务的主要组件图。整个搜索服务分为三个大的服务：搜索推荐服务、聚合服务和搜索服务。,1.搜索推荐服务（Type as you search）。搜索推荐服务对性能有一定的要求，通常来说补全的请求完成时间不能超过 200ms，超过了用户就会有比较明显的延迟感。因此不能直接使用搜索接口实现，我们的系统里是基于 Elasticsearch 的 Context suggester 实现的。除此之外，还有两个问题需要重点考虑：,（1）基于浏览的热度排序。页面上能够推荐的词数是有限的，通常是 10 个，在输入较短时，候选的推荐词通常会超过这个限制，因此通过资产的浏览热度来排序可以提高搜索推荐的准确率，改善用户的搜索体验。,（2）时序问题。一次搜索过程中会有一连串的搜索推荐请求，服务端会并行的处理这些请求，通常更长的输入由于候选推荐词更少服务端响应反而更快，在用户输入较快的时候（比如连续的删除字符），前端先发出的请求可能会后返回，因此可能造成输入停止后推荐的词与输入不匹配。我们的方案是前端在根据服务端响应刷新数据时需要检查返回的输入与当前输入框内容是否一致，从而保持最终一致性。​,2.聚合服务。聚合服务根据输入和筛选项提供搜索过程中需要用到的统计数字。例如用户希望知道搜索结果总共有多少条，每个筛选项下有多少个候选结果等统计信息，从而指导用户对搜索结果进行筛选，缩小搜索范围。同时，每个筛选项下的可选项需要根据输入和其它关联的筛选值动态生成，这部分也需要聚合服务提供。,3.搜索服务。支持核心的搜索过程，通过输入，返回对应的资产作为搜索结果。分为 4 个主要的部分。,4.预处理过程（Preprocess），主要包含对输入的预处理和用户信息的预处理。,（1）对输入的预处理主要包括分词，停用，词性还原等基本的文本处理。分词主要包含英文分词和中文分词。英文分词需要处理-_等链接符分词，中文分词主要是用 IK 分词器。停用主要包含各种词如“的”，“了”，“我”和各种特殊符号“》〉？”等无意义的词语。词性还原是一把双刃剑，因为 Data Catalog 中的词语不同于一般的自然语言，有比较多的专有名词，比如 live listing 不应当被还原为 live list，避免文本匹配的分数不准。同时这部分也包含对输入中的强 pattern 进行识别，如”数据库名.表名”等。,（2）对用户信息的预处理。用户是否为超级用户，是否为 API 用户等，可以借此判断用户常搜索的资产类型或从未搜索的资产类型。,5.召回过程（Recall），负责通过输入和筛选项根据文本相关度从 Elasticsearch 查询一定数量的搜索候选结果，供下一步精排使用。召回过程需要保证用户期望的结果包含在召回结果中，否则后续排序优化都是徒劳。同时，召回的数量需要限制在合理的数值。主要原因有两点：一是排序靠后的搜索结果几乎没有用户会查看。二是召回过多的候选结果会影响性能，尤其是排序性能消耗比较大时。我们的召回主要分为两种方式：自然召回和强规则召回。,6.自然召回。对经过预处理的输入进行不同资产类型的召回，使用 best field 的策略，对资产的不同字段设置不同的权重，例如命中名称的资产应当比命中描述的资产优先级高。这里的权重通常根据经验设置，可以根据搜索结果的 Badcase review 得到，这个权重数值的精度要求不高，确保期望的结果能召回回来即可。,7.强规则召回。可以定制一些规则，作为自然召回的补充，涵盖精确表名的召回，或者从用户的常用资产列表进行召回。,    除此之外，还需要做好多租户的隔离，避免当前租户的用户召回其它租户的资产。,（1）精排过程（Rank），负责对召回的结果进行最终的排序。精排过程依次包含机器学习模型预测（Learning to rank）和基于规则调整两部分。Learning to rank 部分详细介绍见后文。,1）机器学习模型在线预测，负责主要的排序工作。加载离线训练得到的 PMML 模型文件，提供预测功能。,2）基于强规则的调整，包含排序的各种兜底策略，比较常用的有：,a.精确匹配的结果排在第一位。,b.添加 Tie-breaker，保证分数相同的结果多次搜索的排序一致。,（2）后处理过程（Postprocess），对排好序的结果添加各种不影响顺序的后处理。例如：,8.权限检查，隐藏表设置。一些资产不希望被没有相关权限的用户查看详情，需要在搜索结果中设置相应字段并返回给前端。,9.高亮，对命中字段进行高亮标注，返回给前端。,,Learning to rank 主要分为数据收集，离线训练和在线预测三个部分。搜索系统是一个 Data-driven system，因此系统设计之初就需要考虑数据收集。收集的数据可以用来评估和提升搜索的效果。数据收集和在线预测前面已有介绍，不再赘述，下面主要介绍离线训练部分。,离线训练的过程主要包括数据标注，特征工程，模型训练和评估。这四个步骤并非从前往后一气呵成，而是有可能进行评估，发现不足，然后增加标注数据，增加特征，重新训练，再次评估。评估效果有比较明显的收益时，才会上线测试。,作为 Data Catalog 的搜索系统，不太容易获取大规模的人工标注数据，主要有两个原因：一是标注的成本较高，二是领域知识的专业性导致不容易找到合适的标注人员。因此，我们的标注数据来源主要有两个：一是来自搜索日志中有点击的部分，我们将这部分数据划分为三档，曝光有点击，曝光排名前五且未点击和曝光未点击，赋予不同的分数；二是我们根据资产名称结合日志中未点击的输入，基于规则生成一定的训练数据。,训练数据集需要持续更新，在 review badcase 时，可以针对需要改进的场景添加相应的训练数据。,特征工程是一个持续的过程。经过一系列的选取，我们系统的主要特征分为 4 大类型，涵盖了搜索的文本特征，数据的权威性，用户的个性化数据和数据的时效性。,下面列举了一些我们用到的主要特征和分类：,(1)入相关的文本特征,a.输入长度，比如有多少个词，总长度等等,b.输入语言类型，中文或英文,(2)文本匹配度相关的特征​,(1)负责人：当前用户是否是该资产的负责人,(2)收藏：当前用户是否收藏了该资产,(3)点赞：当前用户是否点赞了该资产,Learning to rank 通常有三类方法：Pointwise，Pairwise 和 Listwise。这三类方法各有优缺点，细节介绍如下：,(1)优点：简单直观。,(2)缺点：排序实际上不需要对资产进行精确打分，这类方法没有考虑召回资产之间的互相关系，考虑到用户在一组资产中只会点击其中一个，排名靠后的和排名靠前的资产在损失函数上的贡献没有体现。,(1)优点：基于点击与原有相关性分数排序标注简单，相比 pointwise 考虑到选项之间关系。,(2)缺点：同样没有考虑排序前后顺序的重要性不同，样本生成复杂，开销大。对异常标注敏感，错误点影响范围大。,(1)优点：优化整个序列，考虑序列内资产之间的关系。,(2)缺点：单条样本训练量大。样本过少，则无法对所有样本预测得到好的效果。,我们对 Pointwise 和 Listwise 都做了实验，最终我们的系统采用了 Listwise 的方案。主要原因是在我们的标注方式下，Listwise 的方案更容易标注。具体实现上我们采用了 LightGBM 的框架。,我们使用了 NDCG，AUC 和验证点击率的方式对模型进行评估。,搜索服务变更或新模型上线后，我们需要对线上搜索的真实效果进行衡量。目前我们主要通过搜索的点击率和 Top3 点击率来衡量。由于 Data Catalog 搜索的特殊性，我们更看重模糊搜索的总体点击率和 Top3 点击率（输入和资产名称完全一致的为精确搜索，其它为模糊搜索）。,实际上，点击率并非越高越好，过高的点击率可能意味着:,当然过低的点击率意味着较差的搜索体验。因此，点击率保持在一定健康的区间后，我们也需要关注模糊搜索和精确搜索的占比等指标。,除了个性化的搜索需求，也会有一些场景，用户不需要精细化的排序，只需要把包含相关文本的资产都列举出来，因此我们也支持单纯的列表模式，用户可以在列表模式通过指定字段来对搜索结果进行排序。我们也在规划实现一些 query syntax 的功能，以此来支持用户在列表模式下更灵活地约束输入。,Data Catalog 系统的搜索功能还有很多有意义的工作值得我们继续探索，例如：,火山引擎大数据研发治理套件 DataLeap,一站式数据中台套件，帮助用户快速完成数据集成、开发、运维、治理、资产、安全等全套数据中台建设，帮助数据团队有效的降低工作成本和数据维护成本、挖掘数据价值、为企业决策提供数据支撑。