統一批處理流處理——Flink批流一體實現原理

實現批處理的技術許許多多，從各類關係型數據庫的sql處理，到大數據領域的MapReduce，Hive，Spark等等。這些都是處理有限數據流的經典方式。而Flink專一的是無限流處理，那麼他是怎麼作到批處理的呢？

無限流處理：輸入數據沒有盡頭；數據處理從當前或者過去的某一個時間 點開始，持續不停地進行

另外一種處理形式叫做有限流處理，即從某一個時間點開始處理數據，而後在另外一個時間點結束。輸入數據可能自己是有限的（即輸入數據集並不會隨着時間增加），也可能出於分析的目的被人爲地設定爲有限集（即只分析某一個時間段內的事件）。

顯然，有限流處理是無限流處理的一種特殊狀況，它只不過在某個時間點中止而已。此外，若是計算結果不在執行過程當中連續生成，而僅在末尾處生成一次，那就是批處理（分批處理數據）。

批處理是流處理的一種很是特殊的狀況。在流處理中，咱們爲數據定義滑 動窗口或滾動窗口，而且在每次窗口滑動或滾動時生成結果。批處理則不一樣，咱們定義一個全局窗口，全部的記錄都屬於同一個窗口。舉例來講， 如下代碼表示一個簡單的Flink 程序，它負責每小時對某網站的訪問者計數，並按照地區分組。

val counts = visits   
.keyBy("region")   
.timeWindow(Time.hours(1))   
.sum("visits")複製代碼

若是知道輸入數據是有限的，則能夠經過如下代碼實現批處理。

val counts = visits   
.keyBy("region")   
.window(GlobalWindows.create)   
.trigger(EndOfTimeTrigger.create)   
.sum("visits")複製代碼

Flink 的不尋常之處在於，它既能夠將數據看成無限流來處理，也能夠將它看成有限流來處理。Flink 的 DataSet API 就是專爲批處理而生的，以下所示。

val counts = visits   
.groupBy("region")   
.sum("visits")複製代碼

若是輸入數據是有限的，那麼以上代碼的運行結果將與前一段代碼的相同， 可是它對於習慣使用批處理器的程序員來講更友好。

Fink批處理模型

Flink 經過一個底層引擎同時支持流處理和批處理

在流處理引擎之上，Flink 有如下機制：

• 檢查點機制和狀態機制：用於實現容錯、有狀態的處理；
• 水印機制：用於實現事件時鐘；
• 窗口和觸發器：用於限制計算範圍，並定義呈現結果的時間。

在同一個流處理引擎之上，Flink 還存在另外一套機制，用於實現高效的批處理。

• 用於調度和恢復的回溯法：由 Microsoft Dryad 引入，如今幾乎用於全部批處理器；
• 用於散列和排序的特殊內存數據結構：能夠在須要時，將一部分數據從內存溢出到硬盤上；
• 優化器：儘量地縮短生成結果的時間。

兩套機制分別對應各自的API（DataStream API 和 DataSet API）；在建立 Flink 做業時，並不能經過將二者混合在一塊兒來同時 利用 Flink 的全部功能。

在最新的版本中，Flink 支持兩種關係型的 API，Table API 和 SQL。這兩個 API 都是批處理和流處理統一的 API，這意味着在無邊界的實時數據流和有邊界的歷史記錄數據流上，關係型 API 會以相同的語義執行查詢，併產生相同的結果。Table API 和 SQL 藉助了 Apache Calcite 來進行查詢的解析，校驗以及優化。它們能夠與 DataStream 和 DataSet API 無縫集成，並支持用戶自定義的標量函數，聚合函數以及表值函數。

Table API / SQL 正在以流批統一的方式成爲分析型用例的主要 API。

DataStream API 是數據驅動應用程序和數據管道的主要API。

從長遠來看，DataStream API應該經過有界數據流徹底包含DataSet API。

Flink批處理性能

MapReduce、Tez、Spark 和 Flink 在執行純批處理任務時的性能比較。測試的批處理任務是 TeraSort 和分佈式散列鏈接。

第一個任務是 TeraSort，即測量爲 1TB 數據排序所用的時間。

TeraSort 本質上是分佈式排序問題，它由如下幾個階 段組成：

(1) 讀取階段：從 HDFS 文件中讀取數據分區；

(2) 本地排序階段：對上述分區進行部分排序；

(3) 混洗階段：將數據按照 key 從新分佈處處理節點上；

(4) 終排序階段：生成排序輸出；

(5) 寫入階段：將排序後的分區寫入 HDFS 文件。

Hadoop 發行版包含對 TeraSort 的實現，一樣的實現也能夠用於 Tez，由於 Tez 能夠執行經過MapReduce API 編寫的程序。Spark 和 Flink 的 TeraSort 實現由 Dongwon Kim 提供.用來測量的集羣由 42 臺機器組成，每臺機器 包含 12 個 CPU 內核、24GB 內存，以及 6 塊硬盤。

結果顯示，Flink 的排序時間比其餘全部系統都少。 MapReduce 用了2157 秒，Tez 用了1887 秒，Spark 用了2171 秒，Flink 則 只用了 1480 秒。

第二個任務是一個大數據集（240GB）和一個小數據集（256MB）之間的分佈式散列鏈接。結果顯示，Flink 仍然是速度最快的系統，它所用的時間分別是 Tez 和 Spark 的 1/2 和 1/4.

產生以上結果的整體緣由是，Flink 的執行過程是基於流的，這意味着各個處理階段有更多的重疊，而且混洗操做是流水線式的，所以磁盤訪問操做更少。相反，MapReduce、Tez 和 Spark 是基於批的，這意味着數據在經過網絡傳輸以前必須先被寫入磁盤。該測試說明，在使用Flink 時，系統空閒時間和磁盤訪問操做更少。

值得一提的是，性能測試結果中的原始數值可能會因集羣設置、配置和軟件版本而異。

所以，Flink 能夠用同一個數據處理框架來處理無限數據流和有限數據流，而且不會犧牲性能。

更多Flink相關文章：

穿梭時空的實時計算框架——Flink對時間的處理

Flink快速入門--安裝與示例運行

大數據實時處理的王者-Flink

Flink,Storm,SparkStreaming性能對比

更多實時計算，Flink,Kafka的技術文章歡迎關注實時流式計算