10年+，阿里沉淀出怎樣的搜索引擎？

阿里妹導讀：搜索引擎是阿里的10年+沉淀，具有很高的技術/業務/商業價值。1688很多場景都借助了搜索中臺的能力，基于此，以1688主搜為例介紹搜索全鏈路知識點，希望對你有所借鑒，有所啟發。

一、整體架構

搜索引擎分為數據源聚合(俗稱dump)、全量/增量/實時索引構建及在線服務等部分，以Tisplus為入口經由Bahamut（Maat進行工作流調度）->Blink->Hdfs/Swift->BuildService->Ha3->SP->SW等階段對客戶提供高可用/高性能的搜索服務。其中數據源聚合在tisplus平臺和Blink平臺完成，Build service和Ha3在suez平臺完成，SP和SW通過drogo進行部署。具體架構圖如下：

二、Tisplus

1688目前有spu、cspu，company，buyoffer和feed等引擎及offer離線在tisplus運維，該平臺主要ha3和sp的搭建和維護，大體架構如下：

在日常維護中偶爾會遇到數據源產出失敗的問題，主要是由于數據源表權限過期及zk抖動等原因。性能方面，在集團內搜索中臺團隊的引入Blink Batch模型后，dump執行時間被縮短，具體指標如下（以buyoffer引擎為例）：

在tisplus平臺，離線dump的入口如下：

DAG數據源圖示例：

下面主要說下離線dump數據源處理流程，包括Bahamut、Maat和數據輸出。

2.1 Bahamut——數據源圖處理

Bahamut是離線數據源處理的組件平臺，將web端拼接的數據圖通過jobManager翻譯成可執行的sql語句。目前Bahamut包含的組件有四類，分別是：

數據輸入：datasource（支持tddl和odps）
KV輸入：HbaseKV（Hbase數據表）
數據處理：Rename（數據字段重命名），DimTrans（使用1對多的數據聚合），Functions（簡單字段處理），Selector（字段選擇），UDTF（數據邏輯處理），Merge（數據源聚合），Join（left join）
數據輸出：Ha3（Hdfs/swift）

對數據源的處理過程，描述如下：

by 敬明

而對于Bahamut->blink過程可以陳述如下：

其中，Bahamut將任務拆解后扔給JobManager進行邏輯節點到物理節點的轉換，形成若干節點后再歸并組合成一個完整的SQL語句，例如上圖Kratos_SQL就是一個增量Join的完整SQL，配合資源文件一起通過BayesSDK提交任務。此外，平臺增加了一個弱個性化配置的功能，可以通過個性化配置來實現控制某個具體任務的并發度、節點內存、cpu等等參數。

2.2 Maat——分布式流程調度系統

Maat是基于開源項目Airflow再次開發的分布式流程調度系統，具有可視化編輯及通用的節點類型，Drogo化部署，分集群管理及完善的監控&報警機制等優點。

關于Airflow及其他工作流系統，對比陳列如下：

eed引擎為例，maat調度頁面如下：

當任務錯誤時，可以通過該頁面進行“將指定步驟置fail”然后重跑全量任務，也可以通過查看某個步驟的log獲悉任務失敗原因。

2.3 Ha3 doc——數據輸出

經過上述步驟后，最后將數據以xml的形式(isearch format)輸出到HDFS/Pangu路徑（全量）和Swift Topic（增量），引擎全量時通過HDFS路徑獲取全量doc文件進行build，增量時直接從swift topic中獲取增量更新消息更新到引擎中。離線平臺通過一個服務為Tisplus引擎模塊提供表信息的查詢等功能，以下是一個HA3表包含的信息：

{
 "1649992010": [
   {     "data": "hdfs://xxx/search4test_st3_7u/full", // hdfs路徑
     "swift_start_timestamp": "1531271322", //描述了今天增量的時間起點
     "swift_topic": "bahamut_ha3_topic_search4test_st3_7u_1",
     "swift_zk": "zfs://xxx/swift/swift_hippo_et2",
     "table_name": "search4test_st3_7u", // HA3 table name，目前與應用名稱一樣
     "version": "20190920090800” // 數據產出的時間
   }
 ]
}

三、Suez

經過上述步驟后，數據以xml(isearchformat)的格式產出到Hdfs和swift，然后通過在suez_ops平臺的離線表中選擇數據類型為zk并配置相應的zk_server和zk_path即可。

然后由Build service完成全量/增量/實時索引的構建，然后分發到Ha3在線集群提供服務。

suez的離線表構建邏輯如下：

suez在線服務邏輯如下：

下面針對離線（buildservice）和在線（ha3）進行簡述：

**3.1 Build Service——索引構建
**

Build Service(簡稱BS)是一套提供全量、增量、實時索引的構建系統
build_service總共有五類角色：

admin ：負責控制整體build流程，切換全量增量狀態，發起定期任務，響應用戶的控制請求；
processor ：負責數據處理，將用戶的原始文檔轉化為輕量級可build的文檔形態；
builder ：負責構建索引；
merger ：負責索引整理；
rtBuilder ：負責在線索引的實時構建。

其中admin、processor、builder、merger是以二進制程序的方式運行在hippo上，rtBuilder是以lib的形式提供給在線部分使用。

一個完整的全量+增量過程會產生一個generationid，該generation會經歷 process full-> builder full -> merger full ->process inc -> builder inc ->merger inc的過程，其中處于inc過程后，builder inc和merger inc會交替出現。1688在ha3升級之前經常會出現 build tooslow問題就是因為分配到了壞節點或builderinc/merger inc階段卡住。

3.2 Ha3——在線搜索服務

Ha3是一套基于suez框架的全文檢索引擎，提供豐富的在線查詢子句，過濾子句，排序子句，聚合子句且支持用戶自定義開發排序插件。服務架構如下：

1688主搜引擎由一組Qrs、searcher和summary組成：

Qrs的作用是：對輸入的查詢作解析與校驗，通過后把查詢轉發給相應的；searcher，收集合并searcher返回的結果，最后對結果做一些加工并返回給用戶。其中也可以通過寫meger插件干預合并規則；
searcher：可以是文檔的召回服務(searcher)，也可以是文檔的打分與排序服務(ranker)或者是文檔的摘要服務(summary)；
summary：1688主搜將searcher和summary分離，summary集群只提供取商品詳情的服務。

qrs/searcher/summary等機器通過掛載到cm2提供服務，比如qrs有對外cm2，可以對SP等調用方提供服務，searcher和summary有對內cm2，可以接收從qrs來的請求并完成召回排序取詳情等服務。

一次調用方的query服務，要經由qrs->query解析->seek->filter->rank(粗排)->agg(聚合)->rerank(精排)->extraRank(最終排)->merger->summary(取詳情)的過程，具體描述如下：

其中，ReRank和ExtraRank由Hobbit插件及基于Hobbit的戰馬插件完成，業務方可以根據自身需求開發戰馬特征并指定各特征權重得到商品的最終分。

四、Drogo

drogo是基于二層調度服務Carbon的無數據服務的管控平臺，1688的SP服務及QP代理服務均部署在該平臺。

1688搜索鏈路主要服務平臺部署情況簡述如下：

參考文檔：
《搜索中臺開發運維一體化實踐-Sophon》、《基于DAG的分布式任務調度平臺-Maat》、《tisplus用戶操作手冊》、《Build Service用戶手冊》、《Build Service源碼》、《Ha3 用戶手冊》、《Ha3搜索引擎簡介》、《drogo平臺介紹》、《搜索離線平臺系統架構及實現介紹》、《基于Blink Batch模式的搜索離線任務開發實踐》、《搜索離線平臺計算引擎簡介——基于Blink2.2和Bayes的演進之路》、《解密雙11實時計算每秒4.72億背后的核心技術——Blink》、《SARO用戶手冊》、《工作流引擎比較》、《Airflow簡介》、《Airflow github》

原文發布時間為：2019-09-24
作者：清剛
本文來自云棲社區合作伙伴“阿里技術”，了解相關信息可以關注“阿里技術”。