春節(jié)前一周，經(jīng)過(guò)社區(qū)內(nèi)部討論，阿里巴巴大數(shù)據(jù)引擎 Blink 作為 Flink 的分支正式開(kāi)源。如今，Apache Flink 官方網(wǎng)站發(fā)文對(duì) Blink 貢獻(xiàn)回 Flink 項(xiàng)目的意義作進(jìn)一步說(shuō)明，并公布了 Blink 和 Flink 的合并計(jì)劃。社區(qū)的合并計(jì)劃最初會(huì)將重點(diǎn)放在有界 / 批處理功能上，社區(qū)將對(duì) SQL/Table API 模塊進(jìn)行重組，將 Blink 查詢規(guī)劃器(優(yōu)化器)和運(yùn)行時(shí)(操作符)合并為當(dāng)前 SQL 運(yùn)行時(shí)的附加查詢處理器。經(jīng)過(guò)一段過(guò)渡期之后，將開(kāi)發(fā)新的查詢處理器，而當(dāng)前的處理器很可能會(huì)被棄用。為了合并 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 項(xiàng)目。為什么說(shuō)這對(duì) Flink 來(lái)說(shuō)是一件大事?這對(duì) Flink 的用戶和社區(qū)來(lái)說(shuō)意味著什么?這與 Flink 的整體愿景有著怎樣的關(guān)系?讓我們退后一步，一探究竟。

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

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

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

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

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

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

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

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

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

Flink 提供了一個(gè)流式 API，可以處理有界和無(wú)界的場(chǎng)景，同時(shí)仍然提供了單獨(dú)的 DataSet API 和運(yùn)行時(shí)用于批處理，因?yàn)樗俣葧?huì)更快。

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

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

建立在流式運(yùn)行時(shí)之上的批處理

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

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

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

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

還差些什么?

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

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

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

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

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

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

現(xiàn)在來(lái)說(shuō)說(shuō) Blink

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

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

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

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

Blink 為常見(jiàn)的 SQL 操作添加了更多的運(yùn)行時(shí)操作符，如半連接(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)一步，并減小了序列化開(kāi)銷。代碼生成被用于行序列化器。

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

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

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

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

Blink 和 Flink 的合并計(jì)劃

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

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

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

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

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

總 結(jié)

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

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

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