作者:王峰
創(chuàng)新互聯(lián)服務(wù)項目包括桃源網(wǎng)站建設(shè)、桃源網(wǎng)站制作、桃源網(wǎng)頁制作以及桃源網(wǎng)絡(luò)營銷策劃等。多年來,我們專注于互聯(lián)網(wǎng)行業(yè),利用自身積累的技術(shù)優(yōu)勢、行業(yè)經(jīng)驗、深度合作伙伴關(guān)系等,向廣大中小型企業(yè)、政府機構(gòu)等提供互聯(lián)網(wǎng)行業(yè)的解決方案,桃源網(wǎng)站推廣取得了明顯的社會效益與經(jīng)濟效益。目前,我們服務(wù)的客戶以成都為中心已經(jīng)輻射到桃源省份的部分城市,未來相信會繼續(xù)擴大服務(wù)區(qū)域并繼續(xù)獲得客戶的支持與信任!整理:韓非
本文主要整理自云棲大會阿里巴巴計算平臺事業(yè)部資深技術(shù)專家王峰(花名:莫問)在云棲大會‘開發(fā)者生態(tài)峰會’上發(fā)表的演講。
伴隨著海量增長的數(shù)據(jù),數(shù)字化時代的未來感撲面而至。不論是結(jié)繩記事的小數(shù)據(jù)時代,還是我們正在經(jīng)歷的大數(shù)據(jù)時代,計算的邊界正在被無限拓寬,而數(shù)據(jù)的價值,再也難以被計算。時下,談及大數(shù)據(jù),不得不提到最熱門的下一代大數(shù)據(jù)計算引擎Apache Flink(以下簡稱Flink)。本文將結(jié)合Flink的前世今生,從業(yè)務(wù)角度出發(fā),向大家娓娓道來:為什么阿里選擇了Flink?
隨著人工智能時代的降臨,數(shù)據(jù)量的爆發(fā),在典型的大數(shù)據(jù)的業(yè)務(wù)場景下數(shù)據(jù)業(yè)務(wù)最通用的做法是:選用批處理的技術(shù)處理全量數(shù)據(jù),采用流式計算處理實時增量數(shù)據(jù)。在絕大多數(shù)的業(yè)務(wù)場景之下,用戶的業(yè)務(wù)邏輯在批處理和流處理之中往往是相同的。但是,用戶用于批處理和流處理的兩套計算引擎是不同的。因此,用戶通常需要寫兩套代碼。毫無疑問,這帶來了一些額外的負擔(dān)和成本。阿里巴巴的商品數(shù)據(jù)處理就經(jīng)常需要面對增量和全量兩套不同的業(yè)務(wù)流程問題,所以阿里就在想,我們能不能有一套統(tǒng)一的大數(shù)據(jù)引擎技術(shù),用戶只需要根據(jù)自己的業(yè)務(wù)邏輯開發(fā)一套代碼。這樣在各種不同的場景下,不管是全量數(shù)據(jù)還是增量數(shù)據(jù),亦或者實時處理,一套方案即可全部支持,這就是阿里選擇Flink的背景和初衷。
目前開源大數(shù)據(jù)計算引擎有很多選擇,流計算如Storm、Samza、Flink、Kafka Stream等,批處理如Spark、Hive、Pig、Flink等。而同時支持流處理和批處理的計算引擎,只有兩種選擇:一個是Apache Spark,一個是Apache Flink。
從技術(shù),生態(tài)等各方面的綜合考慮,首先,Spark的技術(shù)理念是基于批來模擬流的計算。而Flink則完全相反,它采用的是基于流計算來模擬批計算。
從技術(shù)發(fā)展方向看,用批來模擬流有一定的技術(shù)局限性,并且這個局限性可能很難突破。而Flink基于流來模擬批,在技術(shù)上有更好的擴展性。從長遠來看,阿里決定用Flink做一個統(tǒng)一的、通用的大數(shù)據(jù)引擎作為未來的選型。
Flink是一個低延遲、高吞吐、統(tǒng)一的大數(shù)據(jù)計算引擎。在阿里巴巴的生產(chǎn)環(huán)境中,F(xiàn)link的計算平臺可以實現(xiàn)毫秒級的延遲情況下,每秒鐘處理上億次的消息或者事件。同時Flink提供了一個Exactly-once的一致性語義。保證了數(shù)據(jù)的正確性。這樣就使得Flink大數(shù)據(jù)引擎可以提供金融級的數(shù)據(jù)處理能力。
基于Apache Flink在阿里巴巴搭建的平臺于2016年正式上線,并從阿里巴巴的搜索和推薦這兩大場景開始實現(xiàn)。目前阿里巴巴所有的業(yè)務(wù),包括阿里巴巴所有子公司都采用了基于Flink搭建的實時計算平臺。同時Flink計算平臺運行在開源的Hadoop集群之上。采用Hadoop的YARN做為資源管理調(diào)度,以 HDFS作為數(shù)據(jù)存儲。因此,F(xiàn)link可以和開源大數(shù)據(jù)軟件Hadoop無縫對接。
目前,這套基于Flink搭建的實時計算平臺不僅服務(wù)于阿里巴巴集團內(nèi)部,而且通過阿里云的云產(chǎn)品API向整個開發(fā)者生態(tài)提供基于Flink的云產(chǎn)品支持。
規(guī)模:一個系統(tǒng)是否成熟,規(guī)模是重要指標(biāo),F(xiàn)link最初上線阿里巴巴只有數(shù)百臺服務(wù)器,目前規(guī)模已達上萬臺,此等規(guī)模在全球范圍內(nèi)也是屈指可數(shù);
狀態(tài)數(shù)據(jù):基于Flink,內(nèi)部積累起來的狀態(tài)數(shù)據(jù)已經(jīng)是PB級別規(guī)模;
Events:如今每天在Flink的計算平臺上,處理的數(shù)據(jù)已經(jīng)超過萬億條;
接下來從開源技術(shù)的角度,來談一談Apache Flink是如何誕生的,它是如何成長的?以及在成長的這個關(guān)鍵的時間點阿里是如何進入的?并對它做出了那些貢獻和支持?
Flink誕生于歐洲的一個大數(shù)據(jù)研究項目StratoSphere。該項目是柏林工業(yè)大學(xué)的一個研究性項目。早期,F(xiàn)link是做Batch計算的,但是在2014年,StratoSphere里面的核心成員孵化出Flink,同年將Flink捐贈Apache,并在后來成為Apache的頂級大數(shù)據(jù)項目,同時Flink計算的主流方向被定位為Streaming,即用流式計算來做所有大數(shù)據(jù)的計算,這就是Flink技術(shù)誕生的背景。
2014年Flink作為主攻流計算的大數(shù)據(jù)引擎開始在開源大數(shù)據(jù)行業(yè)內(nèi)嶄露頭角。區(qū)別于Storm、Spark Streaming以及其他流式計算引擎的是:它不僅是一個高吞吐、低延遲的計算引擎,同時還提供很多高級的功能。比如它提供了有狀態(tài)的計算,支持狀態(tài)管理,支持強一致性的數(shù)據(jù)語義以及支持Event Time,WaterMark對消息亂序的處理。
Flink最區(qū)別于其他流計算引擎的,其實就是狀態(tài)管理。
什么是狀態(tài)?例如開發(fā)一套流計算的系統(tǒng)或者任務(wù)做數(shù)據(jù)處理,可能經(jīng)常要對數(shù)據(jù)進行統(tǒng)計,如Sum、Count、Min、Max,這些值是需要存儲的。因為要不斷更新,這些值或者變量就可以理解為一種狀態(tài)。如果數(shù)據(jù)源是在讀取Kafka、RocketMQ,可能要記錄讀取到什么位置,并記錄Offset,這些Offset變量都是要計算的狀態(tài)。
Flink提供了內(nèi)置的狀態(tài)管理,可以把這些狀態(tài)存儲在Flink內(nèi)部,而不需要把它存儲在外部系統(tǒng)。這樣做的好處是第一降低了計算引擎對外部系統(tǒng)的依賴以及部署,使運維更加簡單;第二,對性能帶來了極大的提升:如果通過外部去訪問,如Redis,HBase,它一定是通過網(wǎng)絡(luò)及RPC。如果通過Flink內(nèi)部去訪問,它只通過自身的進程去訪問這些變量。同時Flink會定期將這些狀態(tài)做Checkpoint持久化,把Checkpoint存儲到一個分布式的持久化系統(tǒng)中,比如HDFS。這樣的話,當(dāng)Flink的任務(wù)出現(xiàn)任何故障時,它都會從最近的一次Checkpoint將整個流的狀態(tài)進行恢復(fù),然后繼續(xù)運行它的流處理。對用戶沒有任何數(shù)據(jù)上的影響。
Flink是如何做到在Checkpoint恢復(fù)過程中沒有任何數(shù)據(jù)的丟失和數(shù)據(jù)的冗余?來保證精準(zhǔn)計算的?
這其中原因是Flink利用了一套非常經(jīng)典的Chandy-Lamport算法,它的核心思想是把這個流計算看成一個流式的拓撲,定期從這個拓撲的頭部Source點開始插入特殊的Barriers,從上游開始不斷的向下游廣播這個Barriers。每一個節(jié)點收到所有的Barriers,會將State做一次Snapshot,當(dāng)每個節(jié)點都做完Snapshot之后,整個拓撲就算完整的做完了一次Checkpoint。接下來不管出現(xiàn)任何故障,都會從最近的Checkpoint進行恢復(fù)。
Flink利用這套經(jīng)典的算法,保證了強一致性的語義。這也是Flink與其他無狀態(tài)流計算引擎的核心區(qū)別。
下面介紹Flink是如何解決亂序問題的。比如星球大戰(zhàn)的播放順序,如果按照上映的時間觀看,可能會發(fā)現(xiàn)故事在跳躍。
在流計算中,與這個例子是非常類似的。所有消息到來的時間,和它真正發(fā)生在源頭,在線系統(tǒng)Log當(dāng)中的時間是不一致的。在流處理當(dāng)中,希望是按消息真正發(fā)生在源頭的順序進行處理,不希望是真正到達程序里的時間來處理。Flink提供了Event Time和WaterMark的一些先進技術(shù)來解決亂序的問題。使得用戶可以有序的處理這個消息。這是Flink一個很重要的特點。
接下來要介紹的是Flink啟動時的核心理念和核心概念,這是Flink發(fā)展的第一個階段;第二個階段時間是2015年和2017年,這個階段也是Flink發(fā)展以及阿里巴巴介入的時間。故事源于2015年年中,我們在搜索事業(yè)部的一次調(diào)研。當(dāng)時阿里有自己的批處理技術(shù)和流計算技術(shù),有自研的,也有開源的。但是,為了思考下一代大數(shù)據(jù)引擎的方向以及未來趨勢,我們做了很多新技術(shù)的調(diào)研。
結(jié)合大量調(diào)研結(jié)果,我們最后得出的結(jié)論是:解決通用大數(shù)據(jù)計算需求,批流融合的計算引擎,才是大數(shù)據(jù)技術(shù)的發(fā)展方向,并且最終我們選擇了Flink。
但2015年的Flink還不夠成熟,不管是規(guī)模還是穩(wěn)定性尚未經(jīng)歷實踐。最后我們決定在阿里內(nèi)部建立一個Flink分支,對Flink做大量的修改和完善,讓其適應(yīng)阿里巴巴這種超大規(guī)模的業(yè)務(wù)場景。在這個過程當(dāng)中,我們團隊不僅對Flink在性能和穩(wěn)定性上做出了很多改進和優(yōu)化,同時在核心架構(gòu)和功能上也進行了大量創(chuàng)新和改進,并將其貢獻給社區(qū),例如:Flink新的分布式架構(gòu),增量Checkpoint機制,基于Credit-based的網(wǎng)絡(luò)流控機制和Streaming SQL等。
我們舉兩個設(shè)計案例,第一個是阿里巴巴重構(gòu)了Flink的分布式架構(gòu),將Flink的Job調(diào)度和資源管理做了一個清晰的分層和解耦。這樣做的首要好處是Flink可以原生的跑在各種不同的開源資源管理器上。經(jīng)過這套分布式架構(gòu)的改進,F(xiàn)link可以原生地跑在Hadoop Yarn和Kubernetes這兩個最常見的資源管理系統(tǒng)之上。同時將Flink的任務(wù)調(diào)度從集中式調(diào)度改為了分布式調(diào)度,這樣Flink就可以支持更大規(guī)模的集群,以及得到更好的資源隔離。
另一個是實現(xiàn)了增量的Checkpoint機制,因為Flink提供了有狀態(tài)的計算和定期的Checkpoint機制,如果內(nèi)部的數(shù)據(jù)越來越多,不停地做Checkpoint, Checkpoint會越來越大,最后可能導(dǎo)致做不出來。提供了增量的Checkpoint后,F(xiàn)link會自動地發(fā)現(xiàn)哪些數(shù)據(jù)是增量變化,哪些數(shù)據(jù)是被修改了。同時只將這些修改的數(shù)據(jù)進行持久化。這樣Checkpoint不會隨著時間的運行而越來越難做,整個系統(tǒng)的性能會非常地平穩(wěn),這也是我們貢獻給社區(qū)的一個很重大的特性。
經(jīng)過2015年到2017年對Flink Streaming的能力完善,F(xiàn)link社區(qū)也逐漸成熟起來。Flink也成為在Streaming領(lǐng)域最主流的計算引擎。因為Flink最早期想做一個流批統(tǒng)一的大數(shù)據(jù)引擎,2018年已經(jīng)啟動這項工作,為了實現(xiàn)這個目標(biāo),阿里巴巴提出了新的統(tǒng)一API架構(gòu),統(tǒng)一SQL解決方案,同時流計算的各種功能得到完善后,我們認為批計算也需要各種各樣的完善。無論在任務(wù)調(diào)度層,還是在數(shù)據(jù)Shuffle層,在容錯性,易用性上,都需要完善很多工作。
篇幅原因,下面主要和大家分享兩點:
統(tǒng)一 API Stack
先來看下目前Flink API Stack的一個現(xiàn)狀,調(diào)研過Flink或者使用過Flink的開發(fā)者應(yīng)該知道。Flink有2套基礎(chǔ)的API,一套是DataStream,一套是DataSet。DataStream API是針對流式處理的用戶提供,DataSet API是針對批處理用戶提供,但是這兩套API的執(zhí)行路徑是完全不一樣的,甚至需要生成不同的Task去執(zhí)行。所以這跟得到統(tǒng)一的API是有沖突的,而且這個也是不完善的,不是最終的解法。在Runtime之上首先是要有一個批流統(tǒng)一融合的基礎(chǔ)API層,我們希望可以統(tǒng)一API層。
因此,我們在新架構(gòu)中將采用一個DAG(有限無環(huán)圖)API,作為一個批流統(tǒng)一的API層。對于這個有限無環(huán)圖,批計算和流計算不需要涇渭分明的表達出來。只需要讓開發(fā)者在不同的節(jié)點,不同的邊上定義不同的屬性,來規(guī)劃數(shù)據(jù)是流屬性還是批屬性。整個拓撲是可以融合批流統(tǒng)一的語義表達,整個計算無需區(qū)分是流計算還是批計算,只需要表達自己的需求。有了這套API后,F(xiàn)link的API Stack將得到統(tǒng)一。
除了統(tǒng)一的基礎(chǔ)API層和統(tǒng)一的API Stack外,同樣在上層統(tǒng)一SQL的解決方案。流和批的SQL,可以認為流計算有數(shù)據(jù)源,批計算也有數(shù)據(jù)源,我們可以將這兩種源都模擬成數(shù)據(jù)表??梢哉J為流數(shù)據(jù)的數(shù)據(jù)源是一張不斷更新的數(shù)據(jù)表,對于批處理的數(shù)據(jù)源可以認為是一張相對靜止的表,沒有更新的數(shù)據(jù)表。整個數(shù)據(jù)處理可以當(dāng)做SQL的一個Query,最終產(chǎn)生的結(jié)果也可以模擬成一個結(jié)果表。
對于流計算而言,它的結(jié)果表是一張不斷更新的結(jié)果表。對于批處理而言,它的結(jié)果表是相當(dāng)于一次更新完成的結(jié)果表。從整個SQL語義上表達,流和批是可以統(tǒng)一的。此外,不管是流式SQL,還是批處理SQL,都可以用同一個Query來表達復(fù)用。這樣以來流批都可以用同一個Query優(yōu)化或者解析。甚至很多流和批的算子都是可以復(fù)用的。
首先,阿里巴巴還是要立足于Flink的本質(zhì),去做一個全能的統(tǒng)一大數(shù)據(jù)計算引擎。將它在生態(tài)和場景上進行落地。目前Flink已經(jīng)是一個主流的流計算引擎,很多互聯(lián)網(wǎng)公司已經(jīng)達成了共識:Flink是大數(shù)據(jù)的未來,是最好的流計算引擎。下一步很重要的工作是讓Flink在批計算上有所突破。在更多的場景下落地,成為一種主流的批計算引擎。然后進一步在流和批之間進行無縫的切換,流和批的界限越來越模糊。用Flink,在一個計算中,既可以有流計算,又可以有批計算。
第二個方向就是Flink的生態(tài)上有更多語言的支持,不僅僅是Java,Scala語言,甚至是機器學(xué)習(xí)下用的Python,Go語言。未來我們希望能用更多豐富的語言來開發(fā)Flink計算的任務(wù),來描述計算邏輯,并和更多的生態(tài)進行對接。
最后不得不說AI,因為現(xiàn)在很多大數(shù)據(jù)計算的需求和數(shù)據(jù)量都是在支持很火爆的AI場景,所以在Flink流批生態(tài)完善的基礎(chǔ)上,將繼續(xù)往上走,完善上層Flink的Machine Learning算法庫,同時Flink往上層也會向成熟的機器學(xué)習(xí),深度學(xué)習(xí)去集成。比如可以做Tensorflow On Flink, 讓大數(shù)據(jù)的ETL數(shù)據(jù)處理和機器學(xué)習(xí)的Feature計算和特征計算,訓(xùn)練的計算等進行集成,讓開發(fā)者能夠同時享受到多種生態(tài)給大家?guī)淼暮锰帯?/p>
更多資訊請訪問 Apache Flink 中文社區(qū)網(wǎng)站
另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)scvps.cn,海內(nèi)外云服務(wù)器15元起步,三天無理由+7*72小時售后在線,公司持有idc許可證,提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國服務(wù)器、虛擬主機、免備案服務(wù)器”等云主機租用服務(wù)以及企業(yè)上云的綜合解決方案,具有“安全穩(wěn)定、簡單易用、服務(wù)可用性高、性價比高”等特點與優(yōu)勢,專為企業(yè)上云打造定制,能夠滿足用戶豐富、多元化的應(yīng)用場景需求。
文章名稱:阿里巴巴為什么選擇ApacheFlink?-創(chuàng)新互聯(lián)
本文來源:http://www.rwnh.cn/article22/ceeojc.html
成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供域名注冊、響應(yīng)式網(wǎng)站、營銷型網(wǎng)站建設(shè)、動態(tài)網(wǎng)站、電子商務(wù)、網(wǎng)站排名
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請盡快告知,我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場,如需處理請聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時需注明來源: 創(chuàng)新互聯(lián)
猜你還喜歡下面的內(nèi)容