搜索引擎新架构：与SQL不得不说的故事
特邀嘉賓：羅濤--阿里巴巴集團資深技術專家
視頻地址：https://yunqi.aliyun.com/2020/session54?liveId=44647
阿里巴巴搜索引擎HA3架構
1.HA3架構分為在線和離線兩部分
? 在線是一個傳統的2層服務架構，分別叫做QRS和search。QRS負責接受用戶請求，做一些簡單處理之后把請求發給下面的search節點，search節點負責加載索引并完成檢索，最終由QRS匯集各個search節點的結果并返回給用戶。
? 離線部分分為兩個環節，一個環節是數據的預處理，其核心的工作是把業務和算法維度的數據加工成對索引友好的大寬表，另一個環節是索引的構建，它的主要挑戰是既要支持大規模的索引更新，也要保障索引是實時性。
2.HA3的特點主要有三個：
? 第一個是高性能的服務架構；
? 第二個是豐富的索引能力；
? 第三個是金字塔形的算法工作框架
這些特點是HA3在阿里巴巴集團內風靡非常有利的武器，但隨著這幾年業務的發展，這一架構逐漸成了我們再往前進一步的攔路虎。
搜索引擎HA3核心挑戰
具體體現在2個方面，一個是深度學習的滲透，另一個是數據維度的膨脹。
1. 深度學習，
它的使用范圍，從早期的精排，逐步擴散到了粗排、檢索，比如向量索引的召回。深度學習的引入本身也會帶來2個問題：一個是深度模型的本身的網絡結構通常比較復雜，對執行流程和模型大小都有非常高的要求，傳統的pipeline工作模式是非常難以有效支持的；另外一個問題是模型和特征數據的實時更新也對索引的能力提出了很大的挑戰，在線上百億級別的更新是一個常態。
2. 數據維度的膨脹，以電商領域為例，原來考慮的維度主要是買家、賣家這兩個維度，現在得考慮位置、配送、門店、履約等等，同樣是配送，有3公里5公里送的，有同城的，還有跨城的，像這樣的例子還有很多。而搜索引擎離線的工作流程會把各個維度的數據join成一張大寬表，這會導致數據更新的規模成笛卡爾積的形式展開，在新場景下，無論是更新的量級還是時效性上都很難滿足
搜索傳統解決方案
就是根據業務數據維度的特點，把引擎分拆成過多個不同的實例，然后在業務層通過查詢不同的引擎實例來得到結果。比如說餓了么的搜索引擎就有門店、商品等維度的數據，為了解決門店狀態的實時變化對索引的沖擊，可以部署兩個搜索引擎實例，一個用來搜索合適的門店，另外一個用來搜索合適的商品，由業務方先查門店引擎再查商品引擎來完成。但這個方案有一個明顯的缺點，那就是符合用戶意圖的門店非常多的時候，門店的數據需要從門店引擎序列化到業務方再發送給商品引擎，這里序列化的開銷非常大，往往需要對返回的門店數目做一定截斷，而截斷的門店中很可能有更匹配用戶意圖的，這樣對業務效果也會有比較大的影響。特別熱門的商區，不管是對用戶還是賣家，都是非常大的損失。
HA3 SQL新的解決方案
以數據庫SQL的執行方式來重塑搜索，核心要點有3條。
**1.將原來大寬表的模式擴展
成支持多表，每個表的索引加載、更新、切換做到相互獨立，把原來需要離線join的操作變成在線查詢時join。 **
2.徹底拋棄原有的pipeline的工作模式，以DAG圖化的方式來執行，并將搜索的功能抽象成一個個獨立的算子，與深度學習的執行引擎進行統一。
3.以SQL的方式來表達圖化的查詢流程，這樣不光用戶使用起來簡單，也可以復用SQL生態的一些基礎功能。舉個例子，電商個性化搜索技術里面，把商品、個性化推薦、深度模型等信息分別放到不同的表中，配合上靈活的索引格式，比如倒排索引、正排索引、KV索引等等，加上執行引擎本身可以支持并行、異步、編譯優化等技術，不管是內存還是CPU都能得到有效利用，很輕松地就能解決業務上的各種問題。
搜索引擎HA3新的架構
主要分為三層：
? 最底下一層是searchRuntime的Framework，其核心職責主要有索引管理和服務調度，其中索引部分主要是加載的策略和查詢接口，如計算存儲分離的支持、實時索引構建的支持等等；服務調度主要處理的是進程的failover和服務的更新，即通常意義的面向終態的二層調度，主要的特點是以統一的方式做進程的重啟、程序的更新、灰度的發布等等。
? 中間這一層是DAG引擎層，其核心內容有兩個，一個是執行引擎本身，另一個就是算子。這里的執行引擎主要有三部分的能力，包括單機內圖的執行，分布式的通信和深度學習，通過算子間的互聯，我們能夠很方便的把搜索的查詢流程和深度學習進行對接，實現深度學習在搜索的各個階段的滲透，如向量檢索、粗排和精排。算子部分的抽象是這輪架構抽象最重要的一環，把原來面向過程式的開發變成了獨立功能的開發，一方面要求算子本身的功能要盡可能內聚，另一方面算子級別的管理也更有利于功能的復用和發布。
? 最上面一層是SQL查詢層，核心的工作有兩部分，一個是SQL解析，另外一個是查詢優化。由于DAG的流程可以任意定制，如何讓用戶更方便地構建圖、更方便的進行算子間的協作會是很關鍵的問題，簡單、通用是個必須考慮的，這也是我們首選SQL的原因；另外一個原因是業界SQL的執行器，通常包含邏輯優化和物理優化兩個環節，這個對一個復雜的DAG的執行提供了非常好的抽象，我們也利用了這個機制來進行了很多細致的優化，包括圖的變換、算子合并、編譯優化等等。
實踐案例
1. 餓了么
外賣搜索場景的例子，假設用戶在搜索框里面輸入了一個關鍵詞"牛肉面"，搜索引擎后臺的流程大體如下：通過用戶的位置信息找到現在還在營業的、并且能賣牛肉面的門店，每個門店給出最匹配的商品，最后返回最符合用戶需求的門店與商品。在這里，門店營業情況如何、配送能力是否足夠、對應的商品有沒有賣完，這些數據都需要實時更新的，而在大規模的數據里面快速找到匹配的信息，也涉及到豐富的索引技術，比如空間索引、倒排索引、向量索引等等，最后門店和商品的排序也要依賴深度模型的參與，用戶的偏好、優惠信息、距離都是很重要的因素。原有的搜索流程是基于elasticsearch通過分別查詢門店和商品維度的表來實現的，但會有查詢結果截斷和深度學習接入困難的問題，而在HA3上這些問題都非常容易解決，遷移到新架構后，不光業務的長尾問題消失了，而且性能還提升1倍，給后續算法的迭代留下了非常大的空間，這里性能的提升主要來自于索引結構和查詢優化上的一些工作。
2.淘寶本地生活的服務
其核心的訴求也是希望在淘寶的搜索里面引入本地服務的概念，如天貓超市和盒馬的小時達的業務，通過將門店和商品維度的數據單獨分拆，不光更新能力提升了兩個數量級，還復用了餓了么搜索的很多功能。
3.釘釘的釘盤搜索
業務上需要在傳統的搜索上支持釘盤文件的權限控制，由于文件和權限這兩個維度數據的規模都非常大，而且更新比較頻繁，通過HA3SQL在線的實時本地join，非常低延遲的解決了這個問題。
4.內部監控系統
原來是基于開源技術druid構建的，但業務規模上來逐步不能滿足需求了，經常出現異常需要手動處理的情況，我們在HA3的基礎上擴展了時序數據索引，借助SQL并行執行的能力，latency有了明顯下降，穩定性也得到了質的提升。
以上就是本次云棲大會--“搜索引擎新架構：與SQL不得不說的故事”的內容。如果您對搜索與推薦相關技術感興趣，歡迎加入釘釘群內交流~
原文鏈接：https://developer.aliyun.com/article/775338?
版權聲明：本文內容由阿里云實名注冊用戶自發貢獻，版權歸原作者所有，阿里云開發者社區不擁有其著作權，亦不承擔相應法律責任。具體規則請查看《阿里云開發者社區用戶服務協議》和《阿里云開發者社區知識產權保護指引》。如果您發現本社區中有涉嫌抄襲的內容，填寫侵權投訴表單進行舉報，一經查實，本社區將立刻刪除涉嫌侵權內容。總結
以上是生活随笔為你收集整理的搜索引擎新架构：与SQL不得不说的故事的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 字节跳动 Flink 单点恢复功能实践
- 下一篇： 阿里云邀您参加2020年数据湖高峰会议