整體架構(gòu)

?

火山引擎DataLeap的Catalog搜索系統(tǒng)使用了開(kāi)源的搜索引擎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)變更消息，通過(guò)ingestion服務(wù)更新Elasticsearch中的文檔，以此來(lái)達(dá)到搜索實(shí)時(shí)性秒級(jí)的需求。

2. 離線導(dǎo)入。實(shí)時(shí)導(dǎo)入的過(guò)程中可能會(huì)遇到網(wǎng)絡(luò)波動(dòng)等不可控因素導(dǎo)致更新失敗，因此需要定時(shí)的任務(wù)來(lái)檢查和增量更新缺失的元數(shù)據(jù)。

3. 用戶(hù)行為記錄。記錄用戶(hù)搜索點(diǎn)擊日志，用來(lái)后續(xù)進(jìn)行搜索的Badcase review和模型訓(xùn)練?；鹕揭鍰ataLeap的Catalog系統(tǒng)這部分采用了前端埋點(diǎn)和服務(wù)端埋點(diǎn)結(jié)合的方式。前端埋點(diǎn)有成熟的內(nèi)部框架，埋點(diǎn)數(shù)據(jù)流入離線數(shù)倉(cāng)表，缺點(diǎn)是這部分?jǐn)?shù)據(jù)要經(jīng)過(guò)離線任務(wù)T+1才能使用。服務(wù)端埋點(diǎn)數(shù)據(jù)直接進(jìn)入Elasticsearch，即時(shí)可用，同時(shí)在不支持前端埋點(diǎn)的場(chǎng)景（如ToB場(chǎng)景），可以成為主要的埋點(diǎn)數(shù)據(jù)收集方式。

4. 線上搜索服務(wù)。提供搜索相關(guān)的線上服務(wù)，在后文詳細(xì)解釋這部分。

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

?

上圖是線上搜索服務(wù)的主要組件圖?；鹕揭鍰ataLeap的Catalog系統(tǒng)的整個(gè)搜索服務(wù)分為三個(gè)大的服務(wù)：搜索推薦服務(wù)、聚合服務(wù)和搜索服務(wù)。

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

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

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

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

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

  • 預(yù)處理過(guò)程（Preprocess），主要包含對(duì)輸入的預(yù)處理和用戶(hù)信息的預(yù)處理。

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

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

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

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

    • 自然召回。對(duì)經(jīng)過(guò)預(yù)處理的輸入進(jìn)行不同資產(chǎn)類(lèi)型的召回，使用best field的策略，對(duì)資產(chǎn)的不同字段設(shè)置不同的權(quán)重，例如命中名稱(chēng)的資產(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é)果能召回回來(lái)即可。

    • 強(qiáng)規(guī)則召回?？梢远ㄖ埔恍┮?guī)則，作為自然召回的補(bǔ)充，涵蓋精確表名的召回，或者從用戶(hù)的常用資產(chǎn)列表進(jìn)行召回。

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

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

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

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

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

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

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

    • 高亮，對(duì)命中字段進(jìn)行高亮標(biāo)注，返回給前端。文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-490487.html

到了這里，關(guān)于火山引擎DataLeap的Catalog系統(tǒng)搜索實(shí)踐 （二）：整體架構(gòu)的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！