從HA3到AI·OS -- 全圖化引擎破繭之路

全圖化引擎

由來

作為一個草根出生，有着近10年發展的搜尋引擎，HA3有着老古董系統都具備的優缺點，功能經典且穩定，系統複雜而難用。在發展的過程中，HA3通過一個個性能和穩定性的成績在集團内遍地開花，豐富的定制化能力使得能支援不同的業務場景，至今仍有近5年前版本線上上穩定運作。但阿裡的業務發展更快，推薦、個性化、機器學習、人工智能等技術的大力發展，正常搜尋和推薦業務迎來了新的變革，使用過搜尋服務的同學大都聽過搜尋事業部其他的線上技術元件，如iGraph、RTP、DII等，正是這些新生的系統填補了搜尋和推薦其他場景的空白，他們跟HA3一樣，有着豐富的索引能力、實時處理能力，并具備高可用和高可運維性，同時自助化服務的能力也有大幅的進步，這些相近的能力底層在過年的兩年得到了充分整合，并誕生的名叫

suez

架構的東西。suez架構不僅是搜尋技術的集大成者，而且以一個通用的抽象友善使用者定義自己的服務，因為使用者可以直接得到前面提到的各種好處，而在服務本身上也沒有什麼限制，另外一方面suez和底層一層排程系統hippo/sigma的結合，使得服務一上線就具備極好的failover處理能力和資源豐富的在離線混部環境。例如基于suez建構的BE，僅花了2~3個月就完成了系統從無到有的過程，出道便擁有了搜尋沉澱了多年的底層能力，逐漸成為了推薦系統的中流砥柱。

不過基于HA3/BE/RTP/iGraph/DII這些系統開發的使用者來說，suez帶來的好處可能體感沒那麼強烈，相反會有很多的困惑。首先各個服務的用途和局限是很難界定的，其次相同的功能在不同的系統實作和使用不一緻，再者當同時需要組合各個系統的功能時開發成本很高，而且每個新系統的出現對存量使用者來說就意味這遷移成本。倘若繼續挖掘，再找幾個類似的問題應該不難，那麼問題出在哪裡呢？而對這些系統的開發人員來說，suez像一個潘多拉魔盒，一打開就一發不可收拾，它把最核心的能力都開放了出來，把最複雜的問題都收斂了進去，讓功能開發在不同系統上沒有了壁壘，沒有什麼功能在自己的系統上是不能做的，HA3上可以支援BE的多表查詢能力、RTP可以支援QP(DII) Query分析的能力、BE可以支援HA3插件定制的能力...是的，隻要開發人員願意，隻要他的客戶真心有需求，他一定可以得到他想要的。原來的集團軍聯合作戰部隊變成了垂直作戰小組，短期内項目可能會收獲比較好的支援，但長期的協作關系被破壞了，每個團隊核心職責需要重新定位，但誰來規定職責的邊界呢？

可以想見，沒有人能來定義這個邊界，實作客戶需求可是天經地義的，而且搜尋的代碼同享機制在此時成了催化劑，不同系統是能很友善複制其他系統的功能，盡管大家支援的使用者是同一撥人，但可能最終的用法會不一樣，會出現大量“膠水”代碼，而代碼的不一緻往往會導緻參數配置、運維管控接口等不一緻，這種不一緻會随着系統的累加被不斷放大，大到大家會認為他們天生就是不一樣的。造輪子的人會被客戶的認可一直往前推，而忘記了初心，最終的結局可能是大家一起變得平庸。

天無絕人之路，重回初心的最好的方法就是回歸到團隊使命："為客戶提供最先進的資訊組織和擷取技術，幫助客戶取得業務上的成功"，如何從技術上取得突破，得到那條正确的路？線上系統的架構統一一直以來就是大家的夢想，完成suez架構的那最後一公裡，解決好這個問題就可以形成更好的合作網絡。于是，全圖化引擎誕生了，這裡有一個更高大上的名字，AI·OS(Artificial Intelligence Online Serving)。全圖化引擎，以搭積木的方式提供服務，通過組合一個個獨立的子功能(算子)，以标準的方式串聯，進而形成滿足各式各樣需求的線上系統。它沒有固定的流程，HA3/RTP/BE變成流程的特例，它是去中心化的，任何符合串聯标準的流程和算子都能很友善的插入和對接，它是充分共享的，有複用價值的算子都是透明可見的。在這種松耦合的協作中，開發團隊的職責變成了産出高品質的算子和抽象業務特定領域的資料模型，通過和算子倉庫中的算子對接，支援複雜的業務需求。

特性

從前面的叙述中，我們不難發現有些術語跟tensorFlow(下面簡稱tf)很像，其實是因為我們内部深度使用了tf，這對習慣了自研的技術的同學們，在一開始選型的時候大家還是很糾結的。一是算子化的思路本來一直就有，二是對tf在生産環境穩定性存疑，三是正常搜尋領域的功能算子偏複雜，不太可能一上來就拆分到很細小的粒度，算子規模不大，對tf架構本身的依賴并不強。不過環境會教大家做人，tf在搜尋和推薦領域的成功有目共睹，BE/HA3上的使用者都在想辦法往這個領域靠，RTP在生産上運用tf支撐了很多業務需求，異構計算對算法同學帶來了極大幫助，瑕不掩瑜，最終我們決定使用tf作為單機内部的執行引擎。是以全圖化引擎最明顯的特性之一即是和tf算子的無縫對接，生來便具備向量計算優化、異構計算支援、異步并行架構、網絡靈活可拆分等tf原生功能，極大友善使用者定義具有AI屬性的服務。

全圖化引擎第二個特性是定義了支援線上查詢的服務的架構(suez turing framework)，對應到前面HA3/BE/RTP的查詢部分，至此算是初步完成了suez架構的閉合。有人給架構起了個膽大包天的名字turing，雖然噤若寒蟬的人居多，但這個名字還是在開發同學們間傳開了，姑且看做是對前輩的敬意和對自己的鞭策。suez架構簡要包括如下圖幾個部分：

suez架構主要包含兩大塊，一塊是suez Admin，主要負責執行suez服務生命周期内的各種操作，包括create/read/update/delete等，是串聯各基礎服務的核心元件；另一塊是suez worker服務，包含圖中的suez framework/turing framework/suez turing worker這3層結構，其中suez framework是基礎，響應suez Admin的各種操作，同時提供一個業務查詢的入口，即上層turing framework相關的部分。

suez turing framework主要邏輯部分組成：

1. IndexReader 支援包括倒排表、輔表、子表、KV表、KKV表等豐富的存儲引擎。
2. WorkerResource 主要是架構對底層suez能力的一些抽象以及對象生命周期的管理，也是不同算子間隐性互動的橋梁。 
3. Tf Graph Excutor 封裝tf執行架構，可以作為tf的預測服務運作；内置圖查詢架構，支援arpc通信，友善分布式圖的建構和通路；提供通用的trace和metric機制，便于算子的調試與監控；支援多biz(多種圖執行個體)機制，一種輕量級的複用方式，友善多租戶的方式提供服務。 
4. Basic Ops 公共算子倉庫，HA3/RTP/BE通用算子集中營，是不同業務方互相借力的地方。
5. Cava Plugins 提供通用的UDF(User Define Function)能力，并内置一些通用的處理元件，包括score/sort/function等，同時支援jit能力，讓使用者開發的插件有一個較好的性能起點。

在具體的業務(suez turing worker)層面，如BE/IGRAPH/HA3/RTP等，開發者需要關心的子產品和要實作的核心邏輯包括：

1. Biz GraphDef 即定義執行的查詢的流程圖，使用者可以建構不同的圖支援不一樣的業務。
2. Biz Configurate 定制服務需要加載的配置、指令行參數、心跳資訊、程序可共享的資源等
3. Compatible Request/Response 用來相容老的查詢接口或者支援不同的查詢接口，将其對接到tf Graph的輸入輸出。

suez turing framework中有很多HA3/RTP功能的沉澱，主要是為了友善使用者編寫自己的服務(suez turing worker)，而不用花時間在一些基礎的功能上，suez turing worker的開發者也可以更多的關注自己的需求，即如何建構查詢流程，可以腦補下場景：在草稿紙上畫圖，開發需要補充的算子或者插件，再用python構造tf圖，把圖更新後就能驗證查詢結果了。

全圖化引擎的第三個特性是支援線上查詢的分布式建構。作為一個線上的服務，必須是要追求高性能的，而在一個查詢流程中，不同的算子的開銷往往是不一緻的，這就要求能站在全流程和整個生命周期的角度來建構這個服務。如淘寶搜尋場景，使用者的一次搜尋請求，會包含使用者畫像的生成、Query的了解、商品資訊的搜尋、個性化排序等不同的環節，每個環節對機器的要求和自身的開銷都是很不一樣的。有的依賴複雜的算法離線訓練任務，有的依賴實時更新鍊路，有的依賴大規模的索引建構，有的需要使用GPU/FPGA，有的需要大記憶體，有的需要高IOPS等。簡單的無狀态服務顯然不能滿足需求，suez平台提供了有狀态服務的管理，但不同環節間需要大量的人力協同，而全圖化引擎提供了一個更宏觀的解決方案，它将服務間的對接變成算子間的協作，而不失全局視角，簡言之：以查詢的整個鍊路進行構圖，以子產品的内聚程度進行圖分割，以資源的利用效率進行部署，以通用的算子進行服務串接。在推薦的多個場景，我們将業務調用不同服務并組合的代碼下沉到底層算子中，不僅節省了網絡中資料多次轉發開銷，還讓後端服務有了在存儲上做更細緻的優化的可能。

期待

從HA3到AI·OS，大半年的時間，10萬行級代碼的翻騰，在颠覆自己的同時我們對未來也有了更多期待，相比過去的積累，AI·OS才剛起步，有太多的東西需要去完善，要不怎麼迎接下一個五年。從代碼的複用到算子的複用，心路曆程可謂一言難盡，我們希望這樣的成長也能傳遞給使用者，對大部分希望借力AI·OS的同學來說，底層算子本身并不關鍵，關鍵的是業務模型的抽象與沉澱，而這種更高層次的複用定才是提升組織的協作效率的關鍵。在搜尋挖坑多年，能深刻了解使用者基于底層子產品建構服務的痛楚，也深刻感受到能持之以恒做一件事情的幸運，而“既要、也要、還要”的氛圍下，如何在滿足業務需求的情況下還能造有價值的輪子是個極有挑戰的事情，AI OS提供這麼一種解法，複用其他團隊的輪子時盡可能簡單，鍛造自身領域的輪子時盡可能徹底，讓業務疊代和持續內建聚焦到局部功能而不是整個軟體版本。