摘要

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 實現的。除此之外，還有兩個問題需要重點考慮：

1. 基於瀏覽的熱度排序。頁面上能夠推薦的詞數是有限的，通常是 10 個，在輸入較短時，候選的推薦詞通常會超過這個限制，因此通過資產的瀏覽熱度來排序可以提高搜尋推薦的準確率，改善使用者的搜尋體驗。

2. 時序問題。一次搜尋過程中會有一連串的搜尋推薦請求，伺服器端會並行的處理這些請求，通常更長的輸入由於候選推薦詞更少伺服器端響應反而更快，在使用者輸入較快的時候（比如連續的刪除字元），前端先發出的請求可能會後返回，因此可能造成輸入停止後推薦的詞與輸入不匹配。我們的方案是前端在根據伺服器端響應重新整理資料時需要檢查返回的輸入與當前輸入框內容是否一致，從而保持最終一致性。

 

• 聚合服務。聚合服務根據輸入和篩選項提供搜尋過程中需要用到的統計數位。例如使用者希望知道搜尋結果總共有多少條，每個篩選項下有多少個候選結果等統計資訊，從而指導使用者對搜尋結果進行篩選，縮小搜尋範圍。同時，每個篩選項下的可選項需要根據輸入和其它關聯的篩選值動態生成，這部分也需要聚合服務提供。

• 搜尋服務。支援核心的搜尋過程，通過輸入，返回對應的資產作為搜尋結果。分為 4 個主要的部分。

A：預處理過程（Preprocess），主要包含對輸入的預處理和使用者資訊的預處理。

1. 對輸入的預處理主要包括分詞，停用，詞性還原等基本的文書處理。分詞主要包含英文分詞和中文分詞。英文分詞需要處理-_等連結符分詞，中文分詞主要是用 IK 分詞器。停用主要包含各種詞如「的」，「了」，「我」和各種特殊符號「》〉？」等無意義的詞語。詞性還原是一把雙刃劍，因為 Data Catalog 中的詞語不同於一般的自然語言，有比較多的專有名詞，比如 live listing 不應當被還原為 live list，避免文字匹配的分數不準。同時這部分也包含對輸入中的強 pattern 進行識別，如"資料庫名.表名」等。

2. 對使用者資訊的預處理。使用者是否為超級使用者，是否為 API 使用者等，可以藉此判斷使用者常搜尋的資產型別或從未搜尋的資產型別。

B：召回過程（Recall），負責通過輸入和篩選項根據文字相關度從 Elasticsearch 查詢一定數量的搜尋候選結果，供下一步精排使用。召回過程需要保證使用者期望的結果包含在召回結果中，否則後續排序優化都是徒勞。同時，召回的數量需要限制在合理的數值。主要原因有兩點：一是排序靠後的搜尋結果幾乎沒有使用者會檢視。二是召回過多的候選結果會影響效能，尤其是排序效能消耗比較大時。我們的召回主要分為兩種方式：自然召回和強規則召回。

1. 自然召回。對經過預處理的輸入進行不同資產型別的召回，使用 best field 的策略，對資產的不同欄位設定不同的權重，例如命中名稱的資產應當比命中描述的資產優先順序高。這裡的權重通常根據經驗設定，可以根據搜尋結果的 Badcase review 得到，這個權重數值的精度要求不高，確保期望的結果能召回回來即可。

2. 強規則召回。可以客製化一些規則，作為自然召回的補充，涵蓋精確表名的召回，或者從使用者的常用資產列表進行召回。

 除此之外，還需要做好多租戶的隔離，避免當前租戶的使用者召回其它租戶的資產。

C：精排過程（Rank），負責對召回的結果進行最終的排序。精排過程依次包含機器學習模型預測（Learning to rank）和基於規則調整兩部分。Learning to rank 部分詳細介紹見後文。

• 機器學習模型線上預測，負責主要的排序工作。載入離線訓練得到的 PMML 模型檔案，提供預測功能。

  基於強規則的調整，包含排序的各種兜底策略，比較常用的有：

  精確匹配的結果排在第一位。

  新增 Tie-breaker，保證分數相同的結果多次搜尋的排序一致。

D：後處理過程（Postprocess），對排好序的結果新增各種不影響順序的後處理。例如：

• 許可權檢查，隱藏表設定。一些資產不希望被沒有相關許可權的使用者檢視詳情，需要在搜尋結果中設定相應欄位並返回給前端。

  高亮，對命中欄位進行高亮標註，返回給前端。

Learning to rank

 

Learning to rank 主要分為資料收集，離線訓練和線上預測三個部分。搜尋系統是一個 Data-driven system，因此係統設計之初就需要考慮資料收集。收集的資料可以用來評估和提升搜尋的效果。資料收集和線上預測前面已有介紹，不再贅述，下面主要介紹離線訓練部分。

離線訓練的過程主要包括資料標註，特徵工程，模型訓練和評估。這四個步驟並非從前往後一氣呵成，而是有可能進行評估，發現不足，然後增加標註資料，增加特徵，重新訓練，再次評估。評估效果有比較明顯的收益時，才會上線測試。

資料標註

作為 Data Catalog 的搜尋系統，不太容易獲取大規模的人工標註資料，主要有兩個原因：一是標註的成本較高，二是領域知識的專業性導致不容易找到合適的標註人員。因此，我們的標註資料來源主要有兩個：一是來自搜尋紀錄檔中有點選的部分，我們將這部分資料劃分為三檔，曝光有點選，曝光排名前五且未點選和曝光未點選，賦予不同的分數；二是我們根據資產名稱結合紀錄檔中未點選的輸入，基於規則生成一定的訓練資料。

訓練資料集需要持續更新，在 review badcase 時，可以針對需要改進的場景新增相應的訓練資料。

特徵

特徵工程是一個持續的過程。經過一系列的選取，我們系統的主要特徵分為 4 大型別，涵蓋了搜尋的文字特徵，資料的權威性，使用者的個性化資料和資料的時效性。

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

• 文字特徵

1. 輸入相關的文字特徵

• 輸入長度，比如有多少個詞，總長度等等

• 輸入語言型別，中文或英文

2. 文字匹配度相關的特徵

• 基於詞袋的 CQR

• Elasticsearch 查詢返回分數，基於 BM25

• 資料權威性

1. 熱度：AssetRank, 基於資產的使用量和血緣關係，通過 Weighted PageRank 演演算法計算得到的資產熱度

2. 後設資料完整度，包含資產的業務後設資料，如專案，主題，產品線等

3. 資產的最近 1 天/7 天/30 天的全平臺使用總次數

4. 資產所處的生命週期：如上線，待下線，廢棄等

5. 資產的總點贊數

• 使用者個性化資料，分為三大類

1. 靜態個性化資料

• 負責人：當前使用者是否是該資產的負責人

  收藏：當前使用者是否收藏了該資產

  點贊：當前使用者是否點讚了該資產

2. 歷史搜尋查詢行為資料

• 當前使用者歷史上最近 1 天/7 天/30 天全平臺使用該資產的次數

  當前使用者歷史上最近 1 天/7 天/30 天在 Data Catalog 平臺查詢點選該資產的次數

3. 協同資料

• 同部門人員歷史上最近 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 瞭解詳情