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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

還差些什么?

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

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

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

利用有界數(shù)據(jù)流操作符的屬性進(jìn)行調(diào)度：持續(xù)無界的流式應(yīng)用程序需要同時運行所有操作符?；谟薪鐢?shù)據(jù)的應(yīng)用程序可以根據(jù)其中一個操作符如何消費數(shù)據(jù)(例如，先構(gòu)建哈希表，再探測哈希表)來調(diào)度另一個操作符。這樣做可以提高資源效率。

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

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

現(xiàn)在來說說 Blink

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

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

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

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

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

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

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

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

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

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

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

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

Blink 和 Flink 的合并計劃

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

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

為了合并 Blink 的 SQL/Table API 查詢處理器增強(qiáng)功能，我們利用了 Flink 和 Blink 都具有相同 API 的事實：SQL 和 Table API。在對 Table/SQL 模塊( https://cwiki.apache.org/confluence/display/FLINK/FLIP-32%3A+Restructure+flink-table+for+future+contributions )進(jìn)行一些重組之后，我們計劃將 Blink 查詢規(guī)劃器(優(yōu)化器)和運行時(操作符)合并為當(dāng)前 SQL 運行時的附加查詢處理器。可以將其視為同一 API 的兩個不同的運行器。最開始，可以讓用戶選擇要使用哪個查詢處理器。經(jīng)過一個過渡期之后，將開發(fā)新的查詢處理器，而當(dāng)前的處理器很可能會被棄用，并最終被丟棄。因為 SQL 是一個定義良好的接口，我們預(yù)計這種轉(zhuǎn)換對用戶來說幾乎沒有影響。

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

擴(kuò)展的目錄支持、DDL 支持以及對 Hive 目錄和集成的支持目前正在進(jìn)行單獨的設(shè)計討論。

總 結(jié)

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

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

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