雙十一流量洪峯已經過去，身為大數據工程師的你，還在苦學 Spark、Hadoop、Storm，卻還沒搞過 Flink？每年雙十一，阿里都在 Flink 實時計算技術的驅動下全程保持了“如絲般順滑”，基於 Flink 的阿里巴巴實時計算平台簡直強·無敵。

最恐怖的是，阿里幾乎每年的實時計算峯值都達到了破紀錄的每秒40億條記錄，數據量也達到了驚人的7TB每秒，相當於一秒鐘需要讀完500萬本《新華字典》！Flink 的強悍之處，阿里已屢試不爽！

阿里為何堅定不移地選擇Flink？

大數據起源於批處理，在批處理上，Spark有很深的積累。為了應對全球大量業務的實時需求，Spark也推出了流計算解決方案——SparkStreaming。但Spark畢竟不是一款純流式計算引擎，所以在時效性等問題上，始終無法提供極致的流批一體體驗。

而後起新秀 Flink 的基本數據模型則是數據流，以及事件(Event)的序列。數據流作為數據的基本模型，可以是無邊界的無限“流”，即一般意義上的流處理；也可以是有邊界的有限“流”，也就同時兼顧了批處理。

關於以上，阿里搜索事業部資深搜索專家蔣曉偉曾談到：

Spark和Flink都具有流和批處理能力，但是他們的做法是相反的。Spark Streaming是把流轉化成一個個小的批來處理，這種方案的一個問題是我們需要的延遲越低，額外開銷佔的比例就會越大，這導致了Spark Streaming很難做到秒級甚至亞秒級的延遲。Flink是把批當作一種有限的流，這種做法的一個特點是在流和批共享大部分代碼的同時還能夠保留批處理特有的一系列的優化。

同時，Flink 相比於 Spark 而言還有諸多明顯優勢：

• 支持高效容錯的狀態管理，保證在任何時間都能計算出正確的結果；
• 同時支持高吞吐、低延遲、高性能的分佈式流式數據處理框架；
• 支持事件時間（Event Time）概念，事件即使無序到達甚至延遲到達，數據流都能夠計算出精確的結果；
• 輕量級分佈式快照（Snapshot）實現的容錯，能將計算過程分佈到單台並行節點上進行處理。

阿里早在幾年前就開始探索 Flink 的實戰應用，隨着雙 11 阿里基於Flink實時計算場景的屢戰屢勝，毋庸置疑，Flink 將會加速成為大廠主流的數據處理框架，最終化身下一代大數據處理標準。

Flink 在千億級海量數據場景下的最佳實戰

迴歸業務，在千億級海量數據實時處理場景中，Flink如何落地應用？如何設計Flink StateBackend ？Flink兩階段提交核心源碼有哪些？海量大數據去重普適架構又該怎麼做？

頭條基於Flink的統一廣告流引擎推薦平台實戰

碰巧我和前58技術委員會主席孫玄（江湖人稱“玄姐”）聊過關於Flink的問題，玄姐認為：對數字化轉型的公司來説，公司的業務可以分為兩類：一類是 OLTP型 的業務，一類是 OLAP型 的業務。當今的大數據架構師需要掌握大數據採集、大數據ETL、大數據計算、大數據存儲、大數據建模、大數據智能分析等多項技術能力，其中最核心的就是以 Flink 為首的大數據計算引擎。

計算引擎是整個大數據生態非常重要的一環，根據業務需求不同，大數據計算又分為離線批量計算和在線實時計算。比如基於 MapReduce 的海量計算屬於離線計算範疇；基於 ClickHouse 的計算屬於實時在線計算範疇。Flink就是一款既支持離線批量計算又支持實時在線計算引擎，無疑大數據開發/架構師必須具備的核心技能。