身為大資料工程師，你還在苦學Spark、Hadoop、Storm，卻還沒搞過Flink？醒醒吧！剛過去的2020雙11，阿裡在Flink實時計算技術的驅動下全程保持了“如絲般順滑”，基于Flink的阿裡巴巴實時計算平台簡直強·無敵。最恐怖的是，阿裡當時的實時計算峰值達到了破紀錄的每秒40億條記錄，資料量也達到了驚人的7TB每秒，相當于一秒鐘需要讀完500萬本《新華字典》！Flink的強悍之處，阿裡已屢試不爽！
01
阿裡為何堅定不移地選擇Flink？
大資料起源于批處理，在批處理上，Spark有很深的積累。為了應對全球大量業務的實時需求，Spark也推出了流計算解決方案——SparkStreaming。但Spark畢竟不是一款純流式計算引擎，是以在時效性等問題上，始終無法提供極緻的流批一體體驗。而後起新秀Flink的基本資料模型則是資料流，以及事件(Event)的序列。資料流作為資料的基本模型，可以是無邊界的無限“流”，即一般意義上的流處理；也可以是有邊界的有限“流”，也就同時兼顧了批處理。
Spark和Flink都具有流和批處理能力，但是他們的做法是相反的。Spark Streaming是把流轉化成一個個小的批來處理，這種方案的一個問題是我們需要的延遲越低，額外開銷占的比例就會越大，這導緻了Spark Streaming很難做到秒級甚至亞秒級的延遲。Flink是把批當作一種有限的流，這種做法的一個特點是在流和批共享大部分代碼的同時還能夠保留批處理特有的一系列的優化。
同時，Flink相比于Spark而言還有諸多明顯優勢：
- 支援高效容錯的狀态管理，保證在任何時間都能計算出正确的結果；
- 同時支援高吞吐、低延遲、高性能的分布式流式資料處理架構；
- 支援事件時間（Event Time）概念，事件即使無序到達甚至延遲到達，資料流都能夠計算出精确的結果；
- 輕量級分布式快照（Snapshot）實作的容錯，能将計算過程分布到單台并行節點上進行處理。
阿裡早在幾年前就開始探索Flink的實戰應用，随着2020雙11阿裡基于Flink實時計算場景的成功，毋庸置疑，Flink将會加速成為大廠主流的資料處理架構，最終化身下一代大資料處理标準。02
Flink在千億級海量資料場景的最佳實戰
回歸業務，在千億級海量資料實時處理場景中，Flink如何落地應用？如何設計Flink StateBackend ？Flink兩階段送出核心源碼有哪些？海量大資料去重普适架構又該怎麼做？
頭條基于Flink的統一廣告流引擎推薦平台實戰
碰巧我和前58技術委員會主席孫玄（江湖人稱“玄姐”）聊過關于Flink的問題，玄姐認為：對數字化轉型的公司來說，公司的業務可以分為兩類：一類是OLTP型的業務，一類是OLAP型的業務。當今的大資料架構師需要掌握大資料采集、大資料ETL、大資料計算、大資料存儲、大資料模組化、大資料智能分析等多項技術能力，其中最核心的就是以Flink為首的大資料計算引擎。
計算引擎是整個大資料生态非常重要的一環，根據業務需求不同，大資料計算又分為離線批量計算和線上實時計算。比如基于MapReduce的海量計算屬于離線計算範疇；基于ClickHouse的計算屬于實時線上計算範疇。Flink就是一款既支援離線批量計算又支援實時線上計算引擎，無疑大資料開發/架構師必須具備的核心技能。