阿里如何實現秒級百萬TPS？搜索離線大數據平台架構解讀
來自專欄我是程序員
20 人贊了文章
背景
什麼是搜索離線？
一個典型的商品搜索架構如下圖所示，本文將要重點介紹的就是下圖中的離線數據處理系統（Offline System）。
1. 任務模型上區分全量和增量
1）全量是指將搜索業務數據全部重新處理生成，並傳送給在線引擎，一般是每天一次。這麼做有兩個原因：有業務數據是daily更新；引擎需要全量數據來高效的進行索引整理和預處理，提高在線服務效率。
2）增量是指將上游數據源實時發生的數據變化更新到在線引擎中。
3）性能方面有較高要求。全量需要極高吞吐能力，確保數以億計的數據可以在數小時內完成。增量則需要支持數萬TPS秒級的實時性，還需要有極高的可用性。
2. 需要支持多樣化的輸入和輸出數據源，包括：Mysql，ODPS，TT等各種資料庫和消息隊列作為輸入，搜索、Ranking、圖、推薦等各種引擎作為輸出。
3. 需要提供一定能力的數據處理能力，例如多表Join、UDTF支持等，以方便搜索業務的開發和接入。
在後續的段落中我們會看到離線系統架構圍繞著這些特點，針對搜索業務的變化，做出的各種演進和發展。
發展簡介
阿里商品搜索體系肇始於淘寶搜索，大約在2008年初第一代搜索系統誕生，離線系統隨之上線。搜索離線系統經歷多年發展，技術架構幾經迭代，數據處理能力、業務支持能力不斷提升。下面會分階段介紹搜索離線的主要技術架構和特點。
淘寶搜索階段
在2008-2012這個階段，我們重點支持淘寶搜索的業務發展，隨著淘寶商品量的不斷增加，逐步引入Hadoop、Hbase等開源大數據計算和存儲框架，實現了搜索離線系統的分散式化，有力地支持了淘寶搜索業務的發展。但是在這個階段，我們支持的業務線只有淘系合計不到5個業務線，為此投入了大約10名開發人員，整體效率不高。另一方面相關係統框架代碼與淘系業務高度耦合，量身定製了很多特殊代碼，不利於架構的推廣和其它業務的支持。
組件&平台化階段
2013年底以來，特別是最近兩年，隨著集團技術業務線的梳理以及中台化戰略的推行，搜索離線系統需要為越來越多的不同業務團隊（飛豬、釘釘、1688、AE、Lazada等等）提供支持，技術框架復用、開發效率提升和平台化支持的需求越來越強烈。另一方面隨著大數據計算、存儲技術的發展，尤其是流計算引擎的飛速發展，離線系統技術架構上的進一步演進也具備了絕佳的土壤。
離線平台技術架構
上一節我們簡要介紹了離線系統的發展歷史，也簡要提到技術架構的演進，下面將會把離線平台的技術架構展開介紹，主要分為平台流程以及計算和存儲架構等幾個方面。
平台組件和任務流程
上圖描述了離線平台技術組件結構，其中部分組件的簡介如下：
● Maat：分散式任務調度平台，基於Airflow發展而來，主要改進點是調度性能優化、執行器FaaS化、容器化、API及調度功能擴展等四個部分，在保持對Airflow兼容的基礎上，大幅提升性能，提高了穩定性。 一個離線任務的多個Blink job會通過Maat建立依賴關係並進行調度。
● Bahamut：執行引擎，是整個離線平台的核心，負責離線任務的創建、調度、管理等各種功能，後文會詳細介紹。
● Blink：Flink的阿里內部版本，在大規模分散式、SQL、TableAPI、Batch上做了大量的優化和重構。離線平台的所有計算任務都是Blink job，包括stream和batch。
● Soman：UI模塊，與Bahamut後端對接，提供任務信息展示、狀態管理等可視化功能，也是用戶創建應用的開發業務邏輯的主要入口。
● Catalog： 存儲表信息管理，提供各種數據源表的DDL能力，負責離線平台存儲資源的申請、釋放、變更等各種功能。
● Hippo：阿里搜索自研的分散式資源管理和任務調度服務，類似於Yarn，提供Docker管理能力，主要服務於在線系統。
● Swift：阿里搜索自研高性能分散式消息隊列，支持億級別消息吞吐能力，存儲後端為HDFS，存儲計算分離架構。
下圖則描述了一個離線任務從數據源到產出引擎服務數據的整個過程，流程圖分成三層：
● 數據同步層：將用戶定義的數據源表的全量和增量數據同步到Hbase內部表，相當於源表的鏡像。這個鏡像中我們包含cf和d兩個列族，分別存儲資料庫的鏡像和Daily更新的數據。
● 數據關聯計算層：按照數據源中定義的各種關係，將不同維度的數據關聯到一起，把數據送到自定義的UDTF中進行處理，產出引擎所需的全量和增量數據。
● 數據交互層：提供全量和增量數據的存儲信息，與在線服務build模塊進行交互。
全增量統一的計算模型
那麼如何實現對用戶屏蔽離線平台內部的這些技術細節，讓用戶只需要關注業務實現呢？回顧第一節介紹的離線任務概念，離線任務包含全量和增量，它們業務邏輯相同，但是執行模式上有區別。為了讓用戶能夠專註業務邏輯的開發，屏蔽離線平台技術細節實現全增量統一的計算邏輯，我們引入了Business Table（業務表）的概念。
Business Table（業務表）：Business Table是一個抽象表，由一個全量數據表和/或一個增量流表組成，全量/增量表的Schema相同，業務含義相同。
基於業務表和數據處理組件，用戶可以開發出一個描述離線處理流程的業務邏輯圖，我們稱之為Business Graph。下圖就是一個Business Graph的樣例，其中上側紅框標識的就是只包含ODPS全量數據源的Business Table，最下方紅框中標識的是包含Hdfs+Swift的Business Table，除此之外我們還支持Mysql+DRC/ODPS+Swift等多種業務表的組合。圖中還可以看到Join、UDTF等常用的數據處理組件，業務表與處理組件結合在一起就能夠描述常見的離線業務處理邏輯。
1. Business Graph->APP Graph：在這個環節中我們主要有2個重要的工作：
1）正確性校驗：根據BG中的節點信息，校驗節點間連接的合法性（例如兩個輸入源節點不能直接連接）、節點配置的正確性（資料庫配置/ODPS的配置是否正確）、Schema推導是否正確。
2）任務分層優化：為了用Blink Stream模式來統一完成全量和增量的執行，我們需要將輸入源數據存入內部Hbase，直接使用Blink維表Join功能來完成數據的連接。於是在節點遍歷過程中遇到Join、Merge組件時，需要在AppGraph中插入一個內部的HTable節點，將Merge或者Join上游的數據同步進入Hbase。
2. APP Graph->Job Graph：JobGraph是一個Blink/Maat任務的配置DAG，其中每個節點包含配置信息，可以在後續的過程中直接轉化為計算或者調度任務。
1）Blink JobGraph：從數據源業務表節點開始遍歷AppGraph，每當碰到一個內部HTable節點時，會生成兩個（增量/全量）同步層的Blink JobGraph。所有同步層Blink JobGraph生成後，以所有的內部HTable/queue為輸入，生成兩個（增量/全量）關聯處理層的Blink JobGraph。
①同步層：採用Business Table中的全量/增量表配置，分別生成全量和增量的Blink任務配置，描述把數據從數據源同步到內部HTable過程。例如對於Mysql+DRC的表，全量階段將會從mysql中拉取全表數據並轉化為HFile bulkload到HTable中，增量階段則是從DRC中拉取變化數據，直接寫入HTable，並根據需求寫入驅動queue。
②關聯處理層：關聯多個HTable，生成大寬表後調用UDTF處理，產出最終的進入引擎的數據。同樣需要分別生成全量和增量任務配置
2)Maat JobGraph：基於Maat的調度任務描述DAG，主要目的是將各個層次的Blink任務按照依賴進行調度，同時執行特定的腳本完成與外部系統的交互等職責。一般來說一個離線任務會生成Build/Publish/Stop/Release等多個Maat JobGraph。
3. Job Graph->Blink/Maat Job：遍歷JobGraph，調用Translator將JobGraph轉換為Blink/Maat的任務代碼。引入JobGraph的目的是將底層的計算引擎與計算任務描述解耦，例如：我們底層的計算引擎曾經是MapReduce +Blink-1.4-TableAPI，最近剛完成了Blink-2.1 基於SQL的升級，我們所有的工作基本上是重寫了一套Translator，對上層的代碼結構沒有任何變動。
經過了上述的三個步驟，我們完成了BusinessGraph（業務描述）到Blink/Maat job的轉化，生成了若干數據同步/處理的Blink job，以及將這些Blink job進行依賴調度的完成不同功能的Maat job。特別的針對搜索離線的場景，在調度流程中加入了大量與下游引擎交互的邏輯，包括24小時不間斷增量、觸發引擎消費數據、切換引擎消費增量queue等重要的業務流程。
存儲與計算
基於Hbase的存儲架構
搜索離線大約在2012年即引入了Hbase作為數據的存儲引擎，有力的支持了搜索業務從淘寶主搜到離線平台的整個發展歷程，歷經多次雙11考驗，穩定性和性能都得到明確的驗證。從功能層面，搜索離線引入Hbase的原因主要是以下幾點：
● 通過Scan/Get可以批量/單條的獲取數據，通過bulkload/put可以批量/單條的導入數據，這與搜索的全量/增量模型完全吻合，天然適合支持搜索離線業務。
● 底層存儲基於HDFS，LSM-Tree的的架構能夠確保數據安全性，計算存儲分離的架構保證了集群規模水平可擴展，易於提高整體的吞吐。通過單機性能優化（Async、BucketCache、Handler分層、Offheap）和集群的擴容，確保了業務大幅增長時，存儲從來沒有成為系統的瓶頸。
● Free Schema的特性能夠很好的應對業務數據頻繁變化的情況，也能夠方便支持一些特殊業務場景的數據邏輯。
通過引入Hbase做為離線系統的內部數據存儲，我們成功解決了每天全量時對上游Mysql造成很大壓力的問題，大幅度的提升了整體系統的吞吐。數據存儲到Hbase也是全量任務向流式處理流程轉型（MR->Stream）的基礎，而這一點為後來Blink流引擎在搜索離線的孕育和發展也埋下了伏筆。
當然Hbase也不是毫無缺點，JVM內存管理的痼疾、單機Handler打滿導致雪崩、缺乏容器化部署能力等也帶來了不少煩惱，很快我們就會替換Hbase為阿里內部發展的另外一套存儲引擎，期望能夠部分的解決這些問題。
基於Flink的計算架構
2016年中，搜索離線逐漸開始引入Flink作為計算引擎，重點解決搜索實時計算場景碰到的大量問題。在社區Flink版本的基礎上，實時計算團隊開發了Blink，增加原生yarn模式、Incremetal checkpoint等若干解決Flink大規模分散式運行問題的特性，另一方面，在DataStream/DataSet介面的基礎上，進一步加強了TableAPI和SQL的功能，真正統一了Stream和Batch的調用介面，並實現計算業務邏輯的sql化開發模式。
離線平台是Blink的早期使用者和開發者，從0.8版本開始經歷了多個Blink版本的升級和變遷，先後使用了DataStream、TableAPI和SQL作為任務介面，同時也開發了大量Connector以支持不同數據源之間的交互。目前離線平台已經在使用最新的Blink-2.1.1，Bahamut利用SqlTranslator直接生成SQL來描述任務邏輯，通過Bayes（Blink SQL開發平台）服務化直接提交任務到不同的Yarn集群，這樣做有以下幾個明顯的優勢：
● 採用SQL來描述Blink任務業務邏輯非常清晰，可以直接利用Blink提供的各種Operator完成數據處理，方便任務的調試，例如：dim join、groupby，而不是在Datastream時期需要自行編寫完成類似Hbase Join的Operator。
● Blink 2.1原生支持Batch，採用Batch模式可以直接完成生成HFile的任務，下線MR任務，徹底統一計算引擎到Blink。Batch模式任務執行時採用分階段調度可以大幅的節省計算資源，提高集群效率。Blink SQL可以通過修改提交模式，分別轉化為Stream或Batch任務，在保持業務邏輯穩定的同時方便任務調試和驗證。
● 通過Bayes這樣的開發平台服務化的方式提交任務到不同集群，徹底解決以前任務通過GateWay提交運維複雜的問題，添加新的Yarn集群只需要簡單配置即可完成。另外在Bayes上同樣會保存Bahamut自動生成提交的Sql，可以在Bayes上直接進行任務的調試和管理，方便了開發人員。
下圖是一個Bahamut自動生成的Blink Sql樣例，描述同步層的一個任務，任務中包含Source，Select Oper和Sink三個Operator，實現從Mysql實時變化到Hbase表的同步。
-- 定義數據源表，這是一個DRC（Mysql binlog流）源
CREATE TABLE DRCSource_1 ( `tag_id` VARCHAR, `act_info_id` VARCHAR,) with (tableFactoryClass=com.alibaba.xxx.xxx.DRCTableFactory, -- other config);-- 定義輸出表 CREATE TABLE HbaseSink_1 ( `tag_id` VARCHAR, `act_info_id` VARCHAR,) with (class=com.alibaba.xxx.xxx.CombineSink,hbase_tableName=bahamut_search_tmall_act, -- other config );-- 定義Blink任務的業務邏輯INSERT INTO HbaseSink_1SELECT `tag_id`, `act_info_id`,FROM DRCSource_1;
總結
搜索離線數據處理是一個典型的海量數據批次/實時計算結合的場景，搜索中台團隊立足內部技術結合開源大數據存儲和計算系統，針對自身業務和技術特點構建了搜索離線平台，提供複雜業務場景下單日批次處理千億級數據，秒級實時百萬TPS吞吐的計算能力。離線平台目前支持了集團內200多個不同業務線的搜索業務需求，大幅提高了業務迭代的效率，成為搜索中台的重要組成部分。很快離線平台還會在阿里雲上與Opensearch/ES結合，為集團外客戶提供高可用、高性能的搜索離線數據處理能力。在不遠的將來離線平台將會逐漸拓展到推薦和廣告的數據處理場景，有著廣闊的應用場景，一個涵蓋搜索/推薦/廣告體系的SARO（Search Advertisment and Recommandation Offline）平台會逐步成型。
本文作者：崑崙
原文鏈接
更多技術乾貨敬請關注云棲社區知乎機構號：阿里云云棲社區 - 知乎
本文來自雲棲社區合作夥伴「阿里技術」，如需轉載請聯繫原作者。
推薦閱讀：