1. 背景

Data Catalog 能夠幫助大公司更好地梳理和管理自己的資產(chǎn)，是 Data-drvien 公司的重要平臺(tái)。一個(gè)通用的 Data Catalog 平臺(tái)通常包含元數(shù)據(jù)管理，搜索，血緣，標(biāo)簽，術(shù)語等功能。其中，搜索是 Data Catalog 的入口功能，承擔(dān)著讓用戶“找到數(shù)”的主要能力。在字節(jié)跳動(dòng)數(shù)據(jù)中臺(tái)的 Data Catalog 系統(tǒng)中，每天有 70% 以上的用戶會(huì)使用搜索功能。

2. 功能要求

業(yè)界主要的 Augmented Data Catalog 需要支持 Google 一樣的搜索體驗(yàn)來搜索數(shù)據(jù)資產(chǎn)，以滿足不同角色的用戶的找數(shù)需求。我們的系統(tǒng)也一樣，搜索需要支持的主要功能包括：

• 支持多種不同類型資產(chǎn)的搜索。目前系統(tǒng)中已經(jīng)包含 15+ 種數(shù)據(jù)源，可以分為幾大類：數(shù)倉表比如 Hive、看板、數(shù)據(jù)集、實(shí)時(shí)表、Topic、對象存儲(chǔ)、分布式文件系統(tǒng)如 LasFS 等。帶來的主要挑戰(zhàn)是不同類型的資產(chǎn)，搜索的字段和權(quán)重有明顯差異。
• 支持個(gè)性化。目前系統(tǒng)的用戶遍布整個(gè)公司，角色涵蓋數(shù)據(jù)工程師、數(shù)據(jù)分析師、產(chǎn)品經(jīng)理、項(xiàng)目經(jīng)理、銷售和數(shù)據(jù)科學(xué)家等等，需要完成的數(shù)據(jù)工作任務(wù)差異也比較大，比如數(shù)據(jù)開發(fā)、數(shù)據(jù)治理、BI、數(shù)據(jù)分析和機(jī)器學(xué)習(xí)等等，因此個(gè)性化對 Data Catalog 的搜索尤為重要。
• 支持各種業(yè)務(wù)元數(shù)據(jù)的高級(jí)篩選。數(shù)據(jù)資產(chǎn)除了名稱/別名/描述等字段，通常還會(huì)有一些業(yè)務(wù)元數(shù)據(jù)，如項(xiàng)目 / 業(yè)務(wù)域 / 負(fù)責(zé)人 / 負(fù)責(zé)人部門 / 標(biāo)簽 / 業(yè)務(wù)術(shù)語 / 生命周期狀態(tài)等。通過支持指定業(yè)務(wù)元數(shù)據(jù)進(jìn)行篩選，幫助用戶減小搜索范圍，更快搜到對應(yīng)資產(chǎn)。
•  支持秒級(jí)的實(shí)時(shí)性。這里的實(shí)時(shí)性是指元數(shù)據(jù)的變更需要在秒級(jí)別反映到Data Catalog 的搜索里，例如新建表需要在操作完成后 1～2 秒內(nèi)即能搜到相應(yīng)的表，刪除表需要不再顯示在搜索結(jié)果中。原因是用戶新建或更新資產(chǎn)后通常會(huì)到我們的系統(tǒng)上查看相應(yīng)的變更是否生效。用戶手動(dòng)在瀏覽器操作搜索的時(shí)間通常是秒級(jí)，超過這個(gè)時(shí)間會(huì)給用戶帶來困惑，降低整個(gè) Data Catalog 的使用體驗(yàn)。
• 支持 Google 類似的搜索推薦(Type as you search)功能。搜索補(bǔ)全功能是搜索的一個(gè)導(dǎo)航功能，可以在用戶鍵入內(nèi)容時(shí)提示他們可以輸入的相關(guān)內(nèi)容，從而提高搜索精度。這個(gè)功能對響應(yīng)速度有一定的要求，同時(shí)由于數(shù)據(jù)資產(chǎn)的特殊性，前綴相同的資產(chǎn)數(shù)量較多，因此也需要根據(jù)資產(chǎn)的熱度進(jìn)行一定的排序。
• 支持多租戶。我們的系統(tǒng)不僅供公司內(nèi)部使用，也提供公有云服務(wù)，因此支持多租戶也是搜索的一個(gè) P0 需求。
• 支持多語言。數(shù)據(jù)資產(chǎn)的名稱 / 描述 / 標(biāo)簽 / 術(shù)語等需要支持多種語言，搜索的輸入也可能是不同的語言，最常用的比如英文和中文。不同語言的分詞，專有名詞字典，文本特征等都會(huì)帶來一些挑戰(zhàn)。

3. 個(gè)性化的綜合搜索

為了滿足上述需求，我們的系統(tǒng)采用了個(gè)性化綜合搜索的方案。區(qū)別于聯(lián)合搜索（federated search），用戶需要指定搜索的具體資產(chǎn)類型或在搜索結(jié)果頁對不同的資產(chǎn)分欄顯示，綜合搜索（unified search）允許用戶在一個(gè)搜索框中進(jìn)行搜索輸入而無需指定搜索的資產(chǎn)類型，同時(shí)，搜索服務(wù)會(huì)在同一個(gè)搜索結(jié)果頁返回不同類型的相關(guān)資產(chǎn)，并根據(jù)匹配程度和用戶的個(gè)性化數(shù)據(jù)進(jìn)行混合排序。優(yōu)勢是能給不同的用戶針對不同資產(chǎn)的搜索需求提供統(tǒng)一的搜索體驗(yàn)，同時(shí)提供了用戶跨類型圈定資產(chǎn)的能力。另外，綜合搜索使得我們可以在頁面上進(jìn)行標(biāo)準(zhǔn)化透出，從而我們可以從技術(shù)上進(jìn)行搜索標(biāo)準(zhǔn)化，達(dá)到新數(shù)據(jù)源接入即可搜索。

3.1 架構(gòu)

3.1.1 整體架構(gòu)?

我們的搜索系統(tǒng)使用了開源的搜索引擎 Elasticsearch 進(jìn)行基礎(chǔ)的文檔檢索（Recall 階段），因此各種資產(chǎn)元數(shù)據(jù)會(huì)被存放到 Elasticsearch 中。整個(gè)系統(tǒng)包括 4 個(gè)主要的數(shù)據(jù)流程：

1. 實(shí)時(shí)導(dǎo)入。?資產(chǎn)元數(shù)據(jù)變更時(shí)相應(yīng)的平臺(tái)發(fā)出實(shí)時(shí)變更消息，Data Catalog 系統(tǒng)會(huì)消費(fèi)變更消息，通過 ingestion 服務(wù)更新 Elasticsearch 中的文檔，以此來達(dá)到搜索實(shí)時(shí)性秒級(jí)的需求。
2. 離線導(dǎo)入。?實(shí)時(shí)導(dǎo)入的過程中可能會(huì)遇到網(wǎng)絡(luò)波動(dòng)等不可控因素導(dǎo)致更新失敗，因此需要定時(shí)的任務(wù)來檢查和增量更新缺失的元數(shù)據(jù)。
3. 用戶行為記錄。?記錄用戶搜索點(diǎn)擊日志，用來后續(xù)進(jìn)行搜索的 Badcase review 和模型訓(xùn)練。這部分采用了前端埋點(diǎn)和服務(wù)端埋點(diǎn)結(jié)合的方式。前端埋點(diǎn)有成熟的內(nèi)部框架，埋點(diǎn)數(shù)據(jù)流入離線數(shù)倉表，缺點(diǎn)是這部分?jǐn)?shù)據(jù)要經(jīng)過離線任務(wù) T+1 才能使用。服務(wù)端埋點(diǎn)數(shù)據(jù)直接進(jìn)入 Elasticsearch，即時(shí)可用，同時(shí)在不支持前端埋點(diǎn)的場景（如 ToB 場景），可以成為主要的埋點(diǎn)數(shù)據(jù)收集方式。
4. 線上搜索服務(wù)。?提供搜索相關(guān)的線上服務(wù)，在后文詳細(xì)解釋這部分。

3.1.2 服務(wù)架構(gòu)

上圖是線上搜索服務(wù)的主要組件圖。整個(gè)搜索服務(wù)分為三個(gè)大的服務(wù)：搜索推薦服務(wù)、聚合服務(wù)和搜索服務(wù)。

1.搜索推薦服務(wù)（Type as you search）。搜索推薦服務(wù)對性能有一定的要求，通常來說補(bǔ)全的請求完成時(shí)間不能超過 200ms，超過了用戶就會(huì)有比較明顯的延遲感。因此不能直接使用搜索接口實(shí)現(xiàn)，我們的系統(tǒng)里是基于 Elasticsearch 的 Context suggester 實(shí)現(xiàn)的。除此之外，還有兩個(gè)問題需要重點(diǎn)考慮：

（1）基于瀏覽的熱度排序。頁面上能夠推薦的詞數(shù)是有限的，通常是 10 個(gè)，在輸入較短時(shí)，候選的推薦詞通常會(huì)超過這個(gè)限制，因此通過資產(chǎn)的瀏覽熱度來排序可以提高搜索推薦的準(zhǔn)確率，改善用戶的搜索體驗(yàn)。

（2）時(shí)序問題。一次搜索過程中會(huì)有一連串的搜索推薦請求，服務(wù)端會(huì)并行的處理這些請求，通常更長的輸入由于候選推薦詞更少服務(wù)端響應(yīng)反而更快，在用戶輸入較快的時(shí)候（比如連續(xù)的刪除字符），前端先發(fā)出的請求可能會(huì)后返回，因此可能造成輸入停止后推薦的詞與輸入不匹配。我們的方案是前端在根據(jù)服務(wù)端響應(yīng)刷新數(shù)據(jù)時(shí)需要檢查返回的輸入與當(dāng)前輸入框內(nèi)容是否一致，從而保持最終一致性。?

2.聚合服務(wù)。聚合服務(wù)根據(jù)輸入和篩選項(xiàng)提供搜索過程中需要用到的統(tǒng)計(jì)數(shù)字。例如用戶希望知道搜索結(jié)果總共有多少條，每個(gè)篩選項(xiàng)下有多少個(gè)候選結(jié)果等統(tǒng)計(jì)信息，從而指導(dǎo)用戶對搜索結(jié)果進(jìn)行篩選，縮小搜索范圍。同時(shí)，每個(gè)篩選項(xiàng)下的可選項(xiàng)需要根據(jù)輸入和其它關(guān)聯(lián)的篩選值動(dòng)態(tài)生成，這部分也需要聚合服務(wù)提供。

3.搜索服務(wù)。支持核心的搜索過程，通過輸入，返回對應(yīng)的資產(chǎn)作為搜索結(jié)果。分為 4 個(gè)主要的部分。

4.預(yù)處理過程（Preprocess），主要包含對輸入的預(yù)處理和用戶信息的預(yù)處理。

（1）對輸入的預(yù)處理主要包括分詞，停用，詞性還原等基本的文本處理。分詞主要包含英文分詞和中文分詞。英文分詞需要處理-_等鏈接符分詞，中文分詞主要是用 IK 分詞器。停用主要包含各種詞如“的”，“了”，“我”和各種特殊符號(hào)“》〉？”等無意義的詞語。詞性還原是一把雙刃劍，因?yàn)?Data Catalog 中的詞語不同于一般的自然語言，有比較多的專有名詞，比如 live listing 不應(yīng)當(dāng)被還原為 live list，避免文本匹配的分?jǐn)?shù)不準(zhǔn)。同時(shí)這部分也包含對輸入中的強(qiáng) pattern 進(jìn)行識(shí)別，如"數(shù)據(jù)庫名.表名”等。

（2）對用戶信息的預(yù)處理。用戶是否為超級(jí)用戶，是否為 API 用戶等，可以借此判斷用戶常搜索的資產(chǎn)類型或從未搜索的資產(chǎn)類型。

5.召回過程（Recall），負(fù)責(zé)通過輸入和篩選項(xiàng)根據(jù)文本相關(guān)度從 Elasticsearch 查詢一定數(shù)量的搜索候選結(jié)果，供下一步精排使用。召回過程需要保證用戶期望的結(jié)果包含在召回結(jié)果中，否則后續(xù)排序優(yōu)化都是徒勞。同時(shí)，召回的數(shù)量需要限制在合理的數(shù)值。主要原因有兩點(diǎn)：一是排序靠后的搜索結(jié)果幾乎沒有用戶會(huì)查看。二是召回過多的候選結(jié)果會(huì)影響性能，尤其是排序性能消耗比較大時(shí)。我們的召回主要分為兩種方式：自然召回和強(qiáng)規(guī)則召回。

6.自然召回。對經(jīng)過預(yù)處理的輸入進(jìn)行不同資產(chǎn)類型的召回，使用 best field 的策略，對資產(chǎn)的不同字段設(shè)置不同的權(quán)重，例如命中名稱的資產(chǎn)應(yīng)當(dāng)比命中描述的資產(chǎn)優(yōu)先級(jí)高。這里的權(quán)重通常根據(jù)經(jīng)驗(yàn)設(shè)置，可以根據(jù)搜索結(jié)果的 Badcase review 得到，這個(gè)權(quán)重?cái)?shù)值的精度要求不高，確保期望的結(jié)果能召回回來即可。

7.強(qiáng)規(guī)則召回。可以定制一些規(guī)則，作為自然召回的補(bǔ)充，涵蓋精確表名的召回，或者從用戶的常用資產(chǎn)列表進(jìn)行召回。

    除此之外，還需要做好多租戶的隔離，避免當(dāng)前租戶的用戶召回其它租戶的資產(chǎn)。

（1）精排過程（Rank），負(fù)責(zé)對召回的結(jié)果進(jìn)行最終的排序。精排過程依次包含機(jī)器學(xué)習(xí)模型預(yù)測（Learning to rank）和基于規(guī)則調(diào)整兩部分。Learning to rank 部分詳細(xì)介紹見后文。

1）機(jī)器學(xué)習(xí)模型在線預(yù)測，負(fù)責(zé)主要的排序工作。加載離線訓(xùn)練得到的 PMML 模型文件，提供預(yù)測功能。

2）基于強(qiáng)規(guī)則的調(diào)整，包含排序的各種兜底策略，比較常用的有：

a.精確匹配的結(jié)果排在第一位。

b.添加 Tie-breaker，保證分?jǐn)?shù)相同的結(jié)果多次搜索的排序一致。

（2）后處理過程（Postprocess），對排好序的結(jié)果添加各種不影響順序的后處理。例如：

8.權(quán)限檢查，隱藏表設(shè)置。一些資產(chǎn)不希望被沒有相關(guān)權(quán)限的用戶查看詳情，需要在搜索結(jié)果中設(shè)置相應(yīng)字段并返回給前端。

9.高亮，對命中字段進(jìn)行高亮標(biāo)注，返回給前端。

3.2 Learning to rank

Learning to rank 主要分為數(shù)據(jù)收集，離線訓(xùn)練和在線預(yù)測三個(gè)部分。搜索系統(tǒng)是一個(gè) Data-driven system，因此系統(tǒng)設(shè)計(jì)之初就需要考慮數(shù)據(jù)收集。收集的數(shù)據(jù)可以用來評(píng)估和提升搜索的效果。數(shù)據(jù)收集和在線預(yù)測前面已有介紹，不再贅述，下面主要介紹離線訓(xùn)練部分。

離線訓(xùn)練的過程主要包括數(shù)據(jù)標(biāo)注，特征工程，模型訓(xùn)練和評(píng)估。這四個(gè)步驟并非從前往后一氣呵成，而是有可能進(jìn)行評(píng)估，發(fā)現(xiàn)不足，然后增加標(biāo)注數(shù)據(jù)，增加特征，重新訓(xùn)練，再次評(píng)估。評(píng)估效果有比較明顯的收益時(shí)，才會(huì)上線測試。

3.2.1 數(shù)據(jù)標(biāo)注

作為 Data Catalog 的搜索系統(tǒng)，不太容易獲取大規(guī)模的人工標(biāo)注數(shù)據(jù)，主要有兩個(gè)原因：一是標(biāo)注的成本較高，二是領(lǐng)域知識(shí)的專業(yè)性導(dǎo)致不容易找到合適的標(biāo)注人員。因此，我們的標(biāo)注數(shù)據(jù)來源主要有兩個(gè)：一是來自搜索日志中有點(diǎn)擊的部分，我們將這部分?jǐn)?shù)據(jù)劃分為三檔，曝光有點(diǎn)擊，曝光排名前五且未點(diǎn)擊和曝光未點(diǎn)擊，賦予不同的分?jǐn)?shù)；二是我們根據(jù)資產(chǎn)名稱結(jié)合日志中未點(diǎn)擊的輸入，基于規(guī)則生成一定的訓(xùn)練數(shù)據(jù)。

訓(xùn)練數(shù)據(jù)集需要持續(xù)更新，在 review badcase 時(shí)，可以針對需要改進(jìn)的場景添加相應(yīng)的訓(xùn)練數(shù)據(jù)。

3.2.2 特征

特征工程是一個(gè)持續(xù)的過程。經(jīng)過一系列的選取，我們系統(tǒng)的主要特征分為 4 大類型，涵蓋了搜索的文本特征，數(shù)據(jù)的權(quán)威性，用戶的個(gè)性化數(shù)據(jù)和數(shù)據(jù)的時(shí)效性。

下面列舉了一些我們用到的主要特征和分類：

• 文本特征

(1)入相關(guān)的文本特征

a.輸入長度，比如有多少個(gè)詞，總長度等等

b.輸入語言類型，中文或英文

(2)文本匹配度相關(guān)的特征?

• 基于詞袋的 CQR
• Elasticsearch 查詢返回分?jǐn)?shù)，基于 BM25
• 數(shù)據(jù)權(quán)威性
• 熱度：AssetRank, 基于資產(chǎn)的使用量和血緣關(guān)系，通過 Weighted PageRank 算法計(jì)算得到的資產(chǎn)熱度
• 元數(shù)據(jù)完整度，包含資產(chǎn)的業(yè)務(wù)元數(shù)據(jù)，如項(xiàng)目，主題，產(chǎn)品線等
• 資產(chǎn)的最近 1 天/ 7 天/ 30 天的全平臺(tái)使用總次數(shù)
• 資產(chǎn)所處的生命周期：如上線，待下線，廢棄等
• 資產(chǎn)的總點(diǎn)贊數(shù)
• 用戶個(gè)性化數(shù)據(jù)，分為三大類：
• 靜態(tài)個(gè)性化數(shù)據(jù)

(1)負(fù)責(zé)人：當(dāng)前用戶是否是該資產(chǎn)的負(fù)責(zé)人

(2)收藏：當(dāng)前用戶是否收藏了該資產(chǎn)

(3)點(diǎn)贊：當(dāng)前用戶是否點(diǎn)贊了該資產(chǎn)

• 歷史搜索查詢行為數(shù)據(jù)
• 當(dāng)前用戶歷史上最近 1 天/ 7 天/ 30 天全平臺(tái)使用該資產(chǎn)的次數(shù)
• 當(dāng)前用戶歷史上最近 1 天/ 7 天/ 30 天在 Data Catalog 平臺(tái)查詢點(diǎn)擊該資產(chǎn)的次數(shù)
• 協(xié)同數(shù)據(jù)
• 同部門人員歷史上最近 1 天/ 7 天/ 30 天在 Data Catalog 平臺(tái)查詢點(diǎn)擊該資產(chǎn)的次數(shù)
• 當(dāng)前用戶歷史上最近 1 天/ 7 天/ 30 天在 Data Catalog 平臺(tái)查詢點(diǎn)擊該資產(chǎn)所屬部門所有資產(chǎn)的次數(shù)
• 當(dāng)前用戶歷史上最近 1 天/ 7 天/ 30 天在 Data Catalog 平臺(tái)查詢點(diǎn)擊該資產(chǎn)所屬負(fù)責(zé)人所有資產(chǎn)的次數(shù)
• 數(shù)據(jù)實(shí)效性，用戶會(huì)更傾向于使用最近創(chuàng)建或者有數(shù)據(jù)更新到資產(chǎn)
• 資產(chǎn)創(chuàng)建時(shí)間
• 資產(chǎn)數(shù)據(jù)等最近更新時(shí)間等?

  3.2.3 模型

Learning to rank 通常有三類方法：Pointwise，Pairwise 和 Listwise。這三類方法各有優(yōu)缺點(diǎn)，細(xì)節(jié)介紹如下：

• Pointwise，對每個(gè)輸入，對每個(gè)召回的資產(chǎn)單獨(dú)打分（通常是 Regression），然后按照分?jǐn)?shù)進(jìn)行排序。

(1)優(yōu)點(diǎn)：簡單直觀。

(2)缺點(diǎn)：排序?qū)嶋H上不需要對資產(chǎn)進(jìn)行精確打分，這類方法沒有考慮召回資產(chǎn)之間的互相關(guān)系，考慮到用戶在一組資產(chǎn)中只會(huì)點(diǎn)擊其中一個(gè)，排名靠后的和排名靠前的資產(chǎn)在損失函數(shù)上的貢獻(xiàn)沒有體現(xiàn)。

• Pairwise，對每個(gè)輸入，考慮召回結(jié)果中所有資產(chǎn)的二元組合<資產(chǎn) 1, 資產(chǎn) 2>, 采取分類模型，預(yù)測兩個(gè)資產(chǎn)的相對排序關(guān)系。

(1)優(yōu)點(diǎn)：基于點(diǎn)擊與原有相關(guān)性分?jǐn)?shù)排序標(biāo)注簡單，相比 pointwise 考慮到選項(xiàng)之間關(guān)系。

(2)缺點(diǎn)：同樣沒有考慮排序前后順序的重要性不同，樣本生成復(fù)雜，開銷大。對異常標(biāo)注敏感，錯(cuò)誤點(diǎn)影響范圍大。

• Listwise，考慮給定輸入下的召回資產(chǎn)集合的整體序列，優(yōu)化整個(gè)序列，通常使用 NDCG 作為優(yōu)化目標(biāo)。

(1)優(yōu)點(diǎn)：優(yōu)化整個(gè)序列，考慮序列內(nèi)資產(chǎn)之間的關(guān)系。

(2)缺點(diǎn)：單條樣本訓(xùn)練量大。樣本過少，則無法對所有樣本預(yù)測得到好的效果。

我們對 Pointwise 和 Listwise 都做了實(shí)驗(yàn)，最終我們的系統(tǒng)采用了 Listwise 的方案。主要原因是在我們的標(biāo)注方式下，Listwise 的方案更容易標(biāo)注。具體實(shí)現(xiàn)上我們采用了 LightGBM 的框架。

3.2.4 評(píng)估

我們使用了 NDCG，AUC 和驗(yàn)證點(diǎn)擊率的方式對模型進(jìn)行評(píng)估。

• NDCG，歸一化折損累計(jì)增益。NDCG 是推薦和搜索中比較常用的評(píng)估方法，用來整體評(píng)估排序結(jié)果的準(zhǔn)確性。
• AUC，AUC 主要反映排序能力的相對性，用于在正負(fù)樣本不均衡的情況衡量離線模型擬合情況。
• 重放有點(diǎn)擊歷史數(shù)據(jù)的點(diǎn)擊率，使用待評(píng)估的模型預(yù)測有點(diǎn)擊的歷史輸入，排序后得到 Top3, Top5, Top10 點(diǎn)擊率作為參考。這種方式比較直觀，缺點(diǎn)是不能反映出在無點(diǎn)擊歷史數(shù)據(jù)上的效果。

3.3 衡量指標(biāo)

搜索服務(wù)變更或新模型上線后，我們需要對線上搜索的真實(shí)效果進(jìn)行衡量。目前我們主要通過搜索的點(diǎn)擊率和 Top3 點(diǎn)擊率來衡量。由于 Data Catalog 搜索的特殊性，我們更看重模糊搜索的總體點(diǎn)擊率和 Top3 點(diǎn)擊率（輸入和資產(chǎn)名稱完全一致的為精確搜索，其它為模糊搜索）。

實(shí)際上，點(diǎn)擊率并非越高越好，過高的點(diǎn)擊率可能意味著:

• 搜索結(jié)果頁透出的信息過少，用戶不得不點(diǎn)擊結(jié)果進(jìn)入資產(chǎn)詳情，即使只想查看一些簡單的信息。
• 用戶在系統(tǒng)上探索的興趣較小，只搜熟悉的資產(chǎn)或者確定能搜到的輸入。

當(dāng)然過低的點(diǎn)擊率意味著較差的搜索體驗(yàn)。因此，點(diǎn)擊率保持在一定健康的區(qū)間后，我們也需要關(guān)注模糊搜索和精確搜索的占比等指標(biāo)。

4. 其它模式

除了個(gè)性化的搜索需求，也會(huì)有一些場景，用戶不需要精細(xì)化的排序，只需要把包含相關(guān)文本的資產(chǎn)都列舉出來，因此我們也支持單純的列表模式，用戶可以在列表模式通過指定字段來對搜索結(jié)果進(jìn)行排序。我們也在規(guī)劃實(shí)現(xiàn)一些 query syntax 的功能，以此來支持用戶在列表模式下更靈活地約束輸入。

5. 后續(xù)工作

Data Catalog 系統(tǒng)的搜索功能還有很多有意義的工作值得我們繼續(xù)探索，例如：

• 血緣中的搜索。當(dāng)一個(gè)資產(chǎn)的一級(jí)下游就超過上千個(gè)時(shí)，想從當(dāng)前資產(chǎn)的眾多下游中查找到相關(guān)的資產(chǎn)并不容易，因此提供基于血緣的篩選和搜索是一個(gè)不錯(cuò)的選擇。
• 多租戶之間模型的遷移。作為支持多租戶的公有云服務(wù)，由于租戶之間數(shù)據(jù)的差異，新租戶的冷啟動(dòng)問題，以較小的數(shù)據(jù)量和成本來支持不同租戶都有好的搜索體驗(yàn)，也是一個(gè)值得挑戰(zhàn)的方向。

6. 關(guān)于我們

火山引擎大數(shù)據(jù)研發(fā)治理套件 DataLeap

一站式數(shù)據(jù)中臺(tái)套件，幫助用戶快速完成數(shù)據(jù)集成、開發(fā)、運(yùn)維、治理、資產(chǎn)、安全等全套數(shù)據(jù)中臺(tái)建設(shè)，幫助數(shù)據(jù)團(tuán)隊(duì)有效的降低工作成本和數(shù)據(jù)維護(hù)成本、挖掘數(shù)據(jù)價(jià)值、為企業(yè)決策提供數(shù)據(jù)支撐。