春節前一週，經過社區內部討論，阿里巴巴大數據引擎 Blink 作為 Flink 的分支正式開源。今天，Apache Flink 官方網站發文對 Blink 貢獻回 Flink 項目的意義作進一步說明。
春節前一週，經過社區內部討論，阿里巴巴大數據引擎 Blink 作為 Flink 的分支正式開源。今天，Apache Flink 官方網站發文對 Blink 貢獻回 Flink 項目的意義作進一步說明，並公佈了 Blink 和 Flink 的合併計劃。社區的合併計劃最初會將重點放在有界 / 批處理功能上，社區將對 SQL/Table API 模塊進行重組，將 Blink 查詢規劃器(優化器)和運行時(操作符)合併為當前 SQL 運行時的附加查詢處理器。經過一段過渡期之後，將開發新的查詢處理器，而當前的處理器很可能會被棄用。為了合併 Blink 的調度增強功能和有界數據的作業恢復功能，Flink 社區也在努力重構當前的調度功能。
前不久，經社區討論，阿里巴巴決定將 Blink 貢獻回 Flink 項目。為什麼說這對 Flink 來說是一件大事?這對 Flink 的用戶和社區來說意味著什麼?這與 Flink 的整體願景有著怎樣的關係?讓我們退後一步，一探究竟。
針對 Blink 的貢獻形式，Flink 社區討論郵件如下：
https://lists.apache.org/thread.html/2f7330e85d702a53b4a2b361149930b50f2e89d8e8a572f8ee2a0e6d@
統一的批處理和流式處理方法
從早期開始，Flink 就有意採用統一的批處理和流式處理方法。其核心構建塊是“持續處理無界的數據流”：如果可以做到這一點，還可以離線處理有界數據集(批處理)，因為有界數據集就是在某個時刻結束的數據流。
很多項目(例如 Flink、Beam 等)都支持“流式處理優先，將批處理視為流式處理的特殊情況”的理念，這個理念也經常被認為是構建跨實時和離線數據應用程序的強大方式，可以大大降低數據基礎設施的複雜性。
為什麼批處理器仍然存在?
“批處理只是流式處理的一個特例”並不意味著所有的流式處理器都能用於批處理——流式處理器的出現並沒有讓批處理器變得過時：
純流式處理系統在批處理工作負載時其實是很慢的。沒有人會認為使用流式處理器來分析海量數據是個好主意。
像 Apache Beam 這樣的統一 API 通常會根據數據是持續的(無界)還是固定的(有界)將工作負載委託給不同的運行時。
Flink 提供了一個流式 API，可以處理有界和無界的場景，同時仍然提供了單獨的 DataSet API 和運行時用於批處理，因為速度會更快。
那麼“批處理只是流式處理的一個特例”這種想法出了什麼問題?
其實這種範式並沒有錯。統一批處理和流式處理 API 只是一個方面，我們還需要利用“有界數據”這個特殊情況的某些特徵來應對批處理用例。畢竟，批處理器就是專門為這種特殊情況而準備的。
建立在流式運行時之上的批處理
我們始終認為，同時擁有一個可用於流式處理和批處理的運行時是可能的。一個流式處理優先的運行時也可以利用有界數據流的特殊屬性進行快速的批處理，就像批處理器那樣。而這就是 Flink 所採用的方法。
Flink 包含了一個網絡棧，支持低延遲 / 高吞吐的流式數據交換和高吞吐的批次 shuffle。它還提供了很多流式運行時操作符，也為有界輸入提供了專門的操作符，如果你選擇了 DataSet API 或 Table API，就可以使用這些操作符。
因此，Flink 實際上在早期就已經展示出了一些令人印象深刻的批處理性能。下面的基準測試有點舊了，但在早期很好地驗證了我們的架構方法。
排序 3.2TB(80GB/ 節點)數據所使用的時間(以秒為單位)
還差些什麼?
為了總結這個方法，並讓 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 開發者提供，給出了性能提升的粗略情況。
在 TPC-H 基準測試中，Blink 與 Flink 1.6.0 的相對性能。Blink 性能平均提升 10 倍
在 TPC-DS 基準測試中，Blink 與 Spark 的性能，將所有查詢的總時間彙總在一起。
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 社區加快實現這一目標。
來源：Flink官方網站；英文原文：https://flink.apache.org/news/2019/02/13/unified-batch-streaming-blink.html
閱讀更多 Spark大數據開發 的文章
