雲栖号資訊：【 點選檢視更多行業資訊】
在這裡您可以找到不同行業的第一手的上雲資訊，還在等什麼，快來！
1.什麼是 Apache Flink？
Flink 誕生于歐洲的一個大資料研究項目 StratoSphere。該項目是柏林工業大學的一個研究性項目。早期，Flink 是做 Batch 計算的，但是在 2014 年，StratoSphere 裡面的核心成員孵化出 Flink，同年将 Flink 捐贈 Apache，并在後來成為 Apache 的頂級大資料項目，同時 Flink 計算的主流方向被定位為 Streaming，即用流式計算來做所有大資料的計算。
具體來說，Apache Flink 是一個解決實時資料處理的計算架構，但不是資料倉庫的服務，其可對有限資料流和無限資料流進行有狀态計算，并可部署在各種叢集環境，對各種大小的資料規模進行快速計算。
如上圖所示 Flink 架構，大緻可以分為三塊内容，從左到右依次為：資料輸入、Flink 資料處理、資料輸出。
Flink 支援消息隊列的 Events（支援實時的事件）的輸入，上遊源源不斷産生資料放入消息隊列，Flink 不斷消費、處理消息隊列中的資料，處理完成之後資料寫入下遊系統，這個過程是不斷持續的進行。
在 API 層面，Flink 具備較好的層級組。但是不論是通過 SQL 的 API 還是 Table 的 API 還是 DataStream 的 API，其最終都會被轉換成 Stream Operator 然後放在 flink Runtime 的架構下去執行，即轉換成一個各種 Operator 串聯在一起的 Flink 應用程式。隻是上層的 API 在嘗試做 Flink 程式時，會有各種不同的角度，從各方面寫出所想要達到效果的應用程式。
2.新一代分布式流式資料處理架構
Flink 是一套集高吞吐、低延遲、有狀态三者于一身的分布式流式資料處理架構。
衆所周知，非常成熟的計算架構 Apache Spark 也隻能兼顧高吞吐和高性能特性，在 Spark Streaming 流式計算中無法做到低延遲保障；而 Apache Storm 隻能支援低延遲和高性能特性，但是無法滿足高吞吐的要求。而對于滿足高吞吐，低延遲，有狀态這三個目标對分布式流式計算架構是非常重要的。
如上圖所示，相比于 Storm 或其他的架構，Flink 網絡模型還是相對來說比較高效的，每一個 Flink TaskManager 下會有很多個 Subtask。與其他方案設計不同的是，Subtask 會共享一個 TaskManager 的服務，通過一個 TCP Connection 與其它 TaskManager 通信，通信則是由 TaskManager 内設的 Netty 伺服器完成。
需要注意的是，預設的情況下事件的資料并不是完成了一條就發送一條，而是從每一個 Subtask 的 Buffer Pool 中擷取一個緩沖塊，由 RecordWriter 寫到緩沖塊中，等到這個緩沖塊寫滿了，再通知 Netty 發送隊列到其他的 TaskManager。這樣既可以很好保證了每一個 TCP 包被盡可能的利用，又減少了不必要網絡包的數量。
從技術本身的底層特性上說，Flink 引入了 Buffer Pool 和 Buffer 塊的概念。在大流量時，由于 Buffer 區很快就會被寫滿，緊接着會通知 Netty 盡可能地發送，是以不會看到太多的延遲。但在低流量時，可能幾秒鐘才會有一條資料，這就意味着 Buffer pool 有很長時間沒有被強制寫滿，是以為了保證下遊系統盡可能盡快得到上遊的消息，就需要有一個強制的重新整理或往下遊推送的觸發器機制。
Flink 本身則具備這樣的一個機制，它可以盡可能地保證 Buffer 還沒有寫滿時，就可提前去通知 Netty 伺服器，盡快把目前 Buffer 塊裡面的資料發送下去，并可以通過 BufferTimeout 的參數設定，控制 Flink 在低流量時的系統最大延遲。
Buffertimeout 包含 -1、0、x ms 的配法。比較特殊的是 -1 和 0，當把參數設為 -1 時，Flink 的使用者會忽略 Flusher 的通知，往下的發送必須要由 RecordWriter 完成，也就是預設了這個緩沖寫滿了往下發。這樣的情況下雖然每一次通信的效率是高效的，但是在低流量時若接受就會出現大量的不可預測的系統延遲。
當把參數設為 0 時，意味着 Flink 每寫一條資料就會通知 Netty 盡可能的發送，即系統達到了技術理論上的最低延遲。是以，當你對延遲特别敏感流量又不是很高時，可以考慮将 Buffertimeout 設為 0。
正常情況下會将 Buffertimeout 設為某個正值，也就是多少個毫秒。這時 Flink 每間隔一段時間通知 Netty，Netty 不管這個資料有沒有寫完或者有沒有寫滿，都盡可能發送。
這樣通過這兩個參數，也就是緩沖區大小及多長時間強制發送，就可以在延遲和吞吐之間形成一種次元的控制，并可以在低延遲或者是高吞吐這兩個方向上做一些控制，既能保證高吞吐，又能保證低延遲。
由于 Flink 是一個實時計算的架構，是以 Flink 的狀态實際上是最核心的技術資産，涉及到了頻繁的寫入與讀取，并需要用很快的存儲方案存儲該狀态。Flink 提供了三種狀态的存儲模式，分别是記憶體模式、檔案模式和 Rocks DB 的模式。
- 記憶體模式：使用這種方式，Flink 會将狀态維護在 Java 堆上。衆所周知，記憶體的通路讀寫速度最快；其缺點也顯而易見，單台機器的記憶體空間有限，不适合存儲大資料量的狀态資訊。一般在本地開發調試時或者狀态非常小的應用場景下使用記憶體這種方式。
- 檔案模式：當選擇使用檔案系統作為後端時，正在計算的資料會被暫存在 TaskManager 的記憶體中。Checkpoint 時，此後端會将狀态快照寫入配置的檔案系統中，同時會在 JobManager 的記憶體中或者在 Zookeeper 中（高可用情況）存儲極少的中繼資料。檔案系統後端适用于處理大狀态，長視窗，或大鍵值狀态的任務。
- RocksDB：RocksDB 是一種嵌入式鍵值資料庫。使用 RocksDB 作為後端時，Flink 會将實時進行中的資料使用 RocksDB 存儲在本地磁盤上。Checkpoint 時，整個 RocksDB 資料庫會被存儲到配置的檔案系統中，同時 Flink 會将極少的中繼資料存儲在 JobManager 的記憶體中，或者在 Zookeeper 中（高可用情況）。RocksDB 支援增量 Checkpoint，即隻對修改的資料做備份，是以非常适合超大狀态的場景。
3.三大場景，實時處理不在話下
Flink 的應用場景一般看到三大類，分别是流式的 ETL，實時的資料分析以及事件驅動型應用的改造。
流式 ETL
傳統的 ETL 的任務一般是定時出發完成讀取資料，把結果寫到某一個資料庫或者檔案系統中，通過周期性地調用 ETL 腳本完成批處理的作業。但是當有流式 ETL 的能力時，就不再需要定時出發的方式完成 ETL 的任務，而是在資料到達之後馬上開始 ETL 的處理。遇到意外的情況也可通過畫面機制從上一個出發點恢複再繼續執行任務。
實時的資料分析
Apache Flink 同時支援流式及批量分析應用。
Flink 為持續流式分析和批量分析都提供了良好的支援。具體而言，它内置了一個符合 ANSI 标準的 SQL 接口，将批、流查詢的語義統一起來。無論是在記錄事件的靜态資料集上還是實時事件流上，相同 SQL 查詢都會得到一緻的結果。
但是有一點不可避免的是，由于實時分析系統面對的是非閉合的區間，或者是半開放的資料處理區間，是以如果要用實時的資料分析系統，就不可能保證産品結果 100% 能運作，開發者隻能通過一些手段來降低這種情況出現的機率，而不能完全避免像這樣的情況。
事件驅動型應用
事件驅動型應用是一類具有狀态的應用，它從一個或多個事件流提取資料，并根據到來的事件觸發計算、狀态更新或其他外部動作。
如上圖所示，左邊傳統的事務處理應用，右邊是事件驅動的處理應用。
傳統的事務處理應用的點選流 Events 可以通過 Application 寫入 Transaction DB（資料庫），同時也可以通過 Application 從 Transaction DB 将資料讀出，并進行處理，當處理結果達到一個預警值就會觸發一個 Action 動作。
而事件驅動的應用處理采集的資料 Events 可以不斷的放入消息隊列，Flink 應用會不斷 ingest（消費）消息隊列中的資料，Flink 應用内部維護着一段時間的資料（state），隔一段時間會将資料持久化存儲（Persistent sstorage），防止 Flink 應用死掉。Flink 應用每接受一條資料，就會處理一條資料，處理之後就會觸發（trigger）一個動作（Action），同時也可以将處理結果寫入外部消息隊列中，其他 Flink 應用再消費。并且可以通過 checkpoint 機制保證一緻性，避免意外情況。
4.CSA 基于 Flink ，實作 IoT 級資料流和複雜事件的實時狀态處理
将 Flink 添加到 Cloudera DataFlow（CDF） 的意義十分重大，Cloudera 提供了流處理引擎的幾種選擇：Storm，Spark Structured Streaming 和 Kafka Stream，其中，Storm 在市場和開源社群中逐漸失寵，使用者正在尋找更好的選擇，而 Apache Flink 天然支援流計算（而不是批處理）可以大規模處理大量資料流，具有原生支援的容錯 / 恢複能力，以及先進的 Window 語義，這使其成為更廣泛的流處理引擎的預設選擇。
由 Apache Flink 支援的 Cloudera Streaming Analytics（簡稱“CSA”） 是 CDF 平台内的一項新産品，可提供 IoT 級資料流和複雜事件的實時狀态處理。作為 CDF 的關鍵支柱之一，流處理和分析對于處理來自各種資料源的數百萬個資料點和複雜事件非常重要。多年來已經支援了多個流引擎，Flink 的加入，使 CDF 成為了一個可以大規模處理大量流資料的平台。
Cloudera Streaming Analytics 涵蓋了 Apache Flink 的核心流功能：
- 在 YARN 上支援 Flink 1.9.1
- 支援在 Cloudera 托管叢集上安裝 Flink
- 支援完全安全（啟用 TLS 和 Kerberos）的 Flink 叢集
- 從 Kafka 或 HDFS 讀取資料源
- 使用 Java DataStream 和 ProcessFunction API 的 pipeline 定義
- 恰好一次的語義
- 基于事件時間的語義
- 資料接收器寫入 Kafka，HDFS 和 HBase
與 Cloudera Schema Registry 內建以進行模式管理以及流事件的序列化 / 反序列化
如何使用 Cloudera CSA？
Cloudera CSA 的下載下傳與使用 Cloudera Manager 安裝服務沒有太大的差別，在簽署訂閱協定後會獲得下載下傳連結，可以直接刷到 Parcels 包。Parcels 裝好之後就可以裝 Flink 了，裝好之後可以看到 History Server 和 Gateway 的服務。打開 History Server 的 Web UI 就顯示出 Flink 業務運作的監控面闆，代表了 CSA 安裝完畢。
接下來就是采用一些标準的開發包，開始第一個 Flink 工程。首先擷取運作環境，加載或者讀取資料，再編寫 Transformations，添加資料輸出目标系統，最後執行這個應用。
5.不止于此，Apache Flink 與 CSA 正在探索更多的可能性
目前 Flink 已經成為一個主流的流計算引擎，社群下一步很重要的工作是對 Flink 做一個大的整合，面向流和批去做一個統一的資料處理模型。在 1.9 的版本上用一個技術預覽版 Flink 的 SQL Planner 來替代老的 SQL Planner，支援原生 SQL 關鍵字，這對 SQL 的标準性以及 SQL 文法解析的正确性和高效性都是有一個更好的保障。
同時，作為開源技術的或者叫 Apache 社群的參與者，Cloudera 也會對 Apache Flink 這個技術做出更多貢獻，其中會關注在安全層面上的內建，然後還有 Atlas 元件的內建，同時也會在接口層面會做一個新的 HBASE Connector。
此外，目前的 CSA 雖然支援 Kerberos 的語義環境，但是沒有類似于像點選就完成的這種自動化的 Kerberos 配置，以及包括通過一些可視化的這種架構或者是統一的安全管理架構，比如說 Ranger，去管理任務的權限。是以，未來的 CSA 也會在面向企業管理的方向做一些新的更好的管理，包括 A/B 測試的一個 Flink 程式的管理，以及任務和任務 JAR 的管理等等。
同時，Cloudera 将投入更多力量到開源 Flink 的發展和社群的建設當中，希望和廣大業界同仁一起助力 Flink 社群的發展。
【雲栖号線上課堂】每天都有産品技術專家分享！
課程位址：
https://yqh.aliyun.com/zhibo立即加入社群，與專家面對面，及時了解課程最新動态！
【雲栖号線上課堂 社群】
https://c.tb.cn/F3.Z8gvnK
原文釋出時間：2020-04-02
本文作者：LuLu
本文來自：“
InfoQ 微信公衆号”，了解相關資訊可以關注“
InfoQ”