Flink大數據計算的機遇與挑戰

做者: 王紹翾（大沙）

本文來自於王紹翾在2018年08月11日Flink China Meetup。
王紹翾，花名「大沙」，加州大學聖迭戈分校計算機工程的博士，Apache Flink Commiter。目前在阿里負責Flink平臺以及生態的一些工做。

本文內容以下：

流計算核心技術

Flink是德國data Artisans創造的，早期Flink主要是作偏批計算的，可是Spark在批處理上已經有必定優點，正面競爭沒什麼意義，因而改變方向，基於chandy-lamport算法開始作流計算，完成後完美的解決了低延遲問題和狀態管理。

低延遲，快速容錯

低延遲是Flink源生的，固然保證了快速容錯。大數據計算中job老是會失敗，因此須要可以快速的恢復。若是平時延遲很低，可是job一失敗，恢復幾分鐘，確定是沒法接受的。

通用的API，易用性

Flink有了基礎的能力後，開始考慮通用的API，最開始的時候有了一些Java和Scala的一些API。可是發展到必定程度以後，由於API不僅是開放於開發，而是全部用戶。怎麼樣更容易的知足用戶的需求和支持用戶，這是流計算的很核心的一點。

彈性，高性能

彈性，高性能是大數據不變的主題。怎麼樣確保引擎在上千臺機器不出問題的運行，scalability很重要，包括Spark早期到必定規模遇到不少問題，固然Blink已經完美的解決了全部問題。在性能上，Flink不只是在流計算仍是批處理上已經有了絕對的優點。

流和批的統一

Flink的早期interface是很是弱的，包括Spark早期也是，因而流計算的社區開始討論流計算的SQL究竟是什麼樣子的，因而造成了兩派風格，一派是認爲Streaming SQL是一種different SQL跟Batch Sql，另外一派推的SQL跟Batch SQL是徹底一致的。

爲何會說徹底一致？流計算跟批計算一個基本的區別是，都是計算，可是流計算須要提早看到結果，這須要將結果提早發出，可是後面過來的數據會對前面的結果進行修正，因此流計算跟批計算比較大的區別就是數據提早發出和數據修正，最終保證數據正確。

怎麼來處理這個問題:

• 首先要告訴用戶API，怎麼樣去計算徹底是用戶的語義
• 另外兩點就是何時發出去，何時修正，這些跟SQL自己描述是沒什麼關係的
• 因此傳統的ANSI SQL是徹底能夠描述流計算的，Flink SQL的語義就是ANSI SQL

用戶要什麼?

• 高性能
• 高級分析
• 容易開發
• 開箱即用
• 低延遲

咱們說的是大數據，而不只僅是流計算。對於功能型的用戶，更關心的是易用性，如何作好分析，如何更好的開發，如何更容易上手。我沒學過計算機，可是學的是其餘任何的一個行業多是統計，生物，建築，金融……，怎麼樣才能更快的開發出來。

假如老闆說，今天要部署Flink了，因而給了你50臺機器，到了次日，你部署完畢了，做業跑起來了，老闆嚇呆了，以爲你KPI很是的棒。因此開箱即用，更容易的去開發對用戶來講很是須要的。

傳統的批計算要追求performance，目前流計算對performance需求愈來愈大。

一.Flink的現狀和將來

知道了用戶想要的，咱們看Flink現狀。

Flink目前被普遍的用於超低延遲流計算場景中，可是Flink在批處理上其實已經有很是高的處理性能，而且在API上流和批是統一的，在性能上和易用性上都有不錯的表現。

帶着已知的事情和一點點未知的事情，來看看Flink能作的一些事情:流計算已經很是成熟，批計算，AI的計算，包括TF ON Flink，training也好，prediction也好，任何計算。另外還有很大的一塊IOT，Hadoop Summit 中強調各類數據中，流的也好，批的也好，最終IOT的數據最大。雖然不是每一個公司都會接觸IOT，但它絕對是一個很大的future。

1.阿里巴巴的Blink

Blink1.0其實是enterprise版的Flink，主要專一與流計算上。

Blink2.0是一個統一的引擎，支持流處理和批處理，在其餘方面，例如AI方面作了很大的改進，在batch性能上已經遠超Spark。回饋社區也是這個版本。

2.Flink SQL Engine的架構

咱們先看一眼Flink SQL Engine，從上面開始有Query的API，有Query Optimization，下來會翻譯到DataSteam或者DataSet算子，而後Runtime，在各個集羣上運行。這個架構在裏面展開DataSteam和DataSet，能夠看到幾個比較大的問題：

1. 在設計上，歷來沒想過統一塊兒來。最終Query Optimization翻譯完以後到DataStream或者DataSet是徹底兩條獨立的pipline，並且往下的代碼是全完不復用的
2. 再一個能夠看批計算，DataSet下面還有一個Optimized Plan，這兩層優化給統一帶來很大的困難

3.Blink SQL Engine的架構

咱們把整個的SQL Engine換成上圖所示。從上層開始的API，到下面的Query Processor包括了Query Optimizer和Query Executor，當作完這些發現，代碼大量的減小並被複用，一個job用一樣的SQL只須要標識是Batch Mode仍是Stream Mode，就會獲得同樣的結果。

從API開始，翻譯成Logical Plan通過Optimizer，再到相似寫DataStream的這種Physical Plan，咱們能夠看到在Optimizer以前的批跟流徹底同樣，SQL同樣，Logical Plan也同樣。即用戶腦子裏想的東西，在批和流中如出一轍。

二.優化流計算的挑戰和機遇

在Optimizer以後，流和批有些不同。

批和流在同樣的地方就是一些簡單的filter，predicate，projection還有joining reorder。

區別就是在流計算咱們不去支持sort，由於每條數據一來，就要對以前的數據更新，就比如我讓在座的各位稱個體重，排個序，忽然在座的哪位去上個廁所，體重變了，會影響不少人的排序，就須要改變大量的結果。因此在流上不去考慮相似sort的東西。可是流上由於有state的使用，怎麼樣把它的性能變得很高，減小Retraction，怎麼樣讓用戶的SLA用MicroBatch去優化。

流計算上一旦變成SQL，就得跑標準的SQL測試，TPC-H，TPC-DS。咱們看這個TPCH13，這個是測試的是用一張Customer表和一張Order表，須要作一次join和count。

這個計算在批計算上處理很方便，由於兩個表就在那兒，它明顯的知道用戶表很小，它會把用戶表hash到各個地方先cache下來，而後讓訂單表流過去，這個性能很是高，由於Order這張最大的表只是不停的流而不落地。

在流計算上怎麼處理呢？由於根本不知道數據長什麼樣子，每邊一來就得存下來，左邊的Customer表來了以後存下來，由於一行只需存一個，因此用的是ValueState，可是每一個用戶有不少的Order，右邊的Order表則須要使用MapState，這個計算量很是大，性能很是差。怎麼優化呢，咱們使用的SQL就有一個自然的好處Optimizer。SQL Engine有個rule就是轉移了上面的countAgg和下面的join，SQL裏面有個代數優化，先不考慮數據是什麼樣子，我從代數上認爲中間這幅圖和最右邊這幅圖的計算結果是一致的，因此我能夠先對兩邊進行agg，我能夠在Order那一邊先把每一個用戶count完變成一行只有一個數據，預先處理好數據，這樣把Order表壓縮成和customer同樣大小的表，join上的開銷省了不少，state從龐大的MapState變成了輕量的ValueState，性能提高了25倍，這也是爲何SQL是有意義的。

對於一些流計算的特有優化，好比知道用戶的SLA，有段時間就能夠去配置mini-batch 。

作全網的count，那麼用以上左圖的紅色和紫色，分別發送到一個地方去統計，不作預處理的話，紅色節點負載太高，很快就致使反壓。最好的辦法就是紅色和紫色的節點如今上游chain起來作預處理，至關於把一個聚合分紅兩部分，先作count，再作sum。

固然上面的方案不老是有效，好比count distinct，它也須要按顏色group by還要按某一列去distinct，致使不一樣的數據沒法被預聚合。因此在local-global上除了chain的方式還有shuffle的方式，至關於shuffle兩次，也就是你們在流計算中所說的打散。第一次按distinct key去shuffle，第二次用group by的key去作shuffle。固然這些都是SQL Engine都會自動幫你作。

三.融入開源社區，參與開源開發

開源社區除了coding的貢獻外，還有文檔，生態，社區，產品，只要對這個開源的產品有幫助。更重要的是你在社區裏面的活躍度，爲社區解決什麼問題。

做爲一個用戶你能夠提出一些問題，去mailing list回答問題，去作testing和report等等

做爲一個開發你能夠去review code，包括本身的idea，大的重構。還能夠幫助其餘用戶回答問題。

Mailing lists：

dev@flink.apache.org 開發者提問交流。

user@flink.apache.org 用戶提問交流。

JIRA: https://issues.apache.org/jir...

是社區的工做方式。Bug，feature，improvements提出的地方，每個code的貢獻都會關聯到一個JIRA issue。

Wiki: https://cwiki.apache.org/conf...

有許多文檔，包括大量FLIP，固然也等着你們contribution。

那如何要參與開發呢？

1. 你要在社區提出本身的想法，收集一些建議。
2. 你還要了PMC，commiter對分別對哪部分code負責，你能夠聯繫他，讓他幫你review。
3. 能夠依靠JIRA處理一些小的問題，可是比較重大的改進仍是須要依靠FLIP。
4. 完成以後，就須要去貢獻代碼，固然要保證代碼的質量，加入不少test case，當你pull request時，會有不少人review你的代碼，沒有問題後就會merge上去。

更多資訊請訪問 Apache Flink 中文社區網站