91超碰碰碰碰久久久久久综合_超碰av人澡人澡人澡人澡人掠_国产黄大片在线观看画质优化_txt小说免费全本

溫馨提示×

溫馨提示×

您好,登錄后才能下訂單哦!

密碼登錄×
登錄注冊×
其他方式登錄
點擊 登錄注冊 即表示同意《億速云用戶服務條款》

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

發布時間:2020-07-20 02:57:48 來源:網絡 閱讀:372 作者:Ververica 欄目:大數據

作者: 王紹翾(大沙)

本文來自于王紹翾在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大數據計算的機遇與挑戰cdn.xitu.io/2019/4/25/16a539a2cf310379?w=1055&h=563&f=jpeg&s=123260">

我們說的是大數據,而不僅僅是流計算。對于功能型的用戶,更關心的是易用性,如何做好分析,如何更好的開發,如何更容易上手。我沒學過計算機,但是學的是其他任何的一個行業可能是統計,生物,建筑,金融……,怎么樣才能更快的開發出來。

假如老板說,今天要部署Flink了,于是給了你50臺機器,到了第二天,你部署完畢了,作業跑起來了,老板嚇呆了,覺得你KPI非常的棒。所以開箱即用,更容易的去開發對用戶來說非常需要的。

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

一.Flink的現狀和未來

知道了用戶想要的,我們看Flink現狀。

Flink目前被廣泛的用于超低延遲流計算場景中,但是Flink在批處理上其實已經有非常高的處理性能,并且在API上流和批是統一的,在性能上和易用性上都有不錯的表現。

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

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

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,這兩層優化給統一帶來很大的困難

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

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也一樣。即用戶腦子里想的東西,在批和流中一模一樣。

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

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

在Optimizer之后,流和批有些不一樣。

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

區別就是在流計算我們不去支持sort,因為每條數據一來,就要對之前的數據更新,就好比我讓在座的各位稱個體重,排個序,突然在座的哪位去上個廁所,體重變了,會影響很多人的排序,就需要改變大量的結果。所以在流上不去考慮類似sort的東西。但是流上因為有state的使用,怎么樣把它的性能變得很高,減少Retraction,怎么樣讓用戶的SLA用MicroBatch去優化。

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

流計算上一旦變成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。

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

當然上面的方案不總是有效,比如count distinct,它也需要按顏色group by還要按某一列去distinct,導致不同的數據無法被預聚合。所以在local-global上除了chain的方式還有shuffle的方式,相當于shuffle兩次,也就是大家在流計算中所說的打散。第一次按distinct key去shuffle,第二次用group by的key去做shuffle。當然這些都是SQL Engine都會自動幫你做。

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

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

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

作為一個用戶你可以提出一些問題,去mailing list回答問題,去做testing和report等等

作為一個開發你可以去review code,包括自己的idea,大的重構。還可以幫助其他用戶回答問題。

Mailing lists:

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

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

JIRA: https://issues.apache.org/jira/browse/FLINK

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

Wiki: https://cwiki.apache.org/confluence/display/FLINK

有許多文檔,包括大量FLIP,當然也等著大家contribution。

那如何要參與開發呢?

  1. 你要在社區提出自己的想法,收集一些建議。

  2. 你還要了PMC,commiter對分別對哪部分code負責,你可以聯系他,讓他幫你review。

  3. 可以依靠JIRA處理一些小的問題,但是比較重大的改進還是需要依靠FLIP。

  4. 完成之后,就需要去貢獻代碼,當然要保證代碼的質量,加入很多test case,當你pull request時,會有很多人review你的代碼,沒有問題后就會merge上去。

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

向AI問一下細節

免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。

AI

鹰潭市| 沭阳县| 金坛市| 阿图什市| 上杭县| 陵水| 凤山县| 确山县| 孟津县| 纳雍县| 广昌县| 彰化市| 神池县| 渝北区| 博野县| 大安市| 额敏县| 高雄市| 富阳市| 射洪县| 宣威市| 江北区| 汨罗市| 招远市| 沂水县| 徐汇区| 阿拉善左旗| 朔州市| 葵青区| 陕西省| 永平县| 洞口县| 海伦市| 白沙| 竹溪县| 诸暨市| 会理县| 柏乡县| 那曲县| 开鲁县| 临澧县|