架構性能數(shù)據(jù)處理配置磁盤存儲數(shù)據(jù)統(tǒng)計流計算
摘要：今年的雙11再次刷新了記錄——支付成功峰值達25.6萬筆／秒、實時數(shù)據(jù)處理峰值4.72億條/秒。 面對較去年增幅100%的數(shù)據(jù)洪峰，流計算技術可謂功不可沒。今天，我們將揭開阿里流計算技術的神秘面紗。
雙11剛剛拉下帷幕，激動的心還停留在那一刻：
當秒針剛跨過11號零點的一瞬間，來自線上線下的千萬剁手黨在第一時間涌入了這場年度大趴——從進入會場到點擊詳情頁，再到下單付款一氣呵成。
前臺在大家狂歡的同時，后臺數(shù)據(jù)流量也正以突破歷史新高的洪峰形式急劇涌入：
支付成功峰值達 25.6 萬筆／秒
實時數(shù)據(jù)處理峰值 4.72億條/秒
而作為實時數(shù)據(jù)處理任務中最為重要的集團數(shù)據(jù)公共層（保障著業(yè)務的實時數(shù)據(jù)、媒體大屏等核心任務），在當天的總數(shù)據(jù)處理峰值更是創(chuàng)歷史新高達1.8億/秒！ 想象下，1秒鐘時間內千萬人涌入雙11會場的同時，依然應對自如。
流計算的產(chǎn)生即來源于數(shù)據(jù)加工時效性的嚴苛需求：
由于數(shù)據(jù)的業(yè)務價值會隨著時間的流失而迅速降低，因此在數(shù)據(jù)發(fā)生后必須盡快對其進行計算和處理，從而能夠通過數(shù)據(jù)第一時間掌握業(yè)務情況。今年雙11的流計算也面臨著一場實時數(shù)據(jù)洪峰的考驗。
首先來展示今年（2017年）較去年（2016年）數(shù)據(jù)洪峰峰值的比較：
2016年：支付成功峰值12萬筆/秒，總數(shù)據(jù)處理峰值9300萬/秒
2017年：支付成功峰值25.6 萬筆／秒，實時數(shù)據(jù)處理峰值 4.72億條/秒，阿里巴巴集團數(shù)據(jù)公共層總數(shù)據(jù)處理峰值1.8億/秒
在今年雙11流量峰值翻翻的情況下，依然穩(wěn)固做到實時數(shù)據(jù)更新頻率：從第1秒千萬剁手黨涌入到下單付款，到完成實時計算投放至媒體大屏全路徑，秒級響應。面對越發(fā)抬升的流量面前，實時數(shù)據(jù)卻越來越快、越來越準。在hold住數(shù)據(jù)洪峰的背后，是阿里巴巴流計算技術的全面升級。
流計算應用場景
數(shù)據(jù)技術及產(chǎn)品部定位于阿里數(shù)據(jù)中臺，除了離線數(shù)據(jù)外，其產(chǎn)出的實時數(shù)據(jù)也服務于集團內多個數(shù)據(jù)場景。包括今年（其實也是以往的任何一年）雙11媒體大屏實時數(shù)據(jù)、面向商家的生意參謀實時數(shù)據(jù)，以及面向內部高管與小二的各種直播廳產(chǎn)品，覆蓋整個阿里巴巴集團大數(shù)據(jù)事業(yè)部。
同時隨著業(yè)務的不斷發(fā)展壯大，到目前為止，日常實時處理峰值超4000萬/s，每天總處理記錄數(shù)已經(jīng)達到萬億級別，總處理數(shù)據(jù)量也達到PB級別。
面對海量數(shù)據(jù)的實時數(shù)據(jù)我們成功做到了數(shù)據(jù)延遲控制在秒級范圍內，在計算準確率上，已實現(xiàn)了高精準、0誤差，達到精確處理。比如：今年的雙11當天，雙十一媒體屏第一條記錄從交易表經(jīng)過流計算計算處理到達媒體大屏秒級響應。
數(shù)據(jù)中臺流計算實踐中的數(shù)據(jù)鏈路
在經(jīng)過最近幾年大促數(shù)據(jù)洪峰的經(jīng)歷后，使得我們的流計算團隊在引擎選擇，優(yōu)化性能以及開發(fā)流計算平臺上都積累了豐富的經(jīng)驗。我們也形成了穩(wěn)定高效的數(shù)據(jù)鏈路架構，下圖是整個數(shù)據(jù)鏈路示意圖：
業(yè)務數(shù)據(jù)的來源非常多，分別通過兩個工具（DRC與中間件的logagent）實時獲取增量數(shù)據(jù)，并且同步到DataHub（一種PubSub的服務）。
實時計算引擎Flink作業(yè)通過訂閱這些增量數(shù)據(jù)進行實時處理，并且在經(jīng)過ETL處理后把明細層再次回流到Datahub，所有的業(yè)務方都會去定義實時的數(shù)據(jù)進行多維度的聚合，匯總后的數(shù)據(jù)放在分布式數(shù)據(jù)庫或者關系型數(shù)據(jù)庫中（Hbase、Mysql），并通過公共的數(shù)據(jù)服務層產(chǎn)品（One Service）對外提供實時數(shù)據(jù)服務。
最近一年，我們在計算引擎和計算優(yōu)化方面做了很多工作，實現(xiàn)了計算能力、開發(fā)效率的提升。
計算引擎升級及優(yōu)化
在2017年，我們在實時計算架構上進行了全面的升級，從Storm遷移到Blink，并且在新技術架構上進行了非常多的優(yōu)化，實時峰值處理能力提高了2倍以上，平穩(wěn)的處理能力更是提高5倍以上：
優(yōu)化狀態(tài)管理
實時計算過程中會產(chǎn)生大量的state，以前是存儲在HBase，現(xiàn)在會存儲在RocksDB中，本地存儲減少了網(wǎng)絡開銷，能夠大幅提高性能，可以滿足細粒度的數(shù)據(jù)統(tǒng)計（現(xiàn)在key的個數(shù)可以提升到億級別了，是不是棒棒噠~）
優(yōu)化checkpoint（快照/檢查點）和compaction（合并）
state會隨著時間的流轉，會越來越大，如果每次都做全量checkpoint的話，對網(wǎng)絡和磁盤的壓力非常大；所以針對數(shù)據(jù)統(tǒng)計的場景，通過優(yōu)化rocksdb的配置，使用增量checkpoint等手段，可以大幅降低網(wǎng)絡傳輸和磁盤讀寫。
異步Sink
把sink改成異步的形式，可以最大限度提高CPU利用率，可以大幅提供TPS。
抽象公共組件
除了引擎層面的優(yōu)化，數(shù)據(jù)中臺也針對性地基于Blink開發(fā)了自己的聚合組件（目前所有實時公共層線上任務都是通過該組件實現(xiàn)）。該組件提供了數(shù)據(jù)統(tǒng)計中常用的功能，把拓撲結構和業(yè)務邏輯抽象成了一個json文件。這樣只需要在json文件中通過參數(shù)來控制，實現(xiàn)開發(fā)配置化，大幅降低了開發(fā)門檻，縮短開發(fā)周期——再來舉個栗子：之前我們來做開發(fā)工作量為10人/日，現(xiàn)在因為組件化已讓工作量降低為0.5人/日，無論對需求方還是開發(fā)方來講都是好消息，同時歸一的組件提升了作業(yè)性能。
按照上述思路及功能沉淀，最終打磨出了流計算開發(fā)平臺【赤兔】。
該平臺通過簡單的“托拉拽”形式生成實時任務，不需要寫一行代碼，提供了常規(guī)的數(shù)據(jù)統(tǒng)計組件，并集成元數(shù)據(jù)管理、報表系統(tǒng)打通等功能。作為支撐集團實時計算業(yè)務的團隊，我們在經(jīng)過歷年雙11的真槍實彈后沉淀的[赤兔平臺]中獨有的功能也成為它獨一無二的亮點：
一、大小維度合并
比如很多的實時統(tǒng)計作業(yè)同時需要做天粒度與小時粒度的計算，之前是通過兩個任務分開計算的，聚合組件會把這些任務進行合并，并且中間狀態(tài)進行共用，減少網(wǎng)絡傳輸50%以上，同時也會精簡計算邏輯，節(jié)省CPU。
二、精簡存儲
對于存儲在RocksDB的Keyvalue，我們設計了一個利用索引的encoding機制，有效地將state存儲減少一半以上，這個優(yōu)化能有效降低網(wǎng)絡、cpu、磁盤的壓力。
三、高性能排序
排序是實時中非常常見的一個場景， top組件利用內存中PriorityQueue（優(yōu)先隊列） 和blink中新的MapState feature（中間狀態(tài)管理特性），大幅減少序列化次數(shù)，性能提高10倍左右。
四、批量傳輸和寫操作
最終寫結果表HBase和Datahub時，如果每處理一條記錄都去寫庫的話，就會很大限制我們的吞吐。我們組件通過時間觸發(fā)或者記錄數(shù)觸發(fā)的機制（timer功能），實現(xiàn)批量傳輸和批量寫（mini-batch sink），并且可以根據(jù)業(yè)務延時要求進行靈活配置，提高任務吞吐的同時，也降低了服務端壓力。
數(shù)據(jù)保障
對于高優(yōu)先級應用（每天24小時不間斷服務），需要做到跨機房容災，當某條鏈路出現(xiàn)問題時，能夠秒級切換到其他鏈路，下圖是整個實時公共層的鏈路保障架構圖：
從數(shù)據(jù)采集、數(shù)據(jù)同步、數(shù)據(jù)計算、數(shù)據(jù)存儲、數(shù)據(jù)服務，整條鏈路都是獨立的。通過在Oneservice中的動態(tài)配置，能夠實現(xiàn)鏈路切換，保障數(shù)據(jù)服務不終端。
上面內容就是保障今年雙11流量洪峰的流計算技術秘密武器——我們不僅在于創(chuàng)新更希望能沉淀下來復用、優(yōu)化技術到日常。
隨著流計算的技術外界也在不停更迭，后續(xù)基于阿里豐富業(yè)務場景下我們還會不斷優(yōu)化升級流計算技術：
平臺化，服務化，Stream Processing as a service
語義層的統(tǒng)一，Apache Beam，F(xiàn)link 的Table API，以及最終Stream SQL都是非常熱的project
實時智能，時下很火的深度學習或許未來會與流計算碰撞產(chǎn)生火花
實時離線的統(tǒng)一，這個也是很大的趨勢，相較于現(xiàn)在普遍存在的實時一套，離線一套的做法，實時離線的統(tǒng)一也是各大引擎努力想要達到的。
最后，歡迎大家在留言區(qū)，與我們交流討論，一起學習進步。
原文發(fā)布時間為：2017-11-21
本文作者：同杰&黃曉鋒
本文來自云棲社區(qū)合作伙伴“阿里技術”，了解相關信息可以關注“阿里技術”微信公眾號
本文為云棲社區(qū)原創(chuàng)內容，未經(jīng)允許不得轉載，如需轉載請發(fā)送郵件至yqeditor@list.alibaba-inc.com；如果您發(fā)現(xiàn)本社區(qū)中有涉嫌抄襲的內容，歡迎發(fā)送郵件至：yqgroup@service.aliyun.com 進行舉報，并提供相關證據(jù)，一經(jīng)查實，本社區(qū)將立刻刪除涉嫌侵權內容。
