轉載自??揭秘阿里秒級百萬TPS平臺架構實現

導讀：搜索離線數據處理是一個典型的海量數據批次/實時計算結合的場景，阿里搜索中臺團隊立足內部技術結合開源大數據存儲和計算系統，針對自身業務和技術特點構建了搜索離線平臺，提供復雜業務場景下單日批次處理千億級數據，秒級實時百萬TPS吞吐的計算能力。

?

背景

什么是搜索離線？

一個典型的商品搜索架構如下圖所示，本文將要重點介紹的就是下圖中的離線數據處理系統（Offline System）。

何謂離線？在阿里搜索工程體系中我們把搜索引擎、在線算分、SearchPlanner等ms級響應用戶請求的服務稱之為“在線”服務；與之相對應的，將各種來源數據轉換處理后送入搜索引擎等“在線”服務的系統統稱為“離線”系統。商品搜索的業務特性（海量數據、復雜業務）決定了離線系統從誕生伊始就是一個大數據系統，它有以下一些特點：

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等常用的數據處理組件，業務表與處理組件結合在一起就能夠描述常見的離線業務處理邏輯。

?

那么如何把這個Business Graph轉化為真正的離線任務呢？Bahamut作為離線平臺的執行引擎，會按照Business Graph->APP Graph->Job Graph->(Blink Job/Maat Job)的順序把一個業務描述轉化為可執行的離線任務，具體如下：

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）平臺會逐步成型。

?

總結

以上是生活随笔為你收集整理的揭秘阿里秒级百万TPS平台架构实现的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。