1. 布景

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

2. 功用要求

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

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

3. 个性化的归纳查找

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

3.1 架构

3.1.1 整体架构

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

1. 实时导入。财物元数据改变时相应的渠道发出实时改变音讯，Data Catalog 体系会消费改变音讯，经过 ingestion 服务更新 Elasticsearch 中的文档，以此来到达查找实时性秒级的需求。

2. 离线导入。实时导入的进程中或许会遇到网络动摇等不可控因素导致更新失败，因而需求守时的任务来查看和增量更新缺失的元数据。

3. 用户行为记录。记录用户查找点击日志，用来后续进行查找的 Badcase review 和模型练习。这部分采用了前端埋点和服务端埋点结合的办法。前端埋点有成熟的内部结构，埋点数据流入离线数仓表，缺陷是这部分数据要经过离线任务 T+1 才能运用。服务端埋点数据直接进入 Elasticsearch，即时可用，一起在不支撑前端埋点的场景（如 ToB 场景），能够成为首要的埋点数据搜集办法。

4. 线上查找服务。供给查找相关的线上服务，在后文具体解释这部分。

3.1.2 服务架构

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

• 查找引荐服务（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），对排好序的成果添加各种不影响顺序的后处理。例如：
    • 权限查看，隐藏表设置。一些财物不期望被没有相关权限的用户查看概况，需求在查找成果中设置相应字段并回来给前端。
    • 高亮，对射中字段进行高亮标示，回来给前端。

3.2 Learning to rank

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

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

3.2.1 数据标示

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

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

3.2.2 特征

特征工程是一个持续的进程。经过一系列的选取，咱们体系的首要特征分为 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 渠道查询点击该财物所属担任人所有财物的次数
• 数据实效性，用户会更倾向于运用最近创立或许有数据更新到财物
  • 财物创立时刻
  • 财物数据等最近更新时刻等

  3.2.3 模型

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

• Pointwise，对每个输入，对每个召回的财物单独打分（一般是 Regression），然后按照分数进行排序。
  • 长处：简略直观。
  • 缺陷：排序实际上不需求对财物进行准确打分，这类办法没有考虑召回财物之间的相互联系，考虑到用户在一组财物中只会点击其间一个，排名靠后的和排名靠前的财物在损失函数上的奉献没有表现。

• Pairwise，对每个输入，考虑召回成果中所有财物的二元组合<财物 1, 财物 2>, 采取分类模型，猜测两个财物的相对排序联系。
  • 长处：依据点击与原有相关性分数排序标示简略，比较 pointwise 考虑到选项之间联系。
  • 缺陷：同样没有考虑排序前后顺序的重要性不同，样本生成杂乱，开销大。对反常标示灵敏，错误点影响规模大。

• Listwise，考虑给定输入下的召回财物调集的整体序列，优化整个序列，一般运用 NDCG 作为优化目标。
  • 长处：优化整个序列，考虑序列内财物之间的联系。
  • 缺陷：单条样本练习量大。样本过少，则无法对所有样本猜测得到好的作用。

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

3.2.4 评价

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

• NDCG，归一化折损累计增益。NDCG 是引荐和查找中比较常用的评价办法，用来整体评价排序成果的准确性。

• AUC，AUC 首要反映排序能力的相对性，用于在正负样本不均衡的情况衡量离线模型拟合情况。

• 重放有点击历史数据的点击率，运用待评价的模型猜测有点击的历史输入，排序后得到 Top3, Top5, Top10 点击率作为参考。这种办法比较直观，缺陷是不能反映出在无点击历史数据上的作用。

3.3 衡量目标

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

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

• 查找成果页透出的信息过少，用户不得不点击成果进入财物概况，即便只想查看一些简略的信息。

• 用户在体系上探究的兴趣较小，只搜了解的财物或许确定能搜到的输入。

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

4. 其它形式

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

5. 后续工作

Data Catalog 体系的查找功用还有许多有意义的工作值得咱们持续探究，例如：

• 血缘中的查找。当一个财物的一级下流就超过上千个时，想从当时财物的众多下流中查找到相关的财物并不简单，因而供给依据血缘的挑选和查找是一个不错的挑选。
• 多租户之间模型的迁移。作为支撑多租户的公有云服务，因为租户之间数据的差异，新租户的冷启动问题，以较小的数据量和本钱来支撑不同租户都有好的查找体会，也是一个值得应战的方向。

6. 关于咱们

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

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

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