《從0到1學習Flink》—— Apache Flink 介紹
前言
Flink 是一種流式計算框架，為什麼我會接觸到 Flink 呢？因為我目前在負責的是監控平臺的告警部分，負責採集到的監控資料會直接往 kafka 裡塞，然後告警這邊需要從 kafka topic 裡面實時讀取到監控資料，並將讀取到的監控資料做一些 聚合/轉換/計算 等操作，然後將計算後的結果與告警規則的閾值進行比較，然後做出相應的告警措施（釘釘群、郵件、簡訊、電話等）。畫了個簡單的圖如下：
目前告警這塊的架構是這樣的結構，剛進公司那會的時候，架構是所有的監控資料直接存在 ElasticSearch 中，然後我們告警是去 ElasticSearch 中搜索我們監控指標需要的資料，幸好 ElasticSearch 的搜尋能力夠強大。但是你有沒有發現一個問題，就是所有的監控資料從採集、採集後的資料做一些 計算/轉換/聚合、再通過 Kafka 訊息佇列、再存進 ElasticSearch 中，再而去 ElasticSearch 中查詢我們的監控資料，然後做出告警策略。整個流程對監控來說看起來很按照常理，但是對於告警來說，如果中間某個環節出了問題，比如 Kafka 訊息佇列延遲、監控資料存到 ElasticSearch 中寫入時間較長、你的查詢姿勢寫的不對等原因，這都將導致告警從 ElasticSearch 查到的資料是有延遲的。也許是 30 秒、一分鐘、或者更長，這樣對於告警來說這無疑將導致告警的訊息沒有任何的意義。
為什麼這麼說呢？為什麼需要監控告警平臺呢？無非就是希望我們能夠儘早的發現問題，把問題給告警出來，這樣開發和運維人員才能夠及時的處理解決好線上的問題，以免給公司造成巨大的損失。
更何況現在還有更多的公司在做那種提前預警呢！這種又該如何做呢？需要用大資料和機器學習的技術去分析週期性的歷史資料，然後根據這些資料可以整理出來某些監控指標的一些週期性（一天/七天/一月/一季度/一年）走勢圖，這樣就大概可以繪圖出來。然後根據這個走勢圖，可以將當前時間點的監控指標的資料使用量和走勢圖進行對比，在快要達到我們告警規則的閾值時，這時就可以提前告一個預警出來，讓運維提前知道預警，然後提前查詢問題，這樣就能夠提早發現問題所在，避免損失，將損失降到最小！當然，這種也是我打算做的，應該可以學到不少東西的。
於是乎，我現在就在接觸流式計算框架 Flink，類似的還有常用的 Spark 等。
自己也接觸了 Flink 一段時間了，這塊中文資料目前書籍是隻有一本很薄的，英文書籍也是三本不超過。
我自己整理了些 Flink 的學習資料，目前已經全部放到微信公眾號了。你可以加我微信：zhisheng_tian，然後回覆關鍵字：Flink 即可無條件獲取到。
另外這裡也推薦一些部落格可以看看：
1、官網：https://flink.apache.org/
2、GitHub: https://github.com/apache/flink
3、https://blog.csdn.net/column/details/apacheflink.html
4、https://blog.csdn.net/lmalds/article/category/6263085
5、http://wuchong.me/
6、https://blog.csdn.net/liguohuabigdata/article/category/7279020
下面的介紹可能也有不少參考以上所有的資料，感謝他們！在介紹 Flink 前，我們先看看 資料集型別 和 資料運算模型 的種類。
資料集型別有哪些呢：
無窮資料集：無窮的持續整合的資料集合
有界資料集：有限不會改變的資料集合
那麼那些常見的無窮資料集有哪些呢？
使用者與客戶端的實時互動資料
應用實時產生的日誌
金融市場的實時交易記錄
…
資料運算模型有哪些呢：
流式：只要資料一直在產生，計算就持續地進行
批處理：在預先定義的時間內執行計算，當完成時釋放計算機資源
Flink 它可以處理有界的資料集、也可以處理無界的資料集、它可以流式的處理資料、也可以批量的處理資料。
Flink 是什麼 ？
上面三張圖轉自 雲邪 成都站 《Flink 技術介紹與未來展望》，侵刪。
從下至上，Flink 整體結構
從下至上：
1、部署：Flink 支援本地執行、能在獨立叢集或者在被 YARN 或 Mesos 管理的叢集上執行， 也能部署在雲上。
2、執行：Flink 的核心是分散式流式資料引擎，意味著資料以一次一個事件的形式被處理。
3、API：DataStream、DataSet、Table、SQL API。
4、擴充套件庫：Flink 還包括用於複雜事件處理，機器學習，圖形處理和 Apache Storm 相容性的專用程式碼庫。
Flink 資料流程式設計模型
抽象級別
Flink 提供了不同的抽象級別以開發流式或批處理應用。
最底層提供了有狀態流。它將通過 過程函式（Process Function）嵌入到 DataStream API 中。它允許使用者可以自由地處理來自一個或多個流資料的事件，並使用一致、容錯的狀態。除此之外，使用者可以註冊事件時間和處理事件回撥，從而使程式可以實現複雜的計算。
DataStream / DataSet API 是 Flink 提供的核心 API ，DataSet 處理有界的資料集，DataStream 處理有界或者無界的資料流。使用者可以通過各種方法（map / flatmap / window / keyby / sum / max / min / avg / join 等）將資料進行轉換 / 計算。
Table API 是以 表 為中心的宣告式 DSL，其中表可能會動態變化（在表達流資料時）。Table API 提供了例如 select、project、join、group-by、aggregate 等操作，使用起來卻更加簡潔（程式碼量更少）。
你可以在表與 DataStream/DataSet 之間無縫切換，也允許程式將 Table API 與 DataStream 以及 DataSet 混合使用。
Flink 提供的最高層級的抽象是 SQL 。這一層抽象在語法與表達能力上與 Table API 類似，但是是以 SQL查詢表示式的形式表現程式。SQL 抽象與 Table API 互動密切，同時 SQL 查詢可以直接在 Table API 定義的表上執行。
Flink 程式與資料流結構
Flink 應用程式結構就是如上圖所示：
1、Source: 資料來源，Flink 在流處理和批處理上的 source 大概有 4 類：基於本地集合的 source、基於檔案的 source、基於網路套接字的 source、自定義的 source。自定義的 source 常見的有 Apache kafka、Amazon Kinesis Streams、RabbitMQ、Twitter Streaming API、Apache NiFi 等，當然你也可以定義自己的 source。
2、Transformation：資料轉換的各種操作，有 Map / FlatMap / Filter / KeyBy / Reduce / Fold / Aggregations / Window / WindowAll / Union / Window join / Split / Select / Project 等，操作很多，可以將資料轉換計算成你想要的資料。
3、Sink：接收器，Flink 將轉換計算後的資料傳送的地點 ，你可能需要儲存下來，Flink 常見的 Sink 大概有如下幾類：寫入檔案、打印出來、寫入 socket 、自定義的 sink 。自定義的 sink 常見的有 Apache kafka、RabbitMQ、MySQL、ElasticSearch、Apache Cassandra、Hadoop FileSystem 等，同理你也可以定義自己的 sink。
為什麼選擇 Flink？
Flink 是一個開源的分散式流式處理框架：
①提供準確的結果，甚至在出現無序或者延遲載入的資料的情況下。
②它是狀態化的容錯的，同時在維護一次完整的的應用狀態時，能無縫修復錯誤。
③大規模執行，在上千個節點執行時有很好的吞吐量和低延遲。
更早的時候，我們討論了資料集型別（有界 vs 無窮）和運算模型（批處理 vs 流式）的匹配。Flink 的流式計算模型啟用了很多功能特性，如狀態管理，處理無序資料，靈活的視窗，這些功能對於得出無窮資料集的精確結果是很重要的。
Flink 保證狀態化計算強一致性。”狀態化“意味著應用可以維護隨著時間推移已經產生的資料聚合或者，並且 Filnk 的檢查點機制在一次失敗的事件中一個應用狀態的強一致性。
Flink 支援流式計算和帶有事件時間語義的視窗。事件時間機制使得那些事件無序到達甚至延遲到達的資料流能夠計算出精確的結果。
除了提供資料驅動的視窗外，Flink 還支援基於時間，計數，session 等的靈活視窗。視窗能夠用靈活的觸發條件定製化從而達到對複雜的流傳輸模式的支援。Flink 的視窗使得模擬真實的建立資料的環境成為可能。
Flink 的容錯能力是輕量級的，允許系統保持高併發，同時在相同時間內提供強一致性保證。Flink 以零資料丟失的方式從故障中恢復，但沒有考慮可靠性和延遲之間的折衷。
Flink 能滿足高併發和低延遲（計算大量資料很快）。下圖顯示了 Apache Flink 與 Apache Storm 在完成流資料清洗的分散式任務的效能對比。
Flink 儲存點提供了一個狀態化的版本機制，使得能以無丟失狀態和最短停機時間的方式更新應用或者回退歷史資料。
Flink 被設計成能用上千個點在大規模叢集上執行。除了支援獨立叢集部署外，Flink 還支援 YARN 和Mesos 方式部署。
Flink 的程式內在是並行和分散式的，資料流可以被分割槽成 stream partitions，operators 被劃分為operator subtasks; 這些 subtasks 在不同的機器或容器中分不同的執行緒獨立執行；operator subtasks 的數量在具體的 operator 就是平行計算數，程式不同的 operator 階段可能有不同的並行數；如下圖所示，source operator 的並行數為 2，但最後的 sink operator 為1；
自己的記憶體管理
Flink 在 JVM 中提供了自己的記憶體管理，使其獨立於 Java 的預設垃圾收集器。 它通過使用雜湊，索引，快取和排序有效地進行記憶體管理。
豐富的庫
Flink 擁有豐富的庫來進行機器學習，圖形處理，關係資料處理等。 由於其架構，很容易執行復雜的事件處理和警報。
分散式執行
flink 作業提交架構流程可見下圖：
1、Program Code：我們編寫的 Flink 應用程式程式碼
2、Job Client：Job Client 不是 Flink 程式執行的內部部分，但它是任務執行的起點。 Job Client 負責接受使用者的程式程式碼，然後建立資料流，將資料流提交給 Job Manager 以便進一步執行。 執行完成後，Job Client 將結果返回給使用者
3、Job Manager：主程序（也稱為作業管理器）協調和管理程式的執行。 它的主要職責包括安排任務，管理checkpoint ，故障恢復等。機器叢集中至少要有一個 master，master 負責排程 task，協調 checkpoints 和容災，高可用設定的話可以有多個 master，但要保證一個是 leader, 其他是 standby; Job Manager 包含 Actor system、Scheduler、Check pointing 三個重要的元件
4、Task Manager：從 Job Manager 處接收需要部署的 Task。Task Manager 是在 JVM 中的一個或多個執行緒中執行任務的工作節點。 任務執行的並行性由每個 Task Manager 上可用的任務槽決定。 每個任務代表分配給任務槽的一組資源。 例如，如果 Task Manager 有四個插槽，那麼它將為每個插槽分配 25％ 的記憶體。 可以在任務槽中執行一個或多個執行緒。 同一插槽中的執行緒共享相同的 JVM。 同一 JVM 中的任務共享 TCP 連線和心跳訊息。Task Manager 的一個 Slot 代表一個可用執行緒，該執行緒具有固定的記憶體，注意 Slot 只對記憶體隔離，沒有對 CPU 隔離。預設情況下，Flink 允許子任務共享 Slot，即使它們是不同 task 的 subtask，只要它們來自相同的 job。這種共享可以有更好的資源利用率。
最後
本文主要講了我接觸到 Flink 的緣由，然後從資料集型別和資料運算模型開始講起，接著介紹了下 Flink 是什麼、Flink 的整體架構、提供的 API、Flink 的優點所在以及 Flink 的分散式作業執行的方式。水文一篇，希望你能夠對 Flink 稍微有一點概念了。
原文釋出時間為：2018-11-05
本文作者：全棧-老鄧頭
本文來自雲棲社群合作伙伴“ ofollow,noindex">zhisheng ”，瞭解相關資訊可以關注“ zhisheng ”。