apache flink 和 apache storm 是當前業界廣泛使用的兩個分布式實時計算框架。其中 apache storm（以下簡稱「storm」）在美團點評實時計算業務中已有較為成熟的運用（可參考 storm 的可靠性保證測試），有管理平台、常用 api 和相應的文件，大量實時作業基於 storm 構建。而 apache flink（以下簡稱「flink」）在近期倍受關注，具有高吞吐、低延遲、高可靠和精確計算等特性，對事件視窗有很好的支援，目前在美團點評實時計算業務中也已有一定應用。
為深入熟悉了解 flink框架，驗證其穩定性和可靠性，評估其實時處理效能，識別該體系中的缺點，找到其效能瓶頸並進行優化，給使用者提供最適合的實時計算引擎，我們以實踐經驗豐富的 storm 框架作為對照，進行了一系列實驗測試 flink 框架的效能，計算 flink 作為確保「至少一次」和「恰好一次」語義的實時計算框架時對資源的消耗，為實時計算平台資源規劃、框架選擇、效能調優等決策及 flink 平台的建設提出建議並提供資料支援，為後續的 sla 建設提供一定參考。
flink 與 storm 兩個框架對比：
評估不同場景、不同資料壓力下 flink 和 storm 兩個實時計算框架目前的效能表現，獲取其詳細效能資料並找到處理效能的極限；了解不同配置對 flink 效能影響的程度，分析各種配置的適用場景，從而得出調優建議。
「輸入-輸出」簡單處理場景
通過對「輸入-輸出」這樣簡單處理邏輯場景的測試，盡可能減少其它因素的干擾，反映兩個框架本身的效能。
同時測算框架處理能力的極限，處理更加複雜的邏輯的效能不會比純粹「輸入-輸出」更高。
使用者作業耗時較長的場景
如果使用者的處理邏輯較為複雜，或是訪問了資料庫等外部元件，其執行時間會增大，作業的效能會受到影響。因此，我們測試了使用者作業耗時較長的場景下兩個框架的排程效能。
視窗統計場景
精確計算場景（即訊息投遞語義為「恰好一次」）
storm 僅能保證「至多一次」 (at most once) 和「至少一次」 (at least once) 的訊息投遞語義，即可能存在重**送的情況。有很多業務場景對資料的精確性要求較高，希望訊息投遞不重不漏。flink 支援「恰好一次」(exactly once) 的語義，但是在限定的資源條件下，更加嚴格的精確度要求可能帶來更高的代價，從而影響效能。因此，我們測試了在不同訊息投遞語義下兩個框架的效能，希望為精確計算場景的資源規劃提供資料參考。
吞吐量（throughput）
延遲（latency）為 storm 和 flink 分別搭建由 1 台主節點和 2 臺從節點構成的 standalone 集群進行本次測試。其中為了觀察 flink 在實際生產環境中的效能，對於部分測內容也進行了 on yarn 環境的測試。
資料生產
datagenerator 按特定速率生成資料，帶上自增的 id 和 eventtime 時間戳寫入 kafka 的乙個 topic（topicdata）。
資料處理
storm task 和 flink task （每個測試用例不同）從 kafka topic data 相同的 offset 開始消費，並將結果及相應 intime、outtime 時間戳分別寫入兩個 topic（topic storm 和 topic flink）中。
指標統計
metricscollector 按 outtime 的時間視窗從這兩個 topic 中統計測試指標，每五分鐘將相應的指標寫入 mysql 表中。
metricscollector 按 outtime 取五分鐘的滾動時間視窗，計算五分鐘的平均吞吐（輸出資料的條數）、五分鐘內的延遲（outtime – eventtime 或 outtime – intime）的中位數及 99 線等指標，寫入 mysql 相應的資料表中。最後對 mysql 表中的吞吐計算均值，延遲中位數及延遲 99 線選取中位數，繪製影象並分析。
identity
sleep
sleep 用例主要模擬使用者作業耗時較長的場景，反映複雜使用者邏輯對框架差異的削弱 ，比較兩個框架的排程效能 。
輸入資料和輸出資料均與 identity 相同。
讀入資料後，等待一定時長（1 ms）後在字串末尾追加時間戳後輸出。
windowedword count
由此可以看出，flink 吞吐約為 storm 的 3-5 倍。
綜上可得，flink 框架本身效能優於 storm。
綜合上述測試結果，以下實時計算場景建議考慮使用 flink 框架進行計算：
本次測試中尚有一些內容沒有進行更加深入的測試，有待後續測試補充。例如：
1.分布式流處理框架——功能對比和效能評估.
2.intel-hadoop/hibench: hibenchis a big data benchmark suite.
3.yahoo的流計算引擎基準測試.
4.extendingthe yahoo! streaming benchmark.
flink計算實時流中的中位數
求1s內的中位數sink es 視窗1s,對資料進行分組 計算每組資料的總數 計算視窗內所有資料的總數 根據視窗內所有資料的總數找到中位數的位置 根據中位數的位置找到中位數 senv 源資料切割，封裝成stat物件 stat elapsedtime,num flatmap 按照stat elapse...
kafka的流計算框架
producer 傳送例如 aa zz consumer 收到zz 通過 切分得到後面的，如果沒有 就正常輸出public class logprocessor implements processor 具體業務邏輯 public void process byte key,byte value 輸...
大資料「重磅炸彈」 實時計算框架 Flink
apache flink 是一款面向資料流處理和批處理的可分布式的新一代大資料實時處理引擎，簡直是大資料中的 重磅炸彈 對於大資料開發者來說，實時計算一時爽，一直實時計算一直爽 對於有實時計算場景需求的後端開發也可以了解一下。本場 chat 首先會分析一下公司常見的實時計算場景需求有哪些，然後對實時...