天天看點

火山引擎DataLeap的Data Catalog系統搜尋實踐 (上)

作者:位元組跳動資料平台
更多技術交流、求職機會,歡迎關注位元組跳動資料平台微信公衆号,回複【1】進入官方交流群

摘要

火山引擎大資料研發治理套件 DataLeap的Data Catalog系統通過彙總群組織各種中繼資料,解決了資料生産者梳理資料、資料消費者找數和了解數的業務場景,其中搜尋是Data Catalog的主要功能之一。本文詳細介紹了火山引擎DataLeap的Data Catalog系統的搜尋功能的設計與實作。

背景

Data Catalog能夠幫助大公司更好地梳理和管理自己的資産,是Data-drvien公司的重要平台。一個通用的Data Catalog平台通常包含中繼資料管理,搜尋,血緣,标簽,術語等功能。其中,搜尋是Data Catalog的入口功能,承擔着讓使用者“找到數”的主要能力。在火山引擎DataLeap的Data Catalog系統中,每天有70%以上的使用者會使用搜尋功能。

功能要求

業界主要的Augmented Data Catalog需要支援Google一樣的搜尋體驗來搜尋資料資産,以滿足不同角色的使用者的找數需求。火山引擎DataLeap的Data Catalog系統也一樣,搜尋需要支援的主要功能包括:

  • 支援多種不同類型資産的搜尋。目前系統中已經包含15+種資料源,可以分為幾大類:數倉表比如Hive,看闆,資料集,實時表,Topic,對象存儲,分布式檔案系統如LasFS等。帶來的主要挑戰是不同類型的資産,搜尋的字段和權重有明顯差異。
  • 支援個性化。目前系統的使用者遍布整個公司,角色涵蓋資料工程師,資料分析師,産品經理,項目經理,銷售和資料科學家等等,需要完成的資料工作任務差異也比較大,比如資料開發,資料治理,BI,資料分析和機器學習等等,是以個性化對Data Catalog的搜尋尤為重要。
  • 支援各種業務中繼資料的進階篩選。資料資産除了名稱/别名/描述等字段,通常還會有一些業務中繼資料,如項目/業務域/負責人/負責人部門/标簽/業務術語/生命周期狀态等。通過支援指定業務中繼資料進行篩選,幫助使用者減小搜尋範圍,更快搜到對應資産。
  • 支援秒級的實時性。這裡的實時性是指中繼資料的變更需要在秒級别反映到Data Catalog的搜尋裡,例如建立表需要在操作完成後1~2秒内即能搜到相應的表,删除表需要不再顯示在搜尋結果中。原因是使用者建立或更新資産後通常會到我們的系統上檢視相應的變更是否生效。使用者手動在浏覽器操作搜尋的時間通常是秒級,超過這個時間會給使用者帶來困惑,降低整個Data Catalog的使用體驗。
  • 支援Google類似的搜尋推薦(Type as you search)功能。搜尋補全功能是搜尋的一個導航功能,可以在使用者鍵入内容時提示他們可以輸入的相關内容,進而提高搜尋精度。這個功能對響應速度有一定的要求,同時由于資料資産的特殊性,字首相同的資産數量較多,是以也需要根據資産的熱度進行一定的排序。
  • 支援多租戶。我們的系統不僅供公司内部使用,也提供公有雲服務,是以支援多租戶也是搜尋的一個P0需求。
  • 支援多語言。資料資産的名稱/描述/标簽/術語等需要支援多種語言,搜尋的輸入也可能是不同的語言,最常用的比如英文和中文。不同語言的分詞,專有名詞字典,文本特征等都會帶來一些挑戰。

個性化的綜合搜尋

為了滿足上述需求,火山引擎DataLeap的Data Catalog的系統采用了個性化綜合搜尋的方案。差別于聯合搜尋(federated search),使用者需要指定搜尋的具體資産類型或在搜尋結果頁對不同的資産分欄顯示,綜合搜尋(unified search)允許使用者在一個搜尋框中進行搜尋輸入而無需指定搜尋的資産類型,同時,搜尋服務會在同一個搜尋結果頁傳回不同類型的相關資産,并根據比對程度和使用者的個性化資料進行混合排序。優勢是能給不同的使用者針對不同資産的搜尋需求提供統一的搜尋體驗,同時提供了使用者跨類型圈定資産的能力。另外,綜合搜尋使得我們可以在頁面上進行标準化透出,進而我們可以從技術上進行搜尋标準化,達到新資料源接入即可搜尋。

架構

整體架構

火山引擎DataLeap的Data Catalog系統搜尋實踐 (上)

火山引擎DataLeap的Data Catalog的搜尋系統使用了開源的搜尋引擎Elasticsearch進行基礎的文檔檢索(Recall階段),是以各種資産中繼資料會被存放到Elasticsearch中。整個系統包括4個主要的資料流程:

  1. 實時導入。資産中繼資料變更時相應的平台發出實時變更消息,Data Catalog系統會消費變更消息,通過ingestion服務更新Elasticsearch中的文檔,以此來達到搜尋實時性秒級的需求。
  2. 離線導入。實時導入的過程中可能會遇到網絡波動等不可控因素導緻更新失敗,是以需要定時的任務來檢查和增量更新缺失的中繼資料。
  3. 使用者行為記錄。記錄使用者搜尋點選日志,用來後續進行搜尋的Badcase review和模型訓練。這部分采用了前端埋點和服務端埋點結合的方式。前端埋點有成熟的内部架構,埋點資料流入離線數倉表,缺點是這部分資料要經過離線任務T+1才能使用。服務端埋點資料直接進入Elasticsearch,即時可用,同時在不支援前端埋點的場景(如ToB場景),可以成為主要的埋點資料收集方式。
  4. 線上搜尋服務。提供搜尋相關的線上服務,在後文詳細解釋這部分。

服務架構

火山引擎DataLeap的Data Catalog系統搜尋實踐 (上)

上圖是線上搜尋服務的主要元件圖。整個搜尋服務分為三個大的服務:搜尋推薦服務、聚合服務和搜尋服務。

  • 搜尋推薦服務(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模型檔案,提供預測功能。
  • 基于強規則的調整,包含排序的各種兜底政策,比較常用的有:
  1. 精确比對的結果排在第一位。
  2. 添加Tie-breaker,保證分數相同的結果多次搜尋的排序一緻。

後處理過程(Postprocess),對排好序的結果添加各種不影響順序的後處理。例如:

  • 權限檢查,隐藏表設定。一些資産不希望被沒有相關權限的使用者檢視詳情,需要在搜尋結果中設定相應字段并傳回給前端。
  • 高亮,對命中字段進行高亮标注,傳回給前端。

點選跳轉大資料研發治理套件-火山引擎了解更多

繼續閱讀