春節前一週，經過社區內部討論，阿里巴巴大數據引擎Blink作爲Flink的分支正式開源。今天，Apache Flink官方網站發文對Blink貢獻回Flink項目的意義作進一步說明，並公佈了Blink和Flink的合併計劃。社區的合併計劃最初會將重點放在有界/批處理功能上，社區將對SQL/Table API模塊進行重組，將Blink查詢規劃器（優化器）和運行時（操作符）合併爲當前SQL運行時的附加查詢處理器。經過一段過渡期之後，將開發新的查詢處理器，而當前的處理器很可能會被棄用。爲了合併Blink的調度增強功能和有界數據的作業恢復功能，Flink社區也在努力重構當前的調度功能。
前不久，經社區討論，阿里巴巴決定將Blink貢獻回Flink項目。爲什麼說這對Flink來說是一件大事？這對Flink的用戶和社區來說意味着什麼？這與Flink的整體願景有着怎樣的關係？讓我們退後一步，一探究竟。
針對Blink的貢獻形式，Flink社區討論郵件如下：
統一的批處理和流式處理方法
從早期開始，Flink就有意採用統一的批處理和流式處理方法。其核心構建塊是“持續處理無界的數據流”：如果可以做到這一點，還可以離線處理有界數據集（批處理），因爲有界數據集就是在某個時刻結束的數據流。
很多項目（例如Flink、Beam等）都支持“流式處理優先，將批處理視爲流式處理的特殊情況”的理念，這個理念也經常被認爲是構建跨實時和離線數據應用程序的強大方式，可以大大降低數據基礎設施的複雜性。
爲什麼批處理器仍然存在？
“批處理只是流式處理的一個特例”並不意味着所有的流式處理器都能用於批處理——流式處理器的出現並沒有讓批處理器變得過時：
-
純流式處理系統在批處理工作負載時其實是很慢的。沒有人會認爲使用流式處理器來分析海量數據是個好主意。
-
像Apache Beam這樣的統一API通常會根據數據是持續的（無界）還是固定的（有界）將工作負載委託給不同的運行時。
-
Flink提供了一個流式API，可以處理有界和無界的場景，同時仍然提供了單獨的DataSet API和運行時用於批處理，因爲速度會更快。
那麼“批處理只是流式處理的一個特例”這種想法出了什麼問題？
其實這種範式並沒有錯。統一批處理和流式處理API只是一個方面，我們還需要利用“有界數據”這個特殊情況的某些特徵來應對批處理用例。畢竟，批處理器就是專門爲這種特殊情況而準備的。
建立在流式運行時之上的批處理
我們始終認爲，同時擁有一個可用於流式處理和批處理的運行時是可能的。一個流式處理優先的運行時也可以利用有界數據流的特殊屬性進行快速的批處理，就像批處理器那樣。而這就是Flink所採用的方法。
Flink包含了一個網絡棧，支持低延遲/高吞吐的流式數據交換和高吞吐的批次shuffle。它還提供了很多流式運行時操作符，也爲有界輸入提供了專門的操作符，如果你選擇了DataSet API或Table API，就可以使用這些操作符。
因此，Flink實際上在早期就已經展示出了一些令人印象深刻的批處理性能。下面的基準測試有點舊了，但在早期很好地驗證了我們的架構方法。
還差些什麼？
爲了總結這個方法，並讓Flink在有界數據（批處理）方面達到最新的水平，我們需要做出更多的增強。我們認爲下面這些特性是實現我們願景的關鍵:
-
真正統一的運行時操作符棧：目前，有界和無界操作符具有不同的網絡和線程模型，不會混在一起，也不匹配。最初是因爲批處理操作符遵循的是“拉取模型”（爲了方便批處理算法），而流式操作符遵循的是“推模型”（可以獲得更好的延遲/吞吐量）。在統一的操作符棧中，持續流式操作符是基礎。在操作有界數據時，如果沒有延遲方面的約束，API或查詢優化器可以從更大的操作符集中選擇合適的操作符。例如，優化器可以選擇一個特殊的連接操作符，先完全讀取第一個輸入流，然後再讀取第二個輸入流。
-
利用有界數據流來減小容錯範圍：如果輸入數據是有界的，可以在shuffle（內存或磁盤）期間緩衝數據，並在發生故障後重放數據。這樣可以實現更細粒度的故障恢復，也更有效。
-
利用有界數據流操作符的屬性進行調度：持續無界的流式應用程序需要同時運行所有操作符。基於有界數據的應用程序可以根據其中一個操作符如何消費數據（例如，先構建哈希表，再探測哈希表）來調度另一個操作符。這樣做可以提高資源效率。
-
爲DataStream API啓用這些特殊優化：目前只有Table API在處理有界數據時激活了這些優化。
-
SQL的性能和覆蓋範圍：SQL是事實上的標準數據語言，雖然它被用在持續流式處理種，但並不適用於有界/批處理的情況。爲了與最佳批處理引擎展開競爭，Flink需要提升SQL查詢執行覆蓋率和性能。雖然Flink的核心數據平面具有很高的性能，但SQL執行的速度在很大程度上取決於優化器規則、豐富的操作符和代碼生成，等等。
現在來說說Blink
Blink是Flink的一個分支，最初在阿里巴巴內部創建的，針對內部用例對Flink進行改進。Blink添加了一系列改進和集成（https://github.com/apache/flink/blob/blink/README.md ），其中有很多與有界數據/批處理和SQL有關。實際上，在上面的功能列表中，除了第4項外，Blink在其他方面都邁出了重要的一步：
統一的流式操作符：Blink擴展了Flink的流式運行時操作符模型，支持選擇性讀取不同的輸入源，同時保持推送模型的低延遲特性。這種對輸入源的選擇性讀取可以更好地支持一些算法（例如相同操作符的混合散列連接）和線程模型（通過RocksDB的連續對稱連接）。這些操作符爲“側邊輸入”（https://cwiki.apache.org/confluence/display/FLINK/FLIP-17+Side+Inputs+for+DataStream+API ）等新功能打下了基礎。
Table API和SQL查詢處理器：與最新的Flink主分支相比，SQL查詢處理器是演變得最多的一個組件：
-
Flink目前將查詢轉換爲DataSet或DataStream程序（取決於輸入的特性），而Blink會將查詢轉換爲上述流式操作符的數據流。
-
Blink爲常見的SQL操作添加了更多的運行時操作符，如半連接（semi-join）、反連接（anti-join）等。
-
查詢規劃器（優化器）仍然是基於Apache Calcite，但提供了更多的優化規則（包括連接重排序），並且使用了適當的成本模型。
-
更加積極的流式操作符鏈接。
-
擴展通用數據結構（分類器、哈希表）和序列化器，在操作二進制數據上更進一步，並減小了序列化開銷。代碼生成被用於行序列化器。
改進的調度和故障恢復：最後，Blink實現了對任務調度和容錯的若干改進。調度策略通過利用操作符處理輸入數據的方式來更好地使用資源。故障轉移策略沿着持久shuffle的邊界進行更細粒度的恢復。不需重新啓動正在運行的應用程序就可以替換髮生故障的JobManager。
Blink的變化帶來了大幅度的性能提升。以下數據由Blink開發者提供，給出了性能提升的粗略情況。
Blink和Flink的合併計劃
Blink的代碼目前已經作爲Flink代碼庫的一個分支（https://github.com/apache/flink/tree/blink ）對外開放。合併這麼多變更是一項艱鉅的挑戰，同時還要儘可能保持合併過程不要造成任何中斷，並使公共API儘可能保持穩定。
社區的合併計劃最初將重點放在上述的有界/批處理功能上，並遵循以下方法以確保能夠順利集成：
-
爲了合併Blink的SQL/Table API查詢處理器增強功能，我們利用了Flink和Blink都具有相同API的事實：SQL和Table API。在對Table/SQL模塊（ https://cwiki.apache.org/confluence/display/FLINK/FLIP-32%3A+Restructure+flink-table+for+future+contributions ）進行一些重組之後，我們計劃將Blink查詢規劃器（優化器）和運行時（操作符）合併爲當前SQL運行時的附加查詢處理器。可以將其視爲同一API的兩個不同的運行器。最開始，可以讓用戶選擇要使用哪個查詢處理器。經過一個過渡期之後，將開發新的查詢處理器，而當前的處理器很可能會被棄用，並最終被丟棄。因爲SQL是一個定義良好的接口，我們預計這種轉換對用戶來說幾乎沒有影響。
-
爲了合併Blink的調度增強功能和有界數據的作業恢復功能，Flink社區已經在努力重構當前的調度功能，並添加對可插拔調度和故障轉移策略的支持。在完成這項工作後，我們就可以將Blink的調度和恢復策略作爲新查詢處理器的調度策略。最後，我們計劃將新的調度策略應用於有界DataStream程序。
-
擴展的目錄支持、DDL支持以及對Hive目錄和集成的支持目前正在進行單獨的設計討論。
總 結
我們相信未來的數據處理技術棧會以流式處理爲基礎：流式處理的優雅，能夠以相同的方式對離線處理（批處理）、實時數據處理和事件驅動的應用程序進行建模，同時還能提供高性能和一致性，這些實在是太吸引人了。
要讓流式處理器實現與專用批處理器相同的性能，利用有界數據的某些屬性是關鍵。Flink支持批處理，但它的下一步是要構建統一的運行時，併成爲一個可以與批處理系統相競爭的流式處理器。阿里巴巴貢獻的Blink有助於Flink社區加快實現這一目標。
英文原文：
https://flink.apache.org/news/2019/02/13/unified-batch-streaming-blink.html