終於等到你！阿里正式向 Apache Flink 貢獻 Blink 原始碼

阿里技術_發表於2019-01-28

640?wx_fmt=png

阿里妹導讀：如同我們去年12月在 Flink Forward China 峰會所約，阿里巴巴內部 Flink 版本 Blink 將於 2019 年 1 月底正式開源。今天，我們終於等到了這一刻。

阿里資深技術專家大沙，將為大家詳細介紹本次開源的Blink主要功能和優化點，希望與業界同仁共同攜手，推動Flink社群進一步發展。

Blink on GitHub

https://github.com/apache/flink/tree/blink

Blink簡介

Apache Flink是德國柏林工業大學的幾個博士生和研究生從學校開始做起來的專案，早期叫做Stratosphere。2014年，StratoSphere專案中的核心成員從學校出來開發了Flink，同時將Flink計算的主流方向定位為流計算，並在同年將Flink捐贈Apache，後來快速孵化成為Apache的頂級專案。現在Flink是業界公認的最好的大資料流計算引擎。

640?wx_fmt=png

阿里巴巴在2015年開始嘗試使用Flink。但是阿里的業務體量非常龐大，挑戰也很多。彼時的Flink不管是規模還是穩定性尚未經歷實踐，成熟度有待商榷。為了把這麼大的業務體量支援好，我們不得不在Flink之上做了一系列的改進，所以阿里巴巴維護了一個內部版本的Flink，它的名字叫做Blink。

基於Blink的計算平臺於2016年正式上線。截至目前，阿里絕大多數的技術部門都在使用Blink。Blink一直在阿里內部錯綜複雜的業務場景中鍛鍊成長著。對於內部使用者反饋的各種效能、資源使用率、易用性等諸多方面的問題，Blink都做了針對性的改進。雖然現在Blink在阿里內部用的最多的場景主要還是在流計算，但是在批計算場景也有不少業務上線使用了。例如，在搜尋和推薦的演算法業務平臺中，它使用Blink同時進行流計算和批處理。Blink被用來實現了流批一體化的樣本生成和特徵抽取這些流程，能夠處理的特徵數達到了數千億，而且每秒鐘處理數億條訊息。在這個場景的批處理中，我們單個作業處理的資料量已經超過400T，並且為了節省資源，我們的批處理作業是和流計算作業以及搜尋的線上引擎執行在同樣的機器上。所以大家可以看到流批一體化已經在阿里巴巴取得了極大的成功，我們希望這種成功和阿里巴巴內部的經驗都能夠帶回給社群。

Blink開源的背景

其實從我們選擇Flink的第一天開始我們就一直和社群緊密合作。過去的這幾年我們也一直在把阿里對Flink 的改進推回社群。從2016年開始我們已經將流計算SQL的大部分功能，針對runtime的穩定性和效能優化做的若干重要設計都推回了社群。但是Blink本身發展迭代的速度非常快，而社群有自己的步伐，很多時候可能無法把我們的變更及時推回去。對於社群來說，一些大的功能和重構，需要達成共識後，才能被接受，這樣才能更好地保證開源專案的質量，但是同時就會導致推入的速度變得相對較慢。經過這幾年的開發迭代，我們這邊和社群之間的差距已經變得比較大了。

Blink 有一些很好的新功能，比如效能優越的批處理功能，在社群的版本是沒有的。在過去這段時間裡，我們不斷聽到有人在詢問Blink的各種新功能。期望Blink儘快開源的呼聲越來越大。我們一直在思考如何開源的問題，一種方案就是和以前一樣，繼續把各種功能和優化分解，逐個和社群討論，慢慢地推回Flink。但這顯然不是大家所期待的。另一個方案，就是先完整的儘可能的多的把程式碼開源，讓社群的開發者能夠儘快試用起來。第二個方案很快收到社群廣大使用者的支援。因此，從2018年年中開始我們就開始做開源的相關準備。經過半年的努力，我們終於把大部分Blink的功能梳理好，開源了出來。

Blink開源的方式

我們把程式碼貢獻出來，是為了讓大家能先嚐試一些他們感興趣的功能。Blink永遠不會單獨成為一個獨立的開源專案來運作，他一定是Flink的一部分。開源後我們期望能找到辦法以最快的方式將Blink merge到Flink中去。Blink開源只有一個目的，就是希望 Flink 做得更好。Apache Flink 是一個社群專案，Blink以什麼樣的形式進入 Flink 是最合適的，怎麼貢獻是社群最希望的方式，我們都要和社群一起討論。

在過去的一段時間內，我們在Flink社群徵求了廣泛的意見，大家一致認為將本次開源的Blink程式碼作為Flink的一個branch直接推回到Apache Flink專案中是最合適的方式。並且我們和社群也一起討論規劃出一套能夠快速merge Blink到Flink master中的方案（具體細節可以檢視Flink社群正在討論的FLIP32）。我們期望這個merge能夠在很短的時間內完成。這樣我們之後的Machine Learning等其他新功能就可以直接推回到Flink master。相信用不了多久，Flink 和 Blink 就完全合二為一了。在那之後，阿里巴巴將直接使用Flink用於生產，並同時協助社群一起來維護Flink。

本次開源的Blink的主要功能和優化點

本次開源的Blink程式碼在Flink 1.5.1版本之上，加入了大量的新功能，以及在效能和穩定性上的各種優化。主要貢獻包括，阿里巴巴在流計算上積累的一些新功能和效能的優化，一套完整的（能夠跑通全部TPC-H/TPC-DS，能夠讀取Hive meta和data）高效能Batch SQL，以及一些以提升易用性為主的功能（包括支援更高效的interactive programming, 與zeppelin更緊密的結合, 以及體驗和效能更佳的Flink web）。未來我們還將繼續給Flink貢獻在AI，IoT以及其他新領域的功能和優化。更多的關於這一版本Blink release的細節，請參考Blink程式碼根目錄下的README.md文件。下面，我來分模組介紹下Blink主要的新的功能和優化點。

Runtime

為了更好的支援batch processing，以及解決阿里巴巴大規模生產場景中遇到的各種挑戰，Blink對Runtime架構、效率、穩定性方面都做了大量改進。在架構方面，首先Blink引入了Pluggable ShuffleArchitecture，開發者可以根據不同的計算模型或者新硬體的需要實現不同的shuffle策略進行適配。此外Blink還引入新的排程架構，容許開發者根據計算模型自身的特點定製不同排程器。為了優化效能，Blink可以讓運算元更加靈活的chain在一起，避免了不必要的資料傳輸開銷。在Pipeline Shuffle模式中，使用了ZeroCopy減少了網路層記憶體消耗。在BroadCast Shuffle模式中，Blink優化掉了大量的不必要的序列化和反序列化開銷。

此外，Blink提供了全新的JM FailOver機制，JM發生錯誤之後，新的JM會重新接管整個JOB而不是重啟JOB，從而大大減少了JM FailOver對JOB的影響。最後，Blink也開發了對Kubernetes的支援。不同於Standalone模式在Kubernetes上的拉起方式，在基於Flink FLIP6的架構上基礎之上，Blink根據job的資源需求動態的申請/釋放Pod來執行TaskExecutor，實現了資源彈性，提升了資源的利用率。

SQL/TableAPI

640?wx_fmt=png

SQL/TableAPI架構上的重構和效能的優化是Blink本次開源版本的一個重大貢獻。首先，我們對SQL engine的架構做了較大的調整。提出了全新的Query Processor（QP），它包括了一個優化層（Query Optimizer）和一個運算元層（Query Executor）。這樣一來，流計算和批計算的在這兩層大部分的設計工作就能做到儘可能的複用。

另外，SQL和TableAPI的程式最終執行的時候將不會翻譯到DataStream和DataSet這兩個API上，而是直接構建到可執行的DAG上來，這樣就使得物理執行運算元的設計不完全依賴底層的API，有了更大的靈活度，同時執行程式碼也能夠被靈活的codegen出來。唯一的一個影響就是這個版本的SQL和TableAPI不能和DataSet這個API進行互相轉換，但仍然保留了和DataStream API互相轉換的能力（將DataStream註冊成表，或將Table轉成DataStream後繼續操作）。未來，我們計劃把dataset的功能慢慢都在DataStream和TableAPI上面實現。到那時DataStream和SQL以及tableAPI一樣，是一個可以同時描述bounded以及unbounded processing的API。

除了架構上的重構，Blink還在具體實現上做了較多比較大的重構。首先，Blink引入了二進位制的資料結構BinaryRow，極大的減少了資料儲存上的開銷以及資料在序列化和反序列化上計算的開銷。其次，在運算元的實現層面，Blink在更廣範圍內引入了CodeGen技術。由於預先知道運算元需要處理的資料的型別，在QP層內部就可以直接生成更有針對性更高效的執行程式碼。

Blink的運算元會動態的申請和使用資源，能夠更好的利用資源，提升效率，更加重要的是這些運算元對資源有著比較好的控制，不會發生OutOfMemory 的問題。此外，針對流計算場景，Blink加入了miniBatch的執行模式，在aggregate、join等需要和state頻繁互動且往往又能先做部分reduce的場景中，使用miniBatch能夠極大的減少IO，從而成數量級的提升效能。除了上面提到的這些重要的重構和功能點，Blink還實現了完整的SQL DDL，帶emit策略的流計算DML，若干重要的SQL功能，以及大量的效能優化策略。

640?wx_fmt=png

有了上面提到的諸多架構和實現上的重構。Blink的SQL／tableAPI在功能和效能方面都取得了脫胎換骨的變化。在批計算方面，首先Blink batch SQL能夠完整的跑通TPC-H和TPC-DS，且效能上有著極大的提升。如上圖所示，是這次開源的Blink版本和spark 2.3.1的TPC-DS的benchmark效能對比。柱狀圖的高度代表了執行的總時間，高度越低說明效能越好。可以看出，Blink在TPC-DS上和Spark相比有著非常明顯的效能優勢。而且這種效能優勢隨著資料量的增加而變得越來越大。在實際的場景這種優勢已經超過 Spark的三倍。在流計算效能上我們也取得了類似的提升。我們線上的很多典型作業，它的效能是原來的3到5倍。在有資料傾斜的場景，以及若干比較有挑戰的TPC-H query，流計算效能甚至得到了數十倍的提升。

除了標準的Relational SQL API。TableAPI在功能上是SQL的超集，因此在SQL上所有新加的功能，我們在tableAPI也新增了相對應的API。除此之外，我們還在TableAPI上引入了一些新的功能。其中一個比較重要是cache功能。在批計算場景下，使用者可以根據需要來cache計算的中間結果，從而避免不必要的重複計算。它極大的增強了interactive programming體驗。我們後續會在tableAPI上新增更多有用的功能。其實很多新功能已經在社群展開討論並被社群接受，例如我們在tableAPI增加了對一整行操作的運算元map/flatMap/aggregate/flatAggregate(Flink FLIP29)等等。

Hive的相容性

我們這次開源的版本實現了在後設資料(meta data)和資料層將Flink和Hive對接和打通。國內外很多公司都還在用 Hive 在做自己的批處理。對於這些使用者，現在使用這次Blink開源的版本，就可以直接用Flink SQL去查詢Hive的資料，真正能夠做到在Hive引擎和Flink引擎之間的自由切換。

為了打通後設資料，我們重構了Flink catalog的實現，並且增加了兩種catalog，一個是基於記憶體儲存的FlinkInMemoryCatalog，另外一個是能夠橋接Hive metaStore的HiveCatalog。有了這個HiveCatalog，Flink作業就能讀取Hive的metaData。為了打通資料，我們實現了HiveTableSource，使得Flink job可以直接讀取Hive中普通表和分割槽表的資料。因此，通過這個版本，使用者可以使用Flink SQL讀取已有的Hive meta和data，做資料處理。未來我們將在Flink上繼續加大對Hive相容性的支援，包括支援Hive特有的query，data type，和Hive UDF等等。

Zeppelin for Flink

為了提供更好的視覺化和互動式體驗，我們做了大量的工作讓Zeppelin能夠更好的支援Flink。這些改動有些是在Flink上的，有些是在Zeppelin上的。在這些改動全部推回Flink和Zeppelin社群之前，大家可以使用這個Zeppelin image(具體細節請參考Blink程式碼裡的docs/quickstart/zeppelin_quickstart.md)來測試和使用這些功能。這個用於測試的Zeppelin版本，首先很好的融合和整合了Flink的多種執行模式以及運維介面。使用文字SQL和tableAPI可以自如的查詢Flink的static table和dynamic table。

此外，針對Flink的流計算的特點，這一版Zeppelin也很好的支援了savepoint，使用者可以在介面上暫停作業，然後再從savepoint恢復繼續執行作業。在資料展示方面，除了傳統的資料分析介面，我們也新增了流計算的翻牌器和時間序列展示等等功能。為了方便使用者試用，我們在這一版zeppelin中提供3個built-in的Flink tutorial的例子: 一個是做StreamingETL的例子, 另外兩個分別是做Flink Batch,Flink Stream的基礎樣例。

640?wx_fmt=png

Flink Web

我們對Flink Web的易用性與效能等多個方面做了大量的改進，從資源使用、作業調優、日誌查詢等維度新增了大量功能，使得使用者可以更方便的對Flink作業進行運維。在資源使用方面，新增了Cluster、TaskManager與Job三個級別的資源資訊，使得資源的申請與使用情況一目瞭然。作業的拓撲關係及資料流向可以追溯至 Operator 級別，Vertex 增加了InQueue，OutQueue等多項指標，可以方便的追蹤資料的反壓、過濾及傾斜情況。TaskManager 和 JobManager 的日誌功能得到大幅度加強，從Job、Vertex、SubTask 等多個維度都可以關聯至對應日誌，提供多日誌檔案訪問入口，以及分頁展示查詢和日誌高亮功能。

另外，我們使用了較新的Angular 7.0 對Flink web進行了全面重構，頁面執行效能有了一倍以上的提升。在大資料量情況下也不會發生頁面卡死或者卡頓情況。同時對頁面的互動邏輯進行了整體優化，絕大部分關聯資訊在單個頁面就可以完成查詢和比對工作，減少了大量不必要的跳轉。

640?wx_fmt=png

未來的規劃

Blink邁出了全面開源的第一步，接下來我們會和社群合作，儘可能以最快的方式將Blink的功能和效能上的優化merge回Flink。本次的開源版本一方面貢獻了Blink多年在流計算的積累，另一方面又重磅推出了在批處理上的成果。接下來，我們會持續給Flink社群貢獻其他方面的功能。我們期望每過幾個月就能看到技術上有一個比較大的亮點貢獻到社群。下一個亮點應該是對機器學習的支援。要把機器學習支援好，有一系列的工作要做，包括引擎的功能，效能，和易用性。這裡面大部分的工作我們已經開發完成，並且很多功能都已經在阿里巴巴內部服務上線了。

除了技術上創新以及新功能之外，Flink的易用性和外圍生態也非常重要。我們已經啟動了若干這方面的專案，包括Python以及Go等多語言支援，Flink叢集管理，Notebook，以及機器學習平臺等等。這些專案有些會成為Flink自身的一部分貢獻回社群，有些不是。但它們都基於Flink，是Flink生態的一個很好的補充。獨立於Flink之外的那些專案，我們都也在認真的考慮開源出來。總之，Blink在開源的第一天起，就已經完全all-in的融入了Flink社群，我們希望所有的開發者看到我們的誠意和決心。

未來，無論是功能還是生態，我們都會在Flink社群加大投入，我們也將投入力量做 Flink 社群的運營，讓 Flink 真正在中國、乃至全世界大規模地使用起來。我們衷心的希望更多的人加入，一起把Apache Flink開源社群做得更好！

暢聊Flink的那些事兒，抱走限量周邊！

你會將Flink應用在哪些實際場景中？接下來最期待加入什麼功能？

歡迎在留言區討論，我們將選出五位最有“料”的童鞋，送出 Flink定製版雙肩包！