寫在阿里 Blink 正式開源之際

開源 · 發表 2019-01-31 08:17:38

摘要：阿里最近要正式將內部Blink開源，搞Blink 的大牛也在 AI 前線公眾號上推了文章，介紹Blink的優勢重磅！阿里Blink正式開源，重要優化點解讀，首先 spark 君對於每秒處理多少資料量，單個作業處理資料量超過400T 這些標榜不是特別在意，因為這涉及到使...

阿里最近要正式將內部Blink開源，搞Blink 的大牛也在 AI 前線公眾號上推了文章，介紹Blink的優勢重磅！阿里Blink正式開源，重要優化點解讀，首先 spark 君對於每秒處理多少資料量，單個作業處理資料量超過400T 這些標榜不是特別在意，因為這涉及到使用了多少資源，處理時長以及使用姿勢，不說清楚就是無意義的。spark君比較在意的是文中提到的Blink的一些重要的feature，大致看有 5 個方面

Hive的相容性，Blink：為了打通元資料，我們重構了 Flink catalog 的實現，並且增加了兩種 catalog，一個是基於記憶體儲存的 FlinkInMemoryCatalog，另外一個是能夠橋接 Hive metaStore 的 HiveCatalog。有了這個 HiveCatalog，Flink 作業就能讀取 Hive 的 metaData， spark君：這個功能怎麼看怎麼像從 spark 這邊抄過來的，至少是借鑑，我們都知道，spark 定義了ExternalCatalog 用來管理操作資料庫表或者註冊函式等，然後分為 InMemoryCatalog 和HiveExternalCatalog ，連名字都差不多，到底是誰抄誰呢，spark君在平時使用中，感覺 spark sql 除了像 hive 中帶有buckets的table 等極少數幾個操作不支援，spark 君敢說 Spark SQL支援絕大部分的Hive特徵。
SQL/TableAPI的優化，Blink: 我們對 SQL engine 的架構做了較大的調整。提出了全新的 Query Processor（QP），它包括了一個優化層（Query Optimizer）和一個運算元層（Query Executor）。這樣一來，流計算和批計算的在這兩層大部分的設計工作就能做到儘可能地複用, spark 君：這個就對應 spark sql 裡面的邏輯優化和物理執行兩個流程吧，這個在這裡就不用多說了吧，spark君一直孜孜不倦的給小夥伴們普及 spark邏輯優化和物理優化都做了什麼，感覺spark在這塊都優化的不能再優化了。至於說到流批覆用，我就默默提一下 structured streaming , 完全架構在 spark sql 之上，一張無限流動的大表。看文章中重點強調的 BinaryRow 和 codegen 優化方式，這都是 spark 玩了很久很久的東西了，不瞭解的小夥伴，需要多看看相關的，後續spark君會專門抽文章介紹。
更好的runtime支援，Blink: 首先 Blink 引入了 Pluggable Shuffle Architecture，開發者可以根據不同的計算模型或者新硬體的需要實現不同的 shuffle 策略進行適配。此外 Blink 還引入新的排程架構，容許開發者根據計算模型自身的特點定製不同調度器。說道這個，spark君表示我對 spark 官方最佩服的一點就是原始碼裡面體現出來的高度工程抽象能力，高內聚，低耦合，面向變化和介面程式設計，早早就支援排程全家桶了（standalone， yarn， mesos， k8s spark2.3 之後也是原生的哦）。
Zeppelin for Flink， zeppelin 就是個腳手架和大雜燴，spark也早早的入坑了，這個是小功能，就不說了。
Flink Web， Blink 這次介紹出來的多種指標展示維度，看著不錯，其實我對 spark 的介面是有些不滿意的，特別是針對 structured streaming 的指標展示，還是比較弱。

下面是一位 spark 大牛的文章，裡面很多觀點和我的一致，在這裡轉發給大家看下：

前言

今天朋友圈有篇【阿里技術】發的文章，說Blink的效能如何強悍，功能現在也已經比較完善。譬如：

Blink 在 TPC-DS 上和 Spark 相比有著非常明顯的效能優勢，而且這種效能優勢隨著資料量的增加而變得越來越大。在實際的場景這種優勢已經超過 Spark 三倍，在流計算效能上我們也取得了類似的提升。我們線上的很多典型作業，效能是原來的 3 到 5 倍。在有資料傾斜的場景，以及若干比較有挑戰的 TPC-H query，流計算效能甚至得到了數十倍的提升。

什麼時候可以享受這波紅利

還要等待一段時間。要想享受Blink的加持，大家可能還要等待一段時間，因為除了功能合併，還有程式碼質量。程式碼質量理論上應該是沒有原生flink好的。這個需要時間，不是靠人力就能搞定的。

一點憂思

阿里收購Flink母公司，然後馬上發通告，說blink要合併進flink了，之前還是商量口吻。顯然，這對於社群來說，是一個非常不友好的感覺。我猜測，社群部分優秀的人才（包括母公司）肯定會有人走的。開源專案對於PR的質量除了功能，更多的是架構，程式碼質量等等的考量。

那和Spark的對比怎麼樣？

Spark 和 Flink不在一個level級別戰鬥。Spark 從誕生沒多久開始，就朝著AI方向發展，包括內建的mllib,深度學習後也馬上抓住機遇，在2.2.x之後發力，DB公司開發了一套生態輔助系統，比如Spark deep Learning,Tensorframes, GraphFrames等等，另外還有眾多第三方框架的加持。2.3-2.4在商業版本里則已經集成了如horovod等分散式深度學習框架，所以說，2.2.x之後，Spark的主戰場早就已經是AI,而 Flink依然停留在流，批戰場。

Flink,Spark效能好對機器學習有啥影響

有人會問，機器學習對效能不是很在乎麼？現在flink效能據說那麼好？到底有多好，這是一家之言，但是在這些框架裡

效能在AI方面不是很重要，因為他們對AI重在整合，而不是自己實現。這就意味著瓶頸是在資料交換以及AI框架自身之上。模型構件好進行預測，也是對應的AI框架自己去載入，提供預測介面，其他只是wrap一層而已。

盛夏即將釋出的3.0則對AI更加友好，包括CPU/GPU的管理，K8s backend，資料交換(Spark - AI框架)的提速，內部Barrier API 的等進一步的完，顯然讓Spark在AI領域進一步保持優勢

和AI整合的基礎，Spark以有所沉澱

和AI整合的好壞，取決於Java/Scala語言和Python語言的互通的質量。Spark 在1.6之前就已經支援Python,經過這麼多年的優化，已經有了很好的經驗，最新的arrow引入讓速度更是成兩位數的提升。

Flink 盛夏之下的喧鬧

這次關於bink 合併進flink的通告不是由社群主導傳送，而是阿里技術傳送，顯然有喧賓奪主的意味，會加大他們（母公司和阿里巴巴）融合的難度。極端點，Flink可能就由一個社群專案變成一個公司產品。阿里開源了那麼多東西，有幾個達到了真正的國際影響力，並且處於持續的發展之中的？公司加持對於社群而言，短期是利好，但是如果幹預多了，長期就不被看好了。

Presto是facebook開源的並且運作，一切以滿足公司需求為最高優先順序，雖然presto很優秀，但是社群沒有主導權，極大的限制了他的發展，終於發生了分裂（大家可以自己搜搜）。

最後加一句

不要再拿Spark streaming 和Flink比了，請拿Structured streaming 以及Continue Processing 來和Flink比。為啥國內還在拿Spark Streaming 和Flink比？

因為慣性使然，structured streaming 新引入了一堆概念，並且限制也比較多，spark streaming大家把之前該遇到的問題都遇到了，而且也有一定的積累，要切換就沒那麼容易了。加上flink有阿里加持，宣傳勢頭很大,可能有的直接就從，spark streaming 切到flink去了。