《從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，而後回覆關鍵字：Flink 便可無條件獲取到。

另外這裏也推薦一些博客能夠看看：

一、官網：https://flink.apache.org/

二、GitHub: https://github.com/apache/flink

三、https://blog.csdn.net/column/details/apacheflink.html

四、https://blog.csdn.net/lmalds/article/category/6263085

五、http://wuchong.me/

六、https://blog.csdn.net/liguohuabigdata/article/category/7279020

下面的介紹可能也有很多參考以上全部的資料，感謝他們！在介紹 Flink 前，咱們先看看 數據集類型 和 數據運算模型 的種類。

數據集類型有哪些呢：

• 無窮數據集：無窮的持續集成的數據集合
• 有界數據集：有限不會改變的數據集合

那麼那些常見的無窮數據集有哪些呢？

• 用戶與客戶端的實時交互數據
• 應用實時產生的日誌
• 金融市場的實時交易記錄
• …

數據運算模型有哪些呢：

• 流式：只要數據一直在產生，計算就持續地進行
• 批處理：在預先定義的時間內運行計算，當完成時釋放計算機資源

Flink 它能夠處理有界的數據集、也能夠處理無界的數據集、它能夠流式的處理數據、也能夠批量的處理數據。

Flink 是什麼 ？

上面三張圖轉自 雲邪 成都站 《Flink 技術介紹與將來展望》，侵刪。

從下至上，Flink 總體結構

從下至上：

一、部署：Flink 支持本地運行、能在獨立集羣或者在被 YARN 或 Mesos 管理的集羣上運行， 也能部署在雲上。

二、運行：Flink 的核心是分佈式流式數據引擎，意味着數據以一次一個事件的形式被處理。

三、API：DataStream、DataSet、Table、SQL API。

四、擴展庫：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 應用程序結構就是如上圖所示：

一、Source: 數據源，Flink 在流處理和批處理上的 source 大概有 4 類：基於本地集合的 source、基於文件的 source、基於網絡套接字的 source、自定義的 source。自定義的 source 常見的有 Apache kafka、Amazon Kinesis Streams、RabbitMQ、Twitter Streaming API、Apache NiFi 等，固然你也能夠定義本身的 source。

二、Transformation：數據轉換的各類操做，有 Map / FlatMap / Filter / KeyBy / Reduce / Fold / Aggregations / Window / WindowAll / Union / Window join / Split / Select / Project 等，操做不少，能夠將數據轉換計算成你想要的數據。

三、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 做業提交架構流程可見下圖：

一、Program Code：咱們編寫的 Flink 應用程序代碼

二、Job Client：Job Client 不是 Flink 程序執行的內部部分，但它是任務執行的起點。 Job Client 負責接受用戶的程序代碼，而後建立數據流，將數據流提交給 Job Manager 以便進一步執行。 執行完成後，Job Client 將結果返回給用戶

三、Job Manager：主進程（也稱爲做業管理器）協調和管理程序的執行。 它的主要職責包括安排任務，管理checkpoint ，故障恢復等。機器集羣中至少要有一個 master，master 負責調度 task，協調 checkpoints 和容災，高可用設置的話能夠有多個 master，但要保證一個是 leader, 其餘是 standby; Job Manager 包含 Actor system、Scheduler、Check pointing 三個重要的組件

四、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 稍微有一點概念了。