　　摘要：2022年Flink作為流批一體引擎，曾經火爆一時，但是實止今日，spark 引擎任然作為批處理引擎的首選，flink引擎作為流處理的引擎，為什麼flink 都可以作為流批一體了，為什麼沒有替代spark引擎，本文將從flink引擎的功能，和spark引擎的對比，以及技術生態角度介紹，flink引擎為什麼沒有替代spark引擎。

　　01

　　—

　　Flink引擎的功能

　　前面有文章介紹了流批一體的技術架構，以及flink引擎的功能，可以參考文章：

　　Flink 如何做容錯？

　　Flink的Datastream 核心API的應用場景

　　Flink的高階API-Table API&SQL

　　實時數倉&流批一體技術發展趨勢

　　如下圖所示：

　　以上架構圖可以看出，flink的功能架構主要分為API&Libraries層和Runtime核心層兩層。

　　Flink的API&Libraries層提供了豐富的介面和庫，以支援流處理和批處理計算。對於流處理，Flink提供了DataStream API，允許開發者以高階和可維護的方式編寫複雜的流處理程式。同時，Flink還提供了大量的庫，如CEP（複雜事件處理），Table API等，用於處理流式資料的常見場景和問題。

　　對於批處理，Flink提供了DataSet API，它允許使用者以類似於傳統批處理系統的方式處理有界資料集。使用者可以使用豐富的運算子和函式對資料進行轉換和操作。

　　Flink的API&Libraries層的設計目標是提供靈活、高階和可擴充套件的介面，以滿足不同型別的計算需求。同時，Flink還提供了對Java和Scala程式語言的支援，使得開發者可以使用他們熟悉的程式語言進行開發。

　　Flink的Runtime核心層是Flink框架的核心，它提供了基礎的服務來支援分散式流處理作業的執行。這一層面對上層不同介面（比如DataStream和DataSet）提供了統一的基礎服務，使得在流式引擎下能夠同時處理批次計算和流式計算。

　　在這一層，Flink可以將DataStream和DataSet轉換成統一的可執行的Task Operator，然後將JobGraph轉換成ExecutionGraph，進行任務的排程和執行。這樣，Flink能夠像批處理一樣高效地處理大規模的資料，同時又能夠處理實時的資料流，實現了流批一體的能力。

　　這種流批一體的能力是Flink的一大優勢，它使得使用者可以在同一個引擎上執行不同型別的作業，並且能夠實現更低的延遲和更高的吞吐量。與其他引擎相比，Flink在流處理方面的特點更加突出，能夠在處理實時資料的同時保持一定的容錯性和一致性。而在批處理方面，Spark由於其廣泛的應用和優秀的效能，目前在批處理領域處於首選地位。

　　02

　　—

　　Flink引擎和Spark引擎的對比

　　在上一文中介紹了spark引擎的主要功能，可以參考文章：

　　一文了解Spark引擎的優勢及應用場景

　　從兩個引擎的功能架構上好似差不多，都支援SQL，實時計算，機器學習庫和圖計算。也有大資料開發對兩個引擎進行的詳細的對比：

　　功能上的主要區別是：

　　1、Spark 和Flink 在流處理上，spark是利用的微批處理模擬流資料，而flink是採用的真正的流資料處理方式，flink是採用流資料模擬批資料處理。

　　在執行引擎這一層，流處理系統與批處理系統最大不同在於節點間的資料傳輸方式：

　　對於一個流處理系統，其節點間資料傳輸的標準模型是：當一條資料被處理完成後，序列化到快取中，然後立刻透過網路傳輸到下一個節點，由下一個節點繼續處理

　　對於一個批處理系統，其節點間資料傳輸的標準模型是：當一條資料被處理完成後，序列化到快取中，並不會立刻透過網路傳輸到下一個節點，當快取寫滿，就持久化到本地硬碟上，當所有資料都被處理完成後，才開始將處理後的資料透過網路傳輸到下一個節點。

　　對於Spark來說預設是批處理的模式，流處理模式是採用微批來處理，而Flink採用的是快取塊的超時時間引數來控制是流處理還是批處理。

　　如果快取塊的超時值為0，則Flink的資料傳輸方式類似上文所提到流處理系統的標準模型，此時系統可以獲得最低的處理延遲

　　如果快取塊的超時值為無限大/-1，則Flink的資料傳輸方式類似上文所提到批處理系統的標準模型，此時系統可以獲得最高的吞吐量

　　timeoutMillis > 0 表示最長等待 timeoutMillis 時間，就會flush//是批處理

　　timeoutMillis = 0 表示每條資料都會觸發 flush，直接將資料傳送到下游，相當於沒有Buffer了(避免設定為0，可能導致效能下降)//流處理

　　timeoutMillis = -1 表示只有等到 buffer滿了或 CheckPoint的時候，才會flush。相當於取消了 timeout 策略 //批處理。

　　2、計算視窗，SPARK是基於視窗時間，而flink可以基於時間也可以基於計數。

　　3、狀態後端不同；Spark的狀態後端是指用於儲存和管理Spark應用程式中的狀態資料的儲存系統。在Spark中，狀態是指在執行計算過程中需要持久化和共享的資料，例如累加器和廣播變數等。Spark提供了不同的狀態後端選項，包括記憶體、磁碟和HDFS等、

　　Flink的狀態後端是用於儲存和管理作業狀態的一種機制。它用於儲存當前作業的狀態、檢查點資料以及儲存的使用者狀態。透過狀態後端，Flink能夠在發生故障時保證作業的一致性和容錯性。

　　Flink支援多種型別的狀態後端，包括記憶體、檔案系統和分散式儲存系統等。

　　4、延遲，spark是秒級，flink是亞秒級。

　　從以上的功能分析，好像是flink更具優勢，那麼為什麼flink沒有替代spark引擎了？

　　03

　　—

　　Flink引擎為什麼沒能替代Spark引擎？

　　Flink引擎和Spark引擎作為流和批處理引擎，處理的資料大部分來源資料湖，資料倉儲的資料是結構化的資料，一般採用批處理就可以，那麼資料湖的管理框架是哪些了？之前有文章介紹了資料湖相關技術框架：

　　資料湖：從前世到今身的演進與選型探索

　　管理引擎如何實現資料湖的ACID特性

　　其中說到資料湖目前主要的三個管理引擎DeltaLake、Hudi、Iceberge；其中也做了對比分析。

　　可以看到，DeltaLake對flink引擎不支援，因為flink引擎並不是hadoop生態下的引擎，spark引擎是hadoop生態下的引擎。而另外兩個資料湖管理引擎都支援spark引擎。而hudi管理引擎是用 Spark 實現的一個通用資料湖框架，它與 Spark 的繫結可謂是深入骨髓。如果要使用flink引擎，需要將hudi和spark引擎解藕。而對於Iceberge引擎，flink支援的也是不夠完善。主要體現在：

　　1、Iceberg目前不支援Flink SQL 查詢表的後設資料資訊，需要使用Java API 實現。

　　2、Flink不支援建立帶有隱藏分割槽的Iceberg表

　　3、Flink不支援帶有WaterMark的Iceberg表

　　4、Flink不支援新增列、刪除列、重新命名列操作。

　　5、Flink對Iceberg Connector支援並不完善。

　　以上一些重要的功能在Iceberg上支援的不好，也導致flink在Iceberg上使用的並不好。

　　由於spark引擎已經和DeltaLake、Hudi做了強的技術繫結，以及三個管理引擎的運營情況來看，SPARK依然是最頂流的計算引擎。

　　我們再來看看 DeltaLake、Hudi、Iceberge三個管理引擎的社群情況：