摘要

DataLeap是火山引擎数智渠道VeDI旗下的大数据研制管理套件产品，协助用户快速完结数据集成、开发、运维、管理、财物、安全等全套数据中台建造，下降作业本钱和数据维护本钱、发掘数据价值、为企业决议计划供给数据支撑。

火山引擎DataLeap的Data Catalog体系经过汇总和安排各种元数据，处理了数据生产者整理数据、数据顾客找数和理本领的事务场景，其间查找是Data Catalog的首要功用之一。本文具体介绍火山引擎DataLeap的Data Catalog体系查找功用的规划与完结。

背景

Data Catalog能够协助大公司更好地整理和管理自己的财物，是Data-drvien公司的重要渠道。一个通用的Data Catalog渠道一般包括元数据管理，查找，血缘，标签，术语等功用。其间，查找是Data Catalog的入口功用，承担着让用户“找到数”的首要能力。在火山引擎DataLeap的Data Catalog体系中，每天有70%以上的用户会运用查找功用。

功用要求

业界首要的Augmented Data Catalog需求支撑Google一样的查找体会来查找数据财物，以满意不同人物的用户的找数需求。咱们的体系也一样，查找需求支撑的首要功用包括：

• 支撑多种不同类型财物的查找。现在体系中已经包括15+种数据源，能够分为几大类：数仓表比方Hive，看板，数据集，实时表，Topic，对象存储，分布式文件体系如LasFS等。带来的首要应战是不同类型的财物，查找的字段和权重有显着差异。
• 支撑个性化。现在体系的用户遍布整个公司，人物涵盖数据工程师，数据分析师，产品经理，项目经理，出售和数据科学家等等，需求完结的数据作业使命差异也比较大，比方数据开发，数据管理，BI，数据分析和机器学习等等，因而个性化对Data Catalog的查找尤为重要。
• 支撑各种事务 元数据 的高级挑选。数据财物除了称号/别号/描绘等字段，一般还会有一些事务元数据，如项目/事务域/担任人/担任人部门/标签/事务术语/生命周期状况等。经过支撑指定事务元数据进行挑选，协助用户减小查找规模，更快搜到对应财物。
• 支撑秒级的实时性。这儿的实时性是指元数据的改变需求在秒级别反映到Data Catalog的查找里，例如新建表需求在操作完结后1～2秒内即能搜到相应的表，删除表需求不再显现在查找成果中。原因是用户新建或更新财物后一般会到咱们的体系上检查相应的改变是否收效。用户手动在阅读器操作查找的时刻一般是秒级，超越这个时刻会给用户带来困惑，下降整个Data Catalog的运用体会。
• 支撑Google相似的查找引荐(Type as you search)功用。查找补全功用是查找的一个导航功用，能够在用户键入内容时提示他们能够输入的相关内容，然后进步查找精度。这个功用对呼应速度有必定的要求，一起因为数据财物的特殊性，前缀相同的财物数量较多，因而也需求依据财物的热度进行必定的排序。
• 支撑多租户。咱们的体系不仅供公司内部运用，也供给公有云服务，因而支撑多租户也是查找的一个P0需求。
• 支撑多言语。数据财物的称号/描绘/标签/术语等需求支撑多种言语，查找的输入也或许是不同的言语，最常用的比方英文和中文。不同言语的分词，专有名词字典，文本特征等都会带来一些应战。

个性化的归纳查找

为了满意上述需求，火山引擎DataLeap采用了个性化归纳查找的计划。区别于联合查找（federated search），用户需求指定查找的具体财物类型或在查找成果页对不同的财物分栏显现，归纳查找（unified search）允许用户在一个查找框中进行查找输入而无需指定查找的财物类型，一起，查找服务会在同一个查找成果页回来不同类型的相关财物，并依据匹配程度和用户的个性化数据进行混合排序。优势是能给不同的用户针对不同财物的查找需求供给统一的查找体会，一起供给了用户跨类型圈定财物的能力。别的，归纳查找使得咱们能够在页面上进行标准化透出，然后咱们能够从技术上进行查找标准化，到达新数据源接入即可查找。

架构

全体架构

咱们的查找体系运用了开源的查找引擎Elasticsearch进行基础的文档检索（Recall阶段），因而各种财物元数据会被存放到Elasticsearch中。整个体系包括4个首要的数据流程：

1. 实时导入。财物元数据改变时相应的渠道宣布实时改变音讯，Data Catalog体系会消费改变音讯，经过ingestion服务更新Elasticsearch中的文档，以此来到达查找实时性秒级的需求。
2. 离线导入。实时导入的进程中或许会遇到网络动摇等不可控因素导致更新失败，因而需求守时的使命来检查和增量更新缺失的元数据。
3. 用户行为记载。记载用户查找点击日志，用来后续进行查找的Badcase review和模型练习。这部分采用了前端埋点和服务端埋点结合的办法。前端埋点有成熟的内部结构，埋点数据流入离线数仓表，缺陷是这部分数据要经过离线使命T+1才干运用。服务端埋点数据直接进入Elasticsearch，即时可用，一起在不支撑前端埋点的场景（如ToB场景），能够成为首要的埋点数据搜集办法。
4. 线上查找服务。供给查找相关的线上服务，在后文具体解说这部分。

服务架构

上图是线上查找服务的首要组件图。整个查找服务分为三个大的服务：查找引荐服务、聚合服务和查找服务。

• 查找引荐服务（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），对排好序的成果添加各种不影响次序的后处理。例如：

    • 权限检查，躲藏表设置。一些财物不希望被没有相关权限的用户检查概况，需求在查找成果中设置相应字段并回来给前端。
    • 高亮，对命中字段进行高亮标示，回来给前端。

Learning to rank

Learning to rank首要分为数据搜集，离线练习和在线猜测三个部分。查找体系是一个Data-driven system，因而体系规划之初就需求考虑数据搜集。搜集的数据能够用来评价和提升查找的作用。数据搜集和在线猜测前面已有介绍，不再赘述，下面首要介绍离线练习部分。

离线练习的进程首要包括数据标示，特征工程，模型练习和评价。这四个步骤并非从前往后一气呵成，而是有或许进行评价，发现不足，然后添加标示数据，添加特征，重新练习，再次评价。评价作用有比较显着的收益时，才会上线测验。

数据标示

作为Data Catalog的查找体系，不太简略获取大规模的人工标示数据，首要有两个原因：一是标示的本钱较高，二是范畴常识的专业性导致不简略找到合适的标示人员。因而，咱们的标示数据来源首要有两个：一是来自查找日志中有点击的部分，咱们将这部分数据划分为三档，曝光有点击，曝光排名前五且未点击和曝光未点击，赋予不同的分数；二是咱们依据财物称号结合日志中未点击的输入，依据规矩生成必定的练习数据。

练习数据集需求持续更新，在review badcase时，能够针对需求改善的场景添加相应的练习数据。

特征

特征工程是一个持续的进程。经过一系列的选取，咱们体系的首要特征分为4大类型，涵盖了查找的文本特征，数据的权威性，用户的个性化数据和数据的时效性。

下面列举了一些咱们用到的首要特征和分类：

• 文本特征

  • 输入相关的文本特征

    • 输入长度，比方有多少个词，总长度等等
    • 输入言语类型，中文或英文

  • 文本匹配度相关的特征

    • 依据词袋的CQR
    • Elasticsearch查询回来分数，依据BM25

• 数据权威性

  • 热度：AssetRank, 依据财物的运用量和血缘联系，经过Weighted PageRank算法计算得到的财物热度
  • 元数据完整度，包括财物的事务元数据，如项目，主题，产品线等
  • 财物的最近1天/7天/30天的全渠道运用总次数
  • 财物所处的生命周期：如上线，待下线，抛弃等
  • 财物的总点赞数

• 用户个性化数据，分为三大类

  • 静态个性化数据

    • 担任人：当时用户是否是该财物的担任人
    • 保藏：当时用户是否保藏了该财物
    • 点赞：当时用户是否点赞了该财物

  • 前史查找查询行为数据

    • 当时用户前史上最近1天/7天/30天全渠道运用该财物的次数
    • 当时用户前史上最近1天/7天/30天在Data Catalog渠道查询点击该财物的次数

  • 协同数据

    • 同部门人员前史上最近1天/7天/30天在Data Catalog渠道查询点击该财物的次数
    • 当时用户前史上最近1天/7天/30天在Data Catalog渠道查询点击该财物所属部门一切财物的次数
    • 当时用户前史上最近1天/7天/30天在Data Catalog渠道查询点击该财物所属担任人一切财物的次数

• 数据时效性，用户会更倾向于运用最近创建或许有数据更新的财物

  • 财物创建时刻
  • 财物数据的最近更新时刻等

模型

Learning to rank一般有三类办法：Pointwise，Pairwise和Listwise。这三类办法各有优缺陷，细节介绍如下：

• Pointwise，对每个输入，对每个召回的财物单独打分（一般是Regression），然后按照分数进行排序。

  • 长处：简略直观。
  • 缺陷：排序实际上不需求对财物进行准确打分，这类办法没有考虑召回财物之间的相互联系，考虑到用户在一组财物中只会点击其间一个，排名靠后的和排名靠前的财物在丢失函数上的贡献没有表现。

• Pairwise，对每个输入，考虑召回成果中一切财物的二元组合<财物1, 财物2>, 采纳分类模型，猜测两个财物的相对排序联系。

  • 长处：依据点击与原有相关性分数排序标示简略，比较pointwise考虑到选项之间联系。
  • 缺陷：相同没有考虑排序前后次序的重要性不同，样本生成复杂，开销大。对异常标示敏感，错误点影响规模大。

• Listwise，考虑给定输入下的召回财物调集的全体序列，优化整个序列，一般运用NDCG作为优化目标。

  • 长处：优化整个序列，考虑序列内财物之间的联系。
  • 缺陷：单条样本练习量大。样本过少，则无法对一切样本猜测得到好的作用。

咱们对Pointwise和Listwise都做了试验，终究咱们的体系采用了Listwise的计划。首要原因是在咱们的标示办法下，Listwise的计划更简略标示。具体完结上咱们采用了LightGBM的结构。

评价

咱们运用了NDCG，AUC和验证点击率的办法对模型进行评价。

• NDCG，归一化折损累计增益。NDCG是引荐和查找中比较常用的评价办法，用来全体评价排序成果的准确性。
• AUC，AUC首要反映排序能力的相对性，用于在正负样本不均衡的状况衡量离线模型拟合状况。
• 重放有点击前史数据的点击率，运用待评价的模型猜测有点击的前史输入，排序后得到Top3, Top5, Top10 点击率作为参考。这种办法比较直观，缺陷是不能反映出在无点击前史数据上的作用。

衡量指标

查找服务改变或新模型上线后，咱们需求对线上查找的实在作用进行衡量。现在咱们首要经过查找的点击率和Top3点击率来衡量。因为Data Catalog查找的特殊性，咱们更看重含糊查找的整体点击率和Top3点击率（输入和财物称号完全共同的为准确查找，其它为含糊查找）。

实际上，点击率并非越高越好，过高的点击率或许意味着:

• 查找成果页透出的信息过少，用户不得不点击成果进入财物概况，即便只想检查一些简略的信息。
• 用户在体系上探究的兴趣较小，只搜熟悉的财物或许确定能搜到的输入。

当然过低的点击率意味着较差的查找体会。因而，点击率保持在必定健康的区间后，咱们也需求重视含糊查找和准确查找的占比等指标。

其它形式

除了个性化的查找需求，也会有一些场景，用户不需求精细化的排序，只需求把包括相关文本的财物都列举出来，因而咱们也支撑单纯的列表形式，用户能够在列表形式经过指定字段来对查找成果进行排序。咱们也在规划完结一些query syntax的功用，以此来支撑用户在列表形式下更灵敏地束缚输入。

后续作业

火山引擎DataLeap中的Data Catalog体系查找功用还有许多有意义的作业值得持续探究，例如：

• 血缘中的查找。当一个财物的一级下流就超越上千个时，想从当时财物的很多下流中查找到相关的财物并不简略，因而供给依据血缘的挑选和查找是一个不错的选择。

• 多租户之间模型的迁移。作为支撑多租户的公有云服务，因为租户之间数据的差异，新租户的冷启动问题，以较小的数据量和本钱来支撑不同租户都有好的查找体会，也是一个值得应战的方向。

关于咱们

火山引擎大数据研制管理套件DataLeap

一站式数据中台套件，协助用户快速完结数据集成、开发、运维、管理、财物、安全等全套数据中台建造，协助数据团队有用的下降作业本钱和数据维护本钱、发掘数据价值、为企业决议计划供给数据支撑。

欢迎加入字节跳动 数据渠道 官方群，进行数据技术交流、获取更多内容干货

当即跳转 大数据研制管理套件 DataLeap 了解概况！