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