春節(jié)前一周，經過社區(qū)內部討論，阿里巴巴大數(shù)據引擎 Blink 作為 Flink 的分支正式開源。如今，Apache Flink 官方網站發(fā)文對 Blink 貢獻回 Flink 項目的意義作進一步說明，并公布了 Blink 和 Flink 的合并計劃。社區(qū)的合并計劃最初會將重點放在有界 / 批處理功能上，社區(qū)將對 SQL/Table API 模塊進行重組，將 Blink 查詢規(guī)劃器(優(yōu)化器)和運行時(操作符)合并為當前 SQL 運行時的附加查詢處理器。經過一段過渡期之后，將開發(fā)新的查詢處理器，而當前的處理器很可能會被棄用。為了合并 Blink 的調度增強功能和有界數(shù)據的作業(yè)恢復功能，F(xiàn)link 社區(qū)也在努力重構當前的調度功能。

前不久，經社區(qū)討論，阿里巴巴決定將 Blink 貢獻回 Flink 項目。為什么說這對 Flink 來說是一件大事?這對 Flink 的用戶和社區(qū)來說意味著什么?這與 Flink 的整體愿景有著怎樣的關系?讓我們退后一步，一探究竟。

針對 Blink 的貢獻形式，F(xiàn)link 社區(qū)討論郵件如下：

https://lists.apache.org/thread.html/2f7330e85d702a53b4a2b361149930b50f2e89d8e8a572f8ee2a0e6d@

統(tǒng)一的批處理和流式處理方法

從早期開始，F(xiàn)link 就有意采用統(tǒng)一的批處理和流式處理方法。其核心構建塊是“持續(xù)處理無界的數(shù)據流”：如果可以做到這一點，還可以離線處理有界數(shù)據集(批處理)，因為有界數(shù)據集就是在某個時刻結束的數(shù)據流。

很多項目(例如 Flink、Beam 等)都支持“流式處理優(yōu)先，將批處理視為流式處理的特殊情況”的理念，這個理念也經常被認為是構建跨實時和離線數(shù)據應用程序的強大方式，可以大大降低數(shù)據基礎設施的復雜性。

為什么批處理器仍然存在?

“批處理只是流式處理的一個特例”并不意味著所有的流式處理器都能用于批處理——流式處理器的出現(xiàn)并沒有讓批處理器變得過時：

純流式處理系統(tǒng)在批處理工作負載時其實是很慢的。沒有人會認為使用流式處理器來分析海量數(shù)據是個好主意。

像 Apache Beam 這樣的統(tǒng)一 API 通常會根據數(shù)據是持續(xù)的(無界)還是固定的(有界)將工作負載委托給不同的運行時。

Flink 提供了一個流式 API，可以處理有界和無界的場景，同時仍然提供了單獨的 DataSet API 和運行時用于批處理，因為速度會更快。

那么“批處理只是流式處理的一個特例”這種想法出了什么問題?

其實這種范式并沒有錯。統(tǒng)一批處理和流式處理 API 只是一個方面，我們還需要利用“有界數(shù)據”這個特殊情況的某些特征來應對批處理用例。畢竟，批處理器就是專門為這種特殊情況而準備的。

建立在流式運行時之上的批處理

我們始終認為，同時擁有一個可用于流式處理和批處理的運行時是可能的。一個流式處理優(yōu)先的運行時也可以利用有界數(shù)據流的特殊屬性進行快速的批處理，就像批處理器那樣。而這就是 Flink 所采用的方法。

Flink 包含了一個網絡棧，支持低延遲 / 高吞吐的流式數(shù)據交換和高吞吐的批次 shuffle。它還提供了很多流式運行時操作符，也為有界輸入提供了專門的操作符，如果你選擇了 DataSet API 或 Table API，就可以使用這些操作符。

因此，F(xiàn)link 實際上在早期就已經展示出了一些令人印象深刻的批處理性能。下面的基準測試有點舊了，但在早期很好地驗證了我們的架構方法。

排序 3.2TB(80GB/ 節(jié)點)數(shù)據所使用的時間(以秒為單位)

還差些什么?

為了總結這個方法，并讓 Flink 在有界數(shù)據(批處理)方面達到新的水平，我們需要做出更多的增強。我們認為下面這些特性是實現(xiàn)我們愿景的關鍵:

真正統(tǒng)一的運行時操作符棧：目前，有界和無界操作符具有不同的網絡和線程模型，不會混在一起，也不匹配。最初是因為批處理操作符遵循的是“拉取模型”(為了方便批處理算法)，而流式操作符遵循的是“推模型”(可以獲得更好的延遲 / 吞吐量)。在統(tǒng)一的操作符棧中，持續(xù)流式操作符是基礎。在操作有界數(shù)據時，如果沒有延遲方面的約束，API 或查詢優(yōu)化器可以從更大的操作符集中選擇合適的操作符。例如，優(yōu)化器可以選擇一個特殊的連接操作符，先完全讀取一個輸入流，然后再讀取第二個輸入流。

利用有界數(shù)據流來減小容錯范圍：如果輸入數(shù)據是有界的，可以在 shuffle(內存或磁盤)期間緩沖數(shù)據，并在發(fā)生故障后重放數(shù)據。這樣可以實現(xiàn)更細粒度的故障恢復，也更有效。

利用有界數(shù)據流操作符的屬性進行調度：持續(xù)無界的流式應用程序需要同時運行所有操作符。基于有界數(shù)據的應用程序可以根據其中一個操作符如何消費數(shù)據(例如，先構建哈希表，再探測哈希表)來調度另一個操作符。這樣做可以提高資源效率。

為 DataStream API 啟用這些特殊優(yōu)化：目前只有 Table API 在處理有界數(shù)據時激活了這些優(yōu)化。

SQL 的性能和覆蓋范圍：SQL 是事實上的標準數(shù)據語言，雖然它被用在持續(xù)流式處理種，但并不適用于有界 / 批處理的情況。為了與優(yōu)秀批處理引擎展開競爭，F(xiàn)link 需要提升 SQL 查詢執(zhí)行覆蓋率和性能。雖然 Flink 的核心數(shù)據平面具有很高的性能，但 SQL 執(zhí)行的速度在很大程度上取決于優(yōu)化器規(guī)則、豐富的操作符和代碼生成，等等。

現(xiàn)在來說說 Blink

Blink 是 Flink 的一個分支，最初在阿里巴巴內部創(chuàng)建的，針對內部用例對 Flink 進行改進。Blink 添加了一系列改進和集成(https://github.com/apache/flink/blob/blink/README.md )，其中有很多與有界數(shù)據 / 批處理和 SQL 有關。實際上，在上面的功能列表中，除了第 4 項外，Blink 在其他方面都邁出了重要的一步：

統(tǒng)一的流式操作符：Blink 擴展了 Flink 的流式運行時操作符模型，支持選擇性讀取不同的輸入源，同時保持推送模型的低延遲特性。這種對輸入源的選擇性讀取可以更好地支持一些算法(例如相同操作符的混合散列連接)和線程模型(通過 RocksDB 的連續(xù)對稱連接)。這些操作符為“側邊輸入”(https://cwiki.apache.org/confluence/display/FLINK/FLIP-17+Side+Inputs+for+DataStream+API )等新功能打下了基礎。

Table API 和 SQL 查詢處理器：與新的 Flink 主分支相比，SQL 查詢處理器是演變得最多的一個組件：

Flink 目前將查詢轉換為 DataSet 或 DataStream 程序(取決于輸入的特性)，而 Blink 會將查詢轉換為上述流式操作符的數(shù)據流。

Blink 為常見的 SQL 操作添加了更多的運行時操作符，如半連接(semi-join)、反連接(anti-join)等。

查詢規(guī)劃器(優(yōu)化器)仍然是基于 Apache Calcite，但提供了更多的優(yōu)化規(guī)則(包括連接重排序)，并且使用了適當?shù)某杀灸Ｐ汀?/p>

更加積極的流式操作符鏈接。

擴展通用數(shù)據結構(分類器、哈希表)和序列化器，在操作二進制數(shù)據上更進一步，并減小了序列化開銷。代碼生成被用于行序列化器。

改進的調度和故障恢復：最后，Blink 實現(xiàn)了對任務調度和容錯的若干改進。調度策略通過利用操作符處理輸入數(shù)據的方式來更好地使用資源。故障轉移策略沿著持久 shuffle 的邊界進行更細粒度的恢復。不需重新啟動正在運行的應用程序就可以替換發(fā)生故障的 JobManager。

Blink 的變化帶來了大幅度的性能提升。以下數(shù)據由 Blink 開發(fā)者提供，給出了性能提升的粗略情況。

在 TPC-H 基準測試中，Blink 與 Flink 1.6.0 的相對性能。Blink 性能平均提升 10 倍

在 TPC-DS 基準測試中，Blink 與 Spark 的性能，將所有查詢的總時間匯總在一起。

Blink 和 Flink 的合并計劃

Blink 的代碼目前已經作為 Flink 代碼庫的一個分支(https://github.com/apache/flink/tree/blink )對外開放。合并這么多變更是一項艱巨的挑戰(zhàn)，同時還要盡可能保持合并過程不要造成任何中斷，并使公共 API 盡可能保持穩(wěn)定。

社區(qū)的合并計劃最初將重點放在上述的有界 / 批處理功能上，并遵循以下方法以確保能夠順利集成：

為了合并 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 查詢規(guī)劃器(優(yōu)化器)和運行時(操作符)合并為當前 SQL 運行時的附加查詢處理器。可以將其視為同一 API 的兩個不同的運行器。最開始，可以讓用戶選擇要使用哪個查詢處理器。經過一個過渡期之后，將開發(fā)新的查詢處理器，而當前的處理器很可能會被棄用，并最終被丟棄。因為 SQL 是一個定義良好的接口，我們預計這種轉換對用戶來說幾乎沒有影響。

為了合并 Blink 的調度增強功能和有界數(shù)據的作業(yè)恢復功能，F(xiàn)link 社區(qū)已經在努力重構當前的調度功能，并添加對可插拔調度和故障轉移策略的支持。在完成這項工作后，我們就可以將 Blink 的調度和恢復策略作為新查詢處理器的調度策略。最后，我們計劃將新的調度策略應用于有界 DataStream 程序。

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

總 結

我們相信未來的數(shù)據處理技術棧會以流式處理為基礎：流式處理的優(yōu)雅，能夠以相同的方式對離線處理(批處理)、實時數(shù)據處理和事件驅動的應用程序進行建模，同時還能提供高性能和一致性，這些實在是太吸引人了。成都加米谷大數(shù)據培訓，大數(shù)據開發(fā)，數(shù)據分析與挖掘，小班教學，免費試聽。

要讓流式處理器實現(xiàn)與專用批處理器相同的性能，利用有界數(shù)據的某些屬性是關鍵。Flink 支持批處理，但它的下一步是要構建統(tǒng)一的運行時，并成為一個可以與批處理系統(tǒng)相競爭的流式處理器。阿里巴巴貢獻的 Blink 有助于 Flink 社區(qū)加快實現(xiàn)這一目標。

英文原文：https://flink.apache.org/news/2019/02/13/unified-batch-streaming-blink.html