官宣！阿里Blink和Flink合併計劃出爐

apache已公開合併計劃，點擊可閱讀原文《Batch as a Special Case of Streaming and Alibaba's contribution of Blink》，由AI前線進行了翻譯。

**春節前一週，通過社區內部討論，阿里巴巴大數據引擎 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/thre...

統一的批處理和流式處理方法

從早期開始，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/fli... ），其中有不少與有界數據 / 批處理和 SQL 有關。實際上，在上面的功能列表中，除了第 4 項外，Blink 在其餘方面都邁出了重要的一步：

統一的流式操做符：Blink 擴展了 Flink 的流式運行時操做符模型，支持選擇性讀取不一樣的輸入源，同時保持推送模型的低延遲特性。這種對輸入源的選擇性讀取能夠更好地支持一些算法（例如相同操做符的混合散列鏈接）和線程模型（經過 RocksDB 的連續對稱鏈接）。這些操做符爲「側邊輸入」（https://cwiki.apache.org/conf... ）等新功能打下了基礎。

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/fli... ）對外開放。合併這麼多變動是一項艱鉅的挑戰，同時還要儘量保持合併過程不要形成任何中斷，並使公共 API 儘量保持穩定。

社區的合併計劃最初將重點放在上述的有界 / 批處理功能上，並遵循如下方法以確保可以順利集成：

爲了合併 Blink 的 SQL/Table API 查詢處理器加強功能，咱們利用了 Flink 和 Blink 都具備相同 API 的事實：SQL 和 Table API。在對 Table/SQL 模塊（https://cwiki.apache.org/conf...）進行一些重組以後，咱們計劃將 Blink 查詢規劃器（優化器）和運行時（操做符）合併爲當前 SQL 運行時的附加查詢處理器。能夠將其視爲同一 API 的兩個不一樣的運行器。最開始，可讓用戶選擇要使用哪一個查詢處理器。

通過一個過渡期以後，將開發新的查詢處理器，而當前的處理器極可能會被棄用，並最終被丟棄。由於 SQL 是一個定義良好的接口，咱們預計這種轉換對用戶來講幾乎沒有影響。

爲了合併 Blink 的調度加強功能和有界數據的做業恢復功能，Flink 社區已經在努力重構當前的調度功能，並添加對可插拔調度和故障轉移策略的支持。

在完成這項工做後，咱們就能夠將 Blink 的調度和恢復策略做爲新查詢處理器的調度策略。最後，咱們計劃將新的調度策略應用於有界 DataStream 程序。

擴展的目錄支持、DDL 支持以及對 Hive 目錄和集成的支持目前正在進行單獨的設計討論。

總 結

咱們相信將來的數據處理技術棧會以流式處理爲基礎：流式處理的優雅，可以以相同的方式對離線處理（批處理）、實時數據處理和事件驅動的應用程序進行建模，同時還能提供高性能和一致性，這些實在是太吸引人了。

要讓流式處理器實現與專用批處理器相同的性能，利用有界數據的某些屬性是關鍵。Flink 支持批處理，但它的下一步是要構建統一的運行時，併成爲一個能夠與批處理系統相競爭的流式處理器。阿里巴巴貢獻的 Blink 有助於 Flink 社區加快實現這一目標。

本文做者：雲學習小組

閱讀原文

本文爲雲棲社區原創內容，未經容許不得轉載。