第六章 大數據，6.1 雙11數據大屏背後的實時計算處理(做者：藏六 黃曉鋒 同傑)

6.1 雙11數據大屏背後的實時計算處理

1. 雙11數據大屏的實時計算架構

 

1.1 背景

2016年的雙11咱們的實時數據直播大屏有三大戰場，它們分別是面向媒體的數據大屏、面向商家端的數據大屏、面向阿里巴巴內部業務運營的數據大屏。

每個直播大屏對數據都有着很是高的精度要求，特別是面向媒體的數據大屏，同時面臨着高吞吐、低延時、零差錯、高穩定等多方面的挑戰。在雙11的24小時中，支付峯值高達12萬筆/秒，處理的總數據量高達百億，而且全部數據是實時對外披露的，因此數據的實時計算不能出現任何差錯。除此以外，全部的代碼和計算邏輯，都須要封存並隨時準備面對包括美國證監會在內的監管機構的問詢及和檢查。

在面向商家的數據直播大屏中，爲了實時觀察店鋪流量狀況，須要處理全網的全部流量數據。另外，爲了讓商家更全面更細地分析流量，增長了不少實時的數據維度，好比咱們須要計算每一個商家的訪客數量、加購數量、熱銷商品、流量來源、每一個商品的訪問狀況等等。

面向阿里巴巴內部業務運營小二的數據大屏，則提供了最爲豐富角度的數據。除了大盤數據以外，還針對不一樣業務進行了定製，如淘寶、天貓、天貓國際、天貓超市、無線、聚划算、淘海外、飛豬旅行、村淘、AliExpress、賣全球等業務模塊，每一個業務模塊還會進行各維度的交叉分析，好比行業、類目、地域等。這些數據監控了當天活動進展的方方面面，也是當天活動應急響應決策的重要依據。

以上每一個直播功能須要實時處理的數據量都是很是龐大的，每秒的總數據量更是高達億級別，這就對咱們的實時計算架構提出了很是高的要求。在面對如此龐大數據的時候，咱們的實時處理是如何作高精度、高吞吐、低延時、強保障的呢？

 

1.2 實時計算處理鏈路總體架構

DRC: DRC(Data replication center)是阿里自主研發的數據流產品，支持異構數據庫實時同步，數據記錄變動訂閱服務。爲跨域實時同步、實時增量分發、異地雙活、分佈式數據庫等場景提供產品級的解決方案。

TT:  TT(TimeTunnel)是一個高效的、可靠的、可擴展的消息通訊平臺，基於生產者、消費者和Topic模式的消息中間件。

GALAXY: Galaxy是全球領先的通用流計算平臺，支撐阿里絕大部分實時計算任務，支持專有云打包輸出。平臺易用性高、數據準確性100%、集羣線性擴展、支持容錯、支持多租戶、資源隔離。雙11流量暴增狀況下，Galaxy作到毫秒級計算延遲，知足極高穩定性要求，天天處理消息量萬億級。

OTS: 開放結構化數據服務（Open Table Service，OTS）是構建在飛天大規模分佈式計算系統之上的海量結構化和半結構化數據存儲與實時查詢的服務， OTS以數據表的形式組織數據，保證強一致性，提供跨表的事務支持，並提供視圖和分頁的功能來加速查詢。OTS適用於數據規模大且實時性要求高的應用。

 

1.3 實時計算聚合組件：XTool介紹

在實時數據統計的場景中，大部分都是根據某些維度進行去重、求和、算記錄數、求最大值、求最小值、求平均值、算排行榜等聚合計算，另外還會涉及到實時多表join、靜態維表關聯、時間窗口管理等。而storm只提供了最底層的計算算子，每一次的聚合操做、關聯操做等都是須要代碼開發的，效率很是低，而且對於實時計算中checkpoint、snapshot的存儲和恢復沒有標準化的定義。

爲了提升實時計算開發效率和下降運維成本，咱們在storm的trident語義上，把通用聚合功能封裝成了XTool組件，提供配置化定義實時計算拓撲，不須要任何的代碼編寫。另外，聚合組件還提供了重跑、續跑、exactly one等各類特性，方便修復平常運維中遇到的數據問題。XTool是一個完整的實時計算解決方案，對接了數據同步中間件（TimeTunnel）、數據儲存（HBase）、流計算引擎（storm）等，把這些系統結合起來造成一個通用的實時計算服務架構。

XTool經過xml文件來描述實時任務的拓撲結構，只須要在裏面中定義數據源輸入、聚合維度、聚合指標、輸出信息、任務監控信息等，XTool會自動解析成對應的聚合Task，並在storm集羣中提交實時任務，用戶不須要管臨時數據如何存儲、故障如何恢復、事務信息保障等細節問題。

海量數據實時處理中常常會遇到雪崩、數據傾斜、數據重複等問題，除了通用功能外，XTool經過輸入限流、自動Hash分桶、主鍵惟一化等策略來解決以上的問題。例如在遇到數據傾斜問題時，只須要配置一個標記，XTool在解析xml文件時會自動對distinct操做進行Hash分桶去重，在下層直接進行求和就能夠獲得去重指標。

高性能是實時計算中賴以生存的特性，XTool組件爲了知足百萬/秒甚至千萬/秒的qps要求，進行了大量的性能和資源調優工做。好比進行指標去重的時候支持精準去重、布隆去重、基數估計去重等模式，在業務需求和資源使用率上取得很好的平衡。另外，XTool會按照LRU（最近最少）算法緩存聚合結果在內存中，並把維度的key作成布隆集合，當新數據來的時候，能夠避免沒必要要的讀庫操做。XTool還充分利用了localOrShuffle特性（相似Hadoop中的map計算本地化），把計算移到數據存儲節點上進行，大幅減小數據序列化次數，性能提高很是顯著。

目前幾乎全部面對商家、媒體、運營小2、高管的實時計算應用都是經過XTool來實現的，其經歷了幾回雙11的考驗，表現出很是高的吞吐量和穩定性保障，功能也愈來愈豐富。後面計劃把XTool經過Apache Beam來實現，讓其再也不只能依賴storm計算引擎，能夠靈活在各個引擎間進行切換，好比Flink、Apex、Spark等。

 

1.4 OneService服務介紹

統一數據服務平臺（OneService）是數據技術及產品部-產品技術主導的，以集團數據公共層One Data提供上層應用接口依始，提供簡單數據查詢服務（承接包括公共層全部數據在內多個BU簡單數據查詢服務），複雜數據查詢服務（承接集團用戶識別（OneID）、用戶畫像（GProfile）複雜數據查詢服務），實時數據推送服務 三大特點數據服務。

• 簡單數據查詢服務：定位簡單數據查詢引擎，經過物理表、邏輯表組合綁定的方式，將具體數據來源屏蔽在引擎內部，用戶在平臺簡單配置來源表等元數據信息，即可以作到不須要依賴任何應用、代碼得到接口服務（hsf服務），目前SmartDQ支持接入數據源類型爲HBase/Mysql/Phoenix/OpenSearch；
• 複雜數據查詢服務：複雜數據查詢引擎，目前承接了集團用戶識別（OneID）、用戶畫像（GProfile）等複雜數據處理查詢；
• 實時數據推送服務：經過數據推送機制，對外提供高性能、高穩定性的JsonP/webSocket接口，提供流量和交易相關的實時數據推送服務。

OneService還重點解決了服務的高可用問題：

• 服務自己的高可用：例如多機房部署、HSF分組隔離等，這裏再也不展開。
• 查詢鏈路的快速切換能力：媒體大屏用到的GMV等指標，後臺通常都會冗餘多個計算任務，並寫入到多個HBase集羣上。若是某個集羣出現不可用或者數據延遲，須要能秒級切換到另外一個集羣上。

 

 

2. 大數據總體鏈路如何應對雙11的挑戰

 

2.1 如何進行實時任務優化

優化工做在實時計算中顯得尤其重要，若是吞吐量跟不上的話，也就失去了實時的特性。吞吐量不佳緣由很是多，有些是跟系統資源相關，有些跟實現方式相關，如下幾點是實時任務優化中常常須要考慮的要素：

• 獨佔資源和共享資源的策略：

           在一臺機器中，共享資源池子是給多個實時任務搶佔的，若是一個任務在運行時的80%以上的時間都須要去搶資源，這時候就須要考慮給它分配更多的獨佔資源，避免搶不到CPU資源致使吞吐量急劇降低。

• 合理選擇緩存機制，儘可能下降讀寫庫次數：

           內存讀寫性能是最高的，根據業務的特性選擇不一樣的緩存機制，讓最熱和最可能使用的數據放在內存，讀寫庫的次數降下來後，吞吐量天然就上升了。

• 計算單元合併，下降拓撲層級：

           拓撲結構層級越深，性能越差，由於數據在每一個節點間傳輸時，大部分是須要通過序列化和反序列的，而這個過程很是消耗CPU和時間。

• 內存對象共享，避免字符拷貝：

           海量數據處理中，大部分對象都是以字符串存在的，在不一樣線程間合理共享對象，能夠大幅下降字符拷貝帶來的性能消耗，不過要注意不合理使用帶來的內存溢出問題。

• 高吞吐和低延時間取平衡：

          這兩個特性是一對矛盾體，當把多個讀寫庫操做或者ACK操做合併成一個的時候，能夠大幅下降由於網絡請求帶來的消耗，不過也會致使延時會高一些，在業務上衡量作二者的取捨。

 

2.2 如何進行數據鏈路保障

實時數據的處理鏈路很是長（數據同步->數據計算->數據儲存->數據服務），每個環節出現問題，都會致使實時數據中止更新。實時計算屬於分佈式計算的一種，而單個節點故障是常態的，這種狀況在直播大屏中特別明顯，由於數據已經再也不更新了，全部的客戶都會發現數據出現了問題。所以，爲了保障實時數據的可用性，須要對整條計算鏈路都進行多鏈路搭建，作到多機房容災，甚至異地容災。

因爲形成鏈路問題的狀況比較多，而且通常不能在秒級裏面定位到緣由，所以會經過工具比對多條鏈路計算的結果數據，當某條鏈路出現問題時，必定會比其餘鏈路計算的值小，而且差別會愈來愈大。這時候會一鍵切換到備鏈路，而且經過推送配置的形式讓其秒級生效，全部的接口調用會馬上切到備鏈路，對直播大屏徹底透明，而且用戶也感知不到故障的發生。

 

2.3 如何進行壓測

在雙十一備戰中，會對實時鏈路進行屢次壓測，主要是模擬雙十一的峯值狀況，驗證系統是否可以正常運行。壓測都是在線上環境進行的，這裏面分爲數據壓測和產品壓測，數據壓測主要是蓄洪壓測。相似大壩中把幾個小時甚至幾天的數據積累下來，並在某個時刻所有放開，達到模擬雙十一洪峯流量的狀況，這裏面的數據屬於真實的數據。好比經過把實時做業的訂閱數據點位調到幾個小時或者幾天前，這時候每一批讀到的數據是最多的，對實時計算的壓力也最大。

產品壓測還細分爲產品自己的壓測和前端頁面穩定性測試：

• 產品壓測：

           經過收集大屏服務端的全部讀操做的url，經過PAP壓測平臺進行壓測流量回放，按照QPS：500次/每秒 的目標進行壓測。在過程當中不斷的迭代優化服務端的性能，提高大屏應用處理數據的性能。

• 前端頁面穩定性：

           將大屏頁面在瀏覽器打開，並進行8小時到24小時的前端穩定性測試。監控大屏前端js對客戶端瀏覽器的內存、CPU等消耗。檢測出前端js內存泄漏等問題並fix，提高前端頁面的穩定性。

    

3. 架構升級，如何更輕鬆應對將來的雙11

流式計算是對批處理的一個補充，其中最重要的特色就是實時性，而隨着業務的增加，實時計算須要處理的數據也會隨着增加，所以，吞吐量的提高是實時計算中最大的挑戰。除此以外，下降開發成本、提高運維效率也是咱們一直追求的目標，讓實時計算技術給更多的業務場景提供價值。

咱們會經過架構升級、底層計算引擎優化、業務邏輯優化等方式來突破實時計算的性能瓶頸，力求把實時計算的性能提升一個數量級。另外，後面計劃把XTool移植到Apache Beam (Google Dataflow)上面，並嘗試底層不一樣引擎的Beam Runner （Flink，Apex，Gearpump等新開源流計算技術以及阿里巴巴本身的Galaxy），封裝數據統計的流計算開發產品（圖形化定義流計算拓撲結構），讓其保持良好的可移植性；同時讓流計算開發對 ETL開發人員更友好，下降流計算的開發成本；增強阿里巴巴在開源社區的影響力。