字節跳動數據中臺的 Data Catalog 系統搜索實踐
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 個主要的數據流程：
- 實時導入。?資產元數據變更時相應的平臺發出實時變更消息，Data Catalog 系統會消費變更消息，通過 ingestion 服務更新 Elasticsearch 中的文檔，以此來達到搜索實時性秒級的需求。
- 離線導入。?實時導入的過程中可能會遇到網絡波動等不可控因素導致更新失敗，因此需要定時的任務來檢查和增量更新缺失的元數據。
- 用戶行為記錄。?記錄用戶搜索點擊日志，用來后續進行搜索的 Badcase review 和模型訓練。這部分采用了前端埋點和服務端埋點結合的方式。前端埋點有成熟的內部框架，埋點數據流入離線數倉表，缺點是這部分數據要經過離線任務 T+1 才能使用。服務端埋點數據直接進入 Elasticsearch，即時可用，同時在不支持前端埋點的場景（如 ToB 場景），可以成為主要的埋點數據收集方式。
- 線上搜索服務。?提供搜索相關的線上服務，在后文詳細解釋這部分。
3.1.2 服務架構
上圖是線上搜索服務的主要組件圖。整個搜索服務分為三個大的服務：搜索推薦服務、聚合服務和搜索服務。
1.搜索推薦服務（Type as you search）。搜索推薦服務對性能有一定的要求，通常來說補全的請求完成時間不能超過 200ms，超過了用戶就會有比較明顯的延遲感。因此不能直接使用搜索接口實現，我們的系統里是基于 Elasticsearch 的 Context suggester 實現的。除此之外，還有兩個問題需要重點考慮：
（1）基于瀏覽的熱度排序。頁面上能夠推薦的詞數是有限的，通常是 10 個，在輸入較短時，候選的推薦詞通常會超過這個限制，因此通過資產的瀏覽熱度來排序可以提高搜索推薦的準確率，改善用戶的搜索體驗。
（2）時序問題。一次搜索過程中會有一連串的搜索推薦請求，服務端會并行的處理這些請求，通常更長的輸入由于候選推薦詞更少服務端響應反而更快，在用戶輸入較快的時候（比如連續的刪除字符），前端先發出的請求可能會后返回，因此可能造成輸入停止后推薦的詞與輸入不匹配。我們的方案是前端在根據服務端響應刷新數據時需要檢查返回的輸入與當前輸入框內容是否一致，從而保持最終一致性。?
2.聚合服務。聚合服務根據輸入和篩選項提供搜索過程中需要用到的統計數字。例如用戶希望知道搜索結果總共有多少條，每個篩選項下有多少個候選結果等統計信息，從而指導用戶對搜索結果進行篩選，縮小搜索范圍。同時，每個篩選項下的可選項需要根據輸入和其它關聯的篩選值動態生成，這部分也需要聚合服務提供。
3.搜索服務。支持核心的搜索過程，通過輸入，返回對應的資產作為搜索結果。分為 4 個主要的部分。
4.預處理過程（Preprocess），主要包含對輸入的預處理和用戶信息的預處理。
（1）對輸入的預處理主要包括分詞，停用，詞性還原等基本的文本處理。分詞主要包含英文分詞和中文分詞。英文分詞需要處理-_等鏈接符分詞，中文分詞主要是用 IK 分詞器。停用主要包含各種詞如“的”，“了”，“我”和各種特殊符號“》〉？”等無意義的詞語。詞性還原是一把雙刃劍，因為 Data Catalog 中的詞語不同于一般的自然語言，有比較多的專有名詞，比如 live listing 不應當被還原為 live list，避免文本匹配的分數不準。同時這部分也包含對輸入中的強 pattern 進行識別，如"數據庫名.表名”等。
（2）對用戶信息的預處理。用戶是否為超級用戶，是否為 API 用戶等，可以借此判斷用戶常搜索的資產類型或從未搜索的資產類型。
5.召回過程（Recall），負責通過輸入和篩選項根據文本相關度從 Elasticsearch 查詢一定數量的搜索候選結果，供下一步精排使用。召回過程需要保證用戶期望的結果包含在召回結果中，否則后續排序優化都是徒勞。同時，召回的數量需要限制在合理的數值。主要原因有兩點：一是排序靠后的搜索結果幾乎沒有用戶會查看。二是召回過多的候選結果會影響性能，尤其是排序性能消耗比較大時。我們的召回主要分為兩種方式：自然召回和強規則召回。
6.自然召回。對經過預處理的輸入進行不同資產類型的召回，使用 best field 的策略，對資產的不同字段設置不同的權重，例如命中名稱的資產應當比命中描述的資產優先級高。這里的權重通常根據經驗設置，可以根據搜索結果的 Badcase review 得到，這個權重數值的精度要求不高，確保期望的結果能召回回來即可。
7.強規則召回。可以定制一些規則，作為自然召回的補充，涵蓋精確表名的召回，或者從用戶的常用資產列表進行召回。
除此之外，還需要做好多租戶的隔離，避免當前租戶的用戶召回其它租戶的資產。
（1）精排過程（Rank），負責對召回的結果進行最終的排序。精排過程依次包含機器學習模型預測（Learning to rank）和基于規則調整兩部分。Learning to rank 部分詳細介紹見后文。
1）機器學習模型在線預測，負責主要的排序工作。加載離線訓練得到的 PMML 模型文件，提供預測功能。
2）基于強規則的調整，包含排序的各種兜底策略，比較常用的有：
a.精確匹配的結果排在第一位。
b.添加 Tie-breaker，保證分數相同的結果多次搜索的排序一致。
（2）后處理過程（Postprocess），對排好序的結果添加各種不影響順序的后處理。例如：
8.權限檢查，隱藏表設置。一些資產不希望被沒有相關權限的用戶查看詳情，需要在搜索結果中設置相應字段并返回給前端。
9.高亮，對命中字段進行高亮標注，返回給前端。
3.2 Learning to rank
Learning to rank 主要分為數據收集，離線訓練和在線預測三個部分。搜索系統是一個 Data-driven system，因此系統設計之初就需要考慮數據收集。收集的數據可以用來評估和提升搜索的效果。數據收集和在線預測前面已有介紹，不再贅述，下面主要介紹離線訓練部分。
離線訓練的過程主要包括數據標注，特征工程，模型訓練和評估。這四個步驟并非從前往后一氣呵成，而是有可能進行評估，發現不足，然后增加標注數據，增加特征，重新訓練，再次評估。評估效果有比較明顯的收益時，才會上線測試。
3.2.1 數據標注
作為 Data Catalog 的搜索系統，不太容易獲取大規模的人工標注數據，主要有兩個原因：一是標注的成本較高，二是領域知識的專業性導致不容易找到合適的標注人員。因此，我們的標注數據來源主要有兩個：一是來自搜索日志中有點擊的部分，我們將這部分數據劃分為三檔，曝光有點擊，曝光排名前五且未點擊和曝光未點擊，賦予不同的分數；二是我們根據資產名稱結合日志中未點擊的輸入，基于規則生成一定的訓練數據。
訓練數據集需要持續更新，在 review badcase 時，可以針對需要改進的場景添加相應的訓練數據。
3.2.2 特征
特征工程是一個持續的過程。經過一系列的選取，我們系統的主要特征分為 4 大類型，涵蓋了搜索的文本特征，數據的權威性，用戶的個性化數據和數據的時效性。
下面列舉了一些我們用到的主要特征和分類：
- 文本特征
(1)入相關的文本特征
a.輸入長度，比如有多少個詞，總長度等等
b.輸入語言類型，中文或英文
(2)文本匹配度相關的特征?
- 基于詞袋的 CQR
- Elasticsearch 查詢返回分數，基于 BM25
- 數據權威性
- 熱度：AssetRank, 基于資產的使用量和血緣關系，通過 Weighted PageRank 算法計算得到的資產熱度
- 元數據完整度，包含資產的業務元數據，如項目，主題，產品線等
- 資產的最近 1 天/ 7 天/ 30 天的全平臺使用總次數
- 資產所處的生命周期：如上線，待下線，廢棄等
- 資產的總點贊數
- 用戶個性化數據，分為三大類：
- 靜態個性化數據
(1)負責人：當前用戶是否是該資產的負責人
(2)收藏：當前用戶是否收藏了該資產
(3)點贊：當前用戶是否點贊了該資產
- 歷史搜索查詢行為數據
- 當前用戶歷史上最近 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），然后按照分數進行排序。
(1)優點：簡單直觀。
(2)缺點：排序實際上不需要對資產進行精確打分，這類方法沒有考慮召回資產之間的互相關系，考慮到用戶在一組資產中只會點擊其中一個，排名靠后的和排名靠前的資產在損失函數上的貢獻沒有體現。
- Pairwise，對每個輸入，考慮召回結果中所有資產的二元組合<資產 1, 資產 2>, 采取分類模型，預測兩個資產的相對排序關系。
(1)優點：基于點擊與原有相關性分數排序標注簡單，相比 pointwise 考慮到選項之間關系。
(2)缺點：同樣沒有考慮排序前后順序的重要性不同，樣本生成復雜，開銷大。對異常標注敏感，錯誤點影響范圍大。
- Listwise，考慮給定輸入下的召回資產集合的整體序列，優化整個序列，通常使用 NDCG 作為優化目標。
(1)優點：優化整個序列，考慮序列內資產之間的關系。
(2)缺點：單條樣本訓練量大。樣本過少，則無法對所有樣本預測得到好的效果。
我們對 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
一站式數據中臺套件，幫助用戶快速完成數據集成、開發、運維、治理、資產、安全等全套數據中臺建設，幫助數據團隊有效的降低工作成本和數據維護成本、挖掘數據價值、為企業決策提供數據支撐。
