共计 1520 个字符，预计需要花费 4 分钟才能阅读完成。
火山引擎 DataLeap 的 Data Catalog 零碎通过汇总和组织各种元数据，解决了数据生产者梳理数据、数据消费者找数和了解数的业务场景，其中搜寻是 Data Catalog 的次要性能之一。本文具体介绍了火山引擎 DataLeap 的 Catalog 零碎搜寻实际：性能的设计与实现。
Data Catalog 可能帮忙大公司更好地梳理和治理本人的资产，是 Data-drvien 公司的重要平台。一个通用的 Data Catalog 平台通常蕴含元数据管理，搜寻，血统，标签，术语等性能。其中，搜寻是 Data Catalog 的入口性能，承当着让用户“找到数”的次要能力。在火山引擎 DataLeap 的 Data Catalog 零碎中，每天有 70% 以上的用户会应用搜寻性能。
业界次要的 Augmented Data Catalog 须要反对 Google 一样的搜寻体验来搜寻数据资产，以满足不同角色的用户的找数需要。火山引擎 DataLeap 也一样，搜寻须要反对的次要性能包含：
- 反对多种不同类型资产的搜寻。目前零碎中曾经蕴含 15+ 种数据源，能够分为几大类：数仓表比方 Hive，看板，数据集，实时表，Topic，对象存储，分布式文件系统如 LasFS 等。带来的次要挑战是不同类型的资产，搜寻的字段和权重有显著差别。
- 反对个性化。目前零碎的用户遍布整个公司，角色涵盖数据工程师，数据分析师，产品经理，项目经理，销售和数据科学家等等，须要实现的数据工作工作差别也比拟大，比方数据开发，数据治理，BI，数据分析和机器学习等等，因而个性化对 Data Catalog 的搜寻尤为重要。
- 反对各种业务元数据的高级筛选。数据资产除了名称 / 别名 / 形容等字段，通常还会有一些业务元数据，如我的项目 / 业务域 / 负责人 / 负责人部门 / 标签 / 业务术语 / 生命周期状态等。通过反对指定业务元数据进行筛选，帮忙用户减小搜寻范畴，更快搜到对应资产。
- 反对秒级的实时性。这里的实时性是指元数据的变更须要在秒级别反映到 Data Catalog 的搜寻里，例如新建表须要在操作实现后 1～2 秒内即能搜到相应的表，删除表须要不再显示在搜寻后果中。起因是用户新建或更新资产后通常会到咱们的零碎上查看相应的变更是否失效。用户手动在浏览器操作搜寻的工夫通常是秒级，超过这个工夫会给用户带来困惑，升高整个 Data Catalog 的应用体验。
- 反对 Google 相似的搜寻举荐 (Type as you search) 性能。搜寻补全性能是搜寻的一个导航性能，能够在用户键入内容时提醒他们能够输出的相干内容，从而进步搜寻精度。这个性能对响应速度有肯定的要求，同时因为数据资产的特殊性，前缀雷同的资产数量较多，因而也须要依据资产的热度进行肯定的排序。
- 反对多语言。数据资产的名称 / 形容 / 标签 / 术语等须要反对多种语言，搜寻的输出也可能是不同的语言，最罕用的比方英文和中文。不同语言的分词，专有名词字典，文本特色等都会带来一些挑战。
为了满足上述需要，火山引擎 DataLeap 的 Catalog 零碎采纳了个性化综合搜寻的计划。区别于联结搜寻（federated search），用户须要指定搜寻的具体资产类型或在搜寻后果页对不同的资产分栏显示，综合搜寻（unified search）容许用户在一个搜寻框中进行搜寻输出而无需指定搜寻的资产类型。
同时，搜寻服务会在同一个搜寻后果页返回不同类型的相干资产，并依据匹配水平和用户的个性化数据进行混合排序。劣势是能给不同的用户针对不同资产的搜寻需要提供对立的搜寻体验，同时提供了用户跨类型圈定资产的能力。另外，综合搜寻使得火山引擎 DataLeap 的 Catalog 零碎能够在页面上进行标准化透出，从而能够从技术上进行搜寻标准化，达到新数据源接入即可搜寻。
