點擊上方藍色字體，選擇“設爲星標”
回覆”資源“獲取更多資源
![]()
Flink經過2年左右的官方和社區的大規模推廣，現在國內的一衆大小企業基本都在使用。
後臺很多小夥伴都在問Flink的學習路徑，那麼我們在學習Flink的時候，到底重點學習哪些東西呢？
從我個人的學習經歷來看，在學習任何一個新出現的框架或者技術點的時候，核心方法就是：【先看背景，整理大綱，逐個擊破】。
核心背景和論文
Flink框架自提出到實現，是有深厚的理論作爲背書的，其中又以《Lightweight Asynchronous Snapshots for Distributed Dataflows》最爲核心，本文提出了一種輕量級的異步分佈式快照(Asynchronous Barrier Snapshot, 簡稱ABS)方法，既支持無環圖，又支持有環圖，而且可以做到線性擴展。
傳統的流式計算由算子節點和連接算子的數據管道組成，傳統的分佈式快照方案就像拍照片一樣，把每個算子內的state狀態和彼此相連管道中的數據都保存下來。ABS方案的提出對傳統的流式計算引擎的設計方案可以說是顛覆性的。
另外一篇是《Apache FlinkTM: Stream and Batch Processing in a Single Engine》，嚴格來說這篇論文是一篇Flink的概要設計文檔。可以當成一個技術文檔來看，對於很多我們難以理解的設計都有很大的幫助。
此外，《The world beyond batch: streaming 101/102》是由Google的大神Tyler Akidau寫的兩篇文章。第1篇文章，在深入瞭解時間，對批處理和流式數據常見處理方式進行高階闡述之前，介紹一些基本的背景知識和術語。第2篇文章主要介紹包括Google Dataflow大數據平臺使用的統一批量+流式傳輸模式。這兩篇文章對於我們理解Flink中的時間、窗口、觸發器等等的實現有十分重要的指導意義。並且作者還在YouTube上傳了動畫，可謂用心良苦，各位各憑本事翻牆去找吧。
基礎概念
如果你讀過了上面的核心論文，那麼你就會對Flink中一些概念的提出有更爲深刻的理解，在Flink這個框架中，延用了很多之前Hadoop體系或者Spark中的設計概念。
流(無界流、有界流)和轉換
State和checkpoint
並行度
Workers,Slots,Resources
時間和窗口
...
此外還有一些例如：分佈式緩存、重啓策略等。當然在Flink SQL中還有一些特定的概念，例如：Window Aggregate、Non-window Aggregate、Group Aggregate、Append Stream等等。
核心模塊
我們直接把官網的圖拿過來，這張圖上基本就是Flink框架整體的設計思想和模塊要拆分：
![]()
那麼對於我們數據開發來說，裏面最核心的包分配我們看一下Github：
![]()
源碼閱讀
根據上面我們選擇的核心模塊，我們大概可以得知，整個Flink的核心實現包含了：
Flink 基本組件和邏輯計劃：介紹了 Flink 的基本組件、集羣構建的過程、以及客戶端邏輯計劃的生成過程
Flink 物理計劃生成：介紹了 Flink JobManager 對邏輯計劃的運行時抽象，運行時物理計劃的生成和管理等
Jobmanager 基本組件和TaskManager的基本組件
Flink 算子的生命週期：介紹了 Flink 的算子從構建、生成、運行、及銷燬的過程
Flink 網絡棧：介紹了 Flink 網絡層的抽象，包括中間結果抽象、輸入輸出管理、BackPressure 技術、Netty 連接等
Flink的水印和Checkpoint
Flink-scheduler：介紹 Flink 的任務調度算法及負載均衡
Flink對用戶代碼異常處理：介紹作業的代碼異常後 Flink 的處理邏輯，從而更好的理解 Flink 是如何保證了 exactly-once 的計算語義
Flink Table/SQL 執行流程、Flink和Hive的集成等
行業應用
Flink的行業應用，我們在之前的文章中反覆提及。主要的應用：
如果你對大數據技術有所接觸，那麼下面的這些需求場景你應該並不陌生：
各大電商每年雙十一都會直播，實時監控大屏是如何做到的？
我是公司的運維，希望能實時接收到服務器的負載情況？
我們可以看到，數據計算場景需要從原始數據中提取有價值的信息和指標，比如上面提到的實時銷售額、銷量的 TOP5，以及服務器的負載情況等。
傳統的分析方式通常是利用批查詢，或將事件（生產上一般是消息）記錄下來並基於此形成有限數據集（表）構建應用來完成。爲了得到最新數據的計算結果，必須先將它們寫入表中並重新執行 SQL 查詢，然後將結果寫入存儲系統比如 MySQL 中，再生成報告。
Apache Flink 同時支持流式及批量分析應用，這就是我們所說的批流一體。Flink 在上述的需求場景中承擔了數據的實時採集、實時計算和下游發送。
ETL（Extract-Transform-Load）的目的是將業務系統的數據經過抽取、清洗轉換之後加載到數據倉庫的過程。
![]()
傳統的離線數據倉庫將業務數據集中進行存儲後，以固定的計算邏輯定時進行 ETL 和其他建模後產出報表等應用。離線數據倉庫主要是構建 T+1 的離線數據，通過定時任務每天拉取增量數據，然後創建各個業務相關的主題維度數據，對外提供 T+1 的數據查詢接口。
上圖展示了離線數據倉庫 ETL 和實時數據倉庫的差異，可以看到離線數據倉庫的計算和數據的實時性均較差。數據本身的價值隨着時間的流逝會逐步減弱，因此數據發生後必須儘快的達到用戶的手中，實時數倉的構建需求也應運而生。
實時數據倉庫的建設是“數據智能 BI”必不可少的一環，也是大規模數據應用中必然面臨的挑戰。
Flink 在實時數倉和實時 ETL 中有天然的優勢：
狀態管理，實時數倉裏面會進行很多的聚合計算，這些都需要對於狀態進行訪問和管理，Flink 支持強大的狀態管理
豐富的 API，Flink 提供極爲豐富的多層次 API，包括 Stream API、Table API 及 Flink SQL
生態完善，實時數倉的用途廣泛，Flink 支持多種存儲（HDFS、ES 等）
批流一體，Flink 已經在將流計算和批計算的 API 進行統一。
![]()
我們公司有幾萬臺服務器，希望能從服務器上報的消息中將 CPU、MEM、LOAD 信息分離出來做分析，然後觸發自定義的規則進行報警？
我是公司的安全運維人員，希望能從每天的訪問日誌中識別爬蟲程序，並且進行 IP 限制？
事件驅動型應用是一類具有狀態的應用，它從一個或多個事件流提取數據，並根據到來的事件觸發計算、狀態更新或其他外部動作。
在傳統架構中，我們需要讀寫遠程事務型數據庫，比如 MySQL。在事件驅動應用中數據和計算不會分離，應用只需訪問本地（內存或磁盤）即可獲取數據，所以具有更高的吞吐和更低的延遲。
![]()
Flink 的以下特性完美的支持了事件驅動型應用：
高效的狀態管理，Flink 自帶的 State Backend 可以很好的存儲中間狀態信息
豐富的窗口支持，Flink 支持包含滾動窗口、滑動窗口及其他窗口
多種時間語義，Flink 支持 Event Time、Processing Time 和 Ingestion Time
不同級別的容錯，Flink 支持 At Least Once 或 Exactly Once 容錯級別
我們也看到了，Flink目前在各大公司的應用基本集中在以上3個方面。此外，未來的數據領域我們看到了一些例如：
上述一些新興的領域，Flink也會有一些應用。此外，如果你把Flink當成了算法執行引擎，那麼FlinkML可能就是你研究的重點。
![]()
本文分享自微信公衆號 - 大數據技術與架構（import_bigdata）。
如有侵權，請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”，歡迎正在閱讀的你也加入，一起分享。
