摘要:阿里妹導(dǎo)讀如同我們?nèi)ツ暝略诜鍟?huì)所約,阿里巴巴內(nèi)部版本將于年月底正式開源。基于的計(jì)算平臺于年正式上線。截至目前,阿里絕大多數(shù)的技術(shù)部門都在使用。在那之后,阿里巴巴將直接使用用于生產(chǎn),并同時(shí)協(xié)助社區(qū)一起來維護(hù)。
阿里妹導(dǎo)讀:如同我們?nèi)ツ?2月在 Flink Forward China 峰會(huì)所約,阿里巴巴內(nèi)部 Flink 版本 Blink 將于 2019 年 1 月底正式開源。今天,我們終于等到了這一刻。
阿里資深技術(shù)專家大沙,將為大家詳細(xì)介紹本次開源的Blink主要功能和優(yōu)化點(diǎn),希望與業(yè)界同仁共同攜手,推動(dòng)Flink社區(qū)進(jìn)一步發(fā)展。
Blink簡介Apache Flink是德國柏林工業(yè)大學(xué)的幾個(gè)博士生和研究生從學(xué)校開始做起來的項(xiàng)目,早期叫做Stratosphere。2014年,StratoSphere項(xiàng)目中的核心成員從學(xué)校出來開發(fā)了Flink,同時(shí)將Flink計(jì)算的主流方向定位為流計(jì)算,并在同年將Flink捐贈(zèng)Apache,后來快速孵化成為Apache的頂級項(xiàng)目。現(xiàn)在Flink是業(yè)界公認(rèn)的最好的大數(shù)據(jù)流計(jì)算引擎。
阿里巴巴在2015年開始嘗試使用Flink。但是阿里的業(yè)務(wù)體量非常龐大,挑戰(zhàn)也很多。彼時(shí)的Flink不管是規(guī)模還是穩(wěn)定性尚未經(jīng)歷實(shí)踐,成熟度有待商榷。為了把這么大的業(yè)務(wù)體量支持好,我們不得不在Flink之上做了一系列的改進(jìn),所以阿里巴巴維護(hù)了一個(gè)內(nèi)部版本的Flink,它的名字叫做Blink。
基于Blink的計(jì)算平臺于2016年正式上線。截至目前,阿里絕大多數(shù)的技術(shù)部門都在使用Blink。Blink一直在阿里內(nèi)部錯(cuò)綜復(fù)雜的業(yè)務(wù)場景中鍛煉成長著。對于內(nèi)部用戶反饋的各種性能、資源使用率、易用性等諸多方面的問題,Blink都做了針對性的改進(jìn)。雖然現(xiàn)在Blink在阿里內(nèi)部用的最多的場景主要還是在流計(jì)算,但是在批計(jì)算場景也有不少業(yè)務(wù)上線使用了。例如,在搜索和推薦的算法業(yè)務(wù)平臺中,它使用Blink同時(shí)進(jìn)行流計(jì)算和批處理。Blink被用來實(shí)現(xiàn)了流批一體化的樣本生成和特征抽取這些流程,能夠處理的特征數(shù)達(dá)到了數(shù)千億,而且每秒鐘處理數(shù)億條消息。在這個(gè)場景的批處理中,我們單個(gè)作業(yè)處理的數(shù)據(jù)量已經(jīng)超過400T,并且為了節(jié)省資源,我們的批處理作業(yè)是和流計(jì)算作業(yè)以及搜索的在線引擎運(yùn)行在同樣的機(jī)器上。所以大家可以看到流批一體化已經(jīng)在阿里巴巴取得了極大的成功,我們希望這種成功和阿里巴巴內(nèi)部的經(jīng)驗(yàn)都能夠帶回給社區(qū)。
Blink開源的背景其實(shí)從我們選擇Flink的第一天開始我們就一直和社區(qū)緊密合作。過去的這幾年我們也一直在把阿里對Flink 的改進(jìn)推回社區(qū)。從2016年開始我們已經(jīng)將流計(jì)算SQL的大部分功能,針對runtime的穩(wěn)定性和性能優(yōu)化做的若干重要設(shè)計(jì)都推回了社區(qū)。但是Blink本身發(fā)展迭代的速度非常快,而社區(qū)有自己的步伐,很多時(shí)候可能無法把我們的變更及時(shí)推回去。對于社區(qū)來說,一些大的功能和重構(gòu),需要達(dá)成共識后,才能被接受,這樣才能更好地保證開源項(xiàng)目的質(zhì)量,但是同時(shí)就會(huì)導(dǎo)致推入的速度變得相對較慢。經(jīng)過這幾年的開發(fā)迭代,我們這邊和社區(qū)之間的差距已經(jīng)變得比較大了。
Blink 有一些很好的新功能,比如性能優(yōu)越的批處理功能,在社區(qū)的版本是沒有的。在過去這段時(shí)間里,我們不斷聽到有人在詢問Blink的各種新功能。期望Blink盡快開源的呼聲越來越大。我們一直在思考如何開源的問題,一種方案就是和以前一樣,繼續(xù)把各種功能和優(yōu)化分解,逐個(gè)和社區(qū)討論,慢慢地推回Flink。但這顯然不是大家所期待的。另一個(gè)方案,就是先完整的盡可能的多的把代碼開源,讓社區(qū)的開發(fā)者能夠盡快試用起來。第二個(gè)方案很快收到社區(qū)廣大用戶的支持。因此,從2018年年中開始我們就開始做開源的相關(guān)準(zhǔn)備。經(jīng)過半年的努力,我們終于把大部分Blink的功能梳理好,開源了出來。
Blink開源的方式我們把代碼貢獻(xiàn)出來,是為了讓大家能先嘗試一些他們感興趣的功能。Blink永遠(yuǎn)不會(huì)多帶帶成為一個(gè)獨(dú)立的開源項(xiàng)目來運(yùn)作,他一定是Flink的一部分。開源后我們期望能找到辦法以最快的方式將Blink merge到Flink中去。Blink開源只有一個(gè)目的,就是希望 Flink 做得更好。Apache Flink 是一個(gè)社區(qū)項(xiàng)目,Blink以什么樣的形式進(jìn)入 Flink 是最合適的,怎么貢獻(xiàn)是社區(qū)最希望的方式,我們都要和社區(qū)一起討論。
在過去的一段時(shí)間內(nèi),我們在Flink社區(qū)征求了廣泛的意見,大家一致認(rèn)為將本次開源的Blink代碼作為Flink的一個(gè)branch直接推回到Apache Flink項(xiàng)目中是最合適的方式。并且我們和社區(qū)也一起討論規(guī)劃出一套能夠快速merge Blink到Flink master中的方案(具體細(xì)節(jié)可以查看Flink社區(qū)正在討論的FLIP32)。我們期望這個(gè)merge能夠在很短的時(shí)間內(nèi)完成。這樣我們之后的Machine Learning等其他新功能就可以直接推回到Flink master。相信用不了多久,F(xiàn)link 和 Blink 就完全合二為一了。在那之后,阿里巴巴將直接使用Flink用于生產(chǎn),并同時(shí)協(xié)助社區(qū)一起來維護(hù)Flink。
本次開源的Blink的主要功能和優(yōu)化點(diǎn)本次開源的Blink代碼在Flink 1.5.1版本之上,加入了大量的新功能,以及在性能和穩(wěn)定性上的各種優(yōu)化。主要貢獻(xiàn)包括,阿里巴巴在流計(jì)算上積累的一些新功能和性能的優(yōu)化,一套完整的(能夠跑通全部TPC-H/TPC-DS,能夠讀取Hive meta和data)高性能Batch SQL,以及一些以提升易用性為主的功能(包括支持更高效的interactive programming, 與zeppelin更緊密的結(jié)合, 以及體驗(yàn)和性能更佳的Flink web)。未來我們還將繼續(xù)給Flink貢獻(xiàn)在AI,IoT以及其他新領(lǐng)域的功能和優(yōu)化。更多的關(guān)于這一版本Blink release的細(xì)節(jié),請參考Blink代碼根目錄下的README.md文檔。下面,我來分模塊介紹下Blink主要的新的功能和優(yōu)化點(diǎn)。
Runtime為了更好的支持batch processing,以及解決阿里巴巴大規(guī)模生產(chǎn)場景中遇到的各種挑戰(zhàn),Blink對Runtime架構(gòu)、效率、穩(wěn)定性方面都做了大量改進(jìn)。在架構(gòu)方面,首先Blink引入了Pluggable ShuffleArchitecture,開發(fā)者可以根據(jù)不同的計(jì)算模型或者新硬件的需要實(shí)現(xiàn)不同的shuffle策略進(jìn)行適配。此外Blink還引入新的調(diào)度架構(gòu),容許開發(fā)者根據(jù)計(jì)算模型自身的特點(diǎn)定制不同調(diào)度器。為了優(yōu)化性能,Blink可以讓算子更加靈活的chain在一起,避免了不必要的數(shù)據(jù)傳輸開銷。在Pipeline Shuffle模式中,使用了ZeroCopy減少了網(wǎng)絡(luò)層內(nèi)存消耗。在BroadCast Shuffle模式中,Blink優(yōu)化掉了大量的不必要的序列化和反序列化開銷。
此外,Blink提供了全新的JM FailOver機(jī)制,JM發(fā)生錯(cuò)誤之后,新的JM會(huì)重新接管整個(gè)JOB而不是重啟JOB,從而大大減少了JM FailOver對JOB的影響。最后,Blink也開發(fā)了對Kubernetes的支持。不同于Standalone模式在Kubernetes上的拉起方式,在基于Flink FLIP6的架構(gòu)上基礎(chǔ)之上,Blink根據(jù)job的資源需求動(dòng)態(tài)的申請/釋放Pod來運(yùn)行TaskExecutor,實(shí)現(xiàn)了資源彈性,提升了資源的利用率。
SQL/TableAPISQL/TableAPI架構(gòu)上的重構(gòu)和性能的優(yōu)化是Blink本次開源版本的一個(gè)重大貢獻(xiàn)。首先,我們對SQL engine的架構(gòu)做了較大的調(diào)整。提出了全新的Query Processor(QP), 它包括了一個(gè)優(yōu)化層(Query Optimizer)和一個(gè)算子層(Query Executor)。這樣一來,流計(jì)算和批計(jì)算的在這兩層大部分的設(shè)計(jì)工作就能做到盡可能的復(fù)用。
另外,SQL和TableAPI的程序最終執(zhí)行的時(shí)候?qū)⒉粫?huì)翻譯到DataStream和DataSet這兩個(gè)API上,而是直接構(gòu)建到可運(yùn)行的DAG上來,這樣就使得物理執(zhí)行算子的設(shè)計(jì)不完全依賴底層的API,有了更大的靈活度,同時(shí)執(zhí)行代碼也能夠被靈活的codegen出來。唯一的一個(gè)影響就是這個(gè)版本的SQL和TableAPI不能和DataSet這個(gè)API進(jìn)行互相轉(zhuǎn)換,但仍然保留了和DataStream API互相轉(zhuǎn)換的能力(將DataStream注冊成表,或?qū)able轉(zhuǎn)成DataStream后繼續(xù)操作)。未來,我們計(jì)劃把dataset的功能慢慢都在DataStream和TableAPI上面實(shí)現(xiàn)。到那時(shí)DataStream和SQL以及tableAPI一樣,是一個(gè)可以同時(shí)描述bounded以及unbounded processing的API。
除了架構(gòu)上的重構(gòu),Blink還在具體實(shí)現(xiàn)上做了較多比較大的重構(gòu)。首先,Blink引入了二進(jìn)制的數(shù)據(jù)結(jié)構(gòu)BinaryRow,極大的減少了數(shù)據(jù)存儲上的開銷以及數(shù)據(jù)在序列化和反序列化上計(jì)算的開銷。其次,在算子的實(shí)現(xiàn)層面,Blink在更廣范圍內(nèi)引入了CodeGen技術(shù)。由于預(yù)先知道算子需要處理的數(shù)據(jù)的類型,在QP層內(nèi)部就可以直接生成更有針對性更高效的執(zhí)行代碼。
Blink的算子會(huì)動(dòng)態(tài)的申請和使用資源,能夠更好的利用資源,提升效率,更加重要的是這些算子對資源有著比較好的控制,不會(huì)發(fā)生OutOfMemory 的問題。此外,針對流計(jì)算場景,Blink加入了miniBatch的執(zhí)行模式,在aggregate、join等需要和state頻繁交互且往往又能先做部分reduce的場景中,使用miniBatch能夠極大的減少IO,從而成數(shù)量級的提升性能。除了上面提到的這些重要的重構(gòu)和功能點(diǎn),Blink還實(shí)現(xiàn)了完整的SQL DDL,帶emit策略的流計(jì)算DML,若干重要的SQL功能,以及大量的性能優(yōu)化策略。
有了上面提到的諸多架構(gòu)和實(shí)現(xiàn)上的重構(gòu)。Blink的SQL/tableAPI在功能和性能方面都取得了脫胎換骨的變化。在批計(jì)算方面,首先Blink batch SQL能夠完整的跑通TPC-H和TPC-DS,且性能上有著極大的提升。如上圖所示,是這次開源的Blink版本和spark 2.3.1的TPC-DS的benchmark性能對比。柱狀圖的高度代表了運(yùn)行的總時(shí)間,高度越低說明性能越好。可以看出,Blink在TPC-DS上和Spark相比有著非常明顯的性能優(yōu)勢。而且這種性能優(yōu)勢隨著數(shù)據(jù)量的增加而變得越來越大。在實(shí)際的場景這種優(yōu)勢已經(jīng)超過 Spark的三倍。在流計(jì)算性能上我們也取得了類似的提升。我們線上的很多典型作業(yè),它的性能是原來的3到5倍。在有數(shù)據(jù)傾斜的場景,以及若干比較有挑戰(zhàn)的TPC-H query,流計(jì)算性能甚至得到了數(shù)十倍的提升。
除了標(biāo)準(zhǔn)的Relational SQL API。TableAPI在功能上是SQL的超集,因此在SQL上所有新加的功能,我們在tableAPI也添加了相對應(yīng)的API。除此之外,我們還在TableAPI上引入了一些新的功能。其中一個(gè)比較重要是cache功能。在批計(jì)算場景下,用戶可以根據(jù)需要來cache計(jì)算的中間結(jié)果,從而避免不必要的重復(fù)計(jì)算。它極大的增強(qiáng)了interactive programming體驗(yàn)。我們后續(xù)會(huì)在tableAPI上添加更多有用的功能。其實(shí)很多新功能已經(jīng)在社區(qū)展開討論并被社區(qū)接受,例如我們在tableAPI增加了對一整行操作的算子map/flatMap/aggregate/flatAggregate(Flink FLIP29)等等。
Hive的兼容性我們這次開源的版本實(shí)現(xiàn)了在元數(shù)據(jù)(meta data)和數(shù)據(jù)層將Flink和Hive對接和打通。國內(nèi)外很多公司都還在用 Hive 在做自己的批處理。對于這些用戶,現(xiàn)在使用這次Blink開源的版本,就可以直接用Flink SQL去查詢Hive的數(shù)據(jù),真正能夠做到在Hive引擎和Flink引擎之間的自由切換。
為了打通元數(shù)據(jù),我們重構(gòu)了Flink catalog的實(shí)現(xiàn),并且增加了兩種catalog,一個(gè)是基于內(nèi)存存儲的FlinkInMemoryCatalog,另外一個(gè)是能夠橋接Hive metaStore的HiveCatalog。有了這個(gè)HiveCatalog,F(xiàn)link作業(yè)就能讀取Hive的metaData。為了打通數(shù)據(jù),我們實(shí)現(xiàn)了HiveTableSource,使得Flink job可以直接讀取Hive中普通表和分區(qū)表的數(shù)據(jù)。因此,通過這個(gè)版本,用戶可以使用Flink SQL讀取已有的Hive meta和data,做數(shù)據(jù)處理。未來我們將在Flink上繼續(xù)加大對Hive兼容性的支持,包括支持Hive特有的query,data type,和Hive UDF等等。
Zeppelin for Flink為了提供更好的可視化和交互式體驗(yàn),我們做了大量的工作讓Zeppelin能夠更好的支持Flink。這些改動(dòng)有些是在Flink上的,有些是在Zeppelin上的。在這些改動(dòng)全部推回Flink和Zeppelin社區(qū)之前,大家可以使用這個(gè)Zeppelin image(具體細(xì)節(jié)請參考Blink代碼里的docs/quickstart/zeppelin_quickstart.md)來測試和使用這些功能。這個(gè)用于測試的Zeppelin版本,首先很好的融合和集成了Flink的多種運(yùn)行模式以及運(yùn)維界面。使用文本SQL和tableAPI可以自如的查詢Flink的static table和dynamic table。
此外,針對Flink的流計(jì)算的特點(diǎn),這一版Zeppelin也很好的支持了savepoint,用戶可以在界面上暫停作業(yè),然后再從savepoint恢復(fù)繼續(xù)運(yùn)行作業(yè)。在數(shù)據(jù)展示方面,除了傳統(tǒng)的數(shù)據(jù)分析界面,我們也添加了流計(jì)算的翻牌器和時(shí)間序列展示等等功能。為了方便用戶試用,我們在這一版zeppelin中提供3個(gè)built-in的Flink tutorial的例子: 一個(gè)是做StreamingETL的例子, 另外兩個(gè)分別是做Flink Batch,Flink Stream的基礎(chǔ)樣例。
Flink Web我們對Flink Web的易用性與性能等多個(gè)方面做了大量的改進(jìn),從資源使用、作業(yè)調(diào)優(yōu)、日志查詢等維度新增了大量功能,使得用戶可以更方便的對Flink作業(yè)進(jìn)行運(yùn)維。在資源使用方面,新增了Cluster、TaskManager與Job三個(gè)級別的資源信息,使得資源的申請與使用情況一目了然。作業(yè)的拓?fù)潢P(guān)系及數(shù)據(jù)流向可以追溯至 Operator 級別,Vertex 增加了InQueue,OutQueue等多項(xiàng)指標(biāo),可以方便的追蹤數(shù)據(jù)的反壓、過濾及傾斜情況。TaskManager 和 JobManager 的日志功能得到大幅度加強(qiáng),從Job、Vertex、SubTask 等多個(gè)維度都可以關(guān)聯(lián)至對應(yīng)日志,提供多日志文件訪問入口,以及分頁展示查詢和日志高亮功能。
另外,我們使用了較新的Angular 7.0 對Flink web進(jìn)行了全面重構(gòu),頁面運(yùn)行性能有了一倍以上的提升。在大數(shù)據(jù)量情況下也不會(huì)發(fā)生頁面卡死或者卡頓情況。同時(shí)對頁面的交互邏輯進(jìn)行了整體優(yōu)化,絕大部分關(guān)聯(lián)信息在單個(gè)頁面就可以完成查詢和比對工作,減少了大量不必要的跳轉(zhuǎn)。
未來的規(guī)劃Blink邁出了全面開源的第一步,接下來我們會(huì)和社區(qū)合作,盡可能以最快的方式將Blink的功能和性能上的優(yōu)化merge回Flink。本次的開源版本一方面貢獻(xiàn)了Blink多年在流計(jì)算的積累,另一方面又重磅推出了在批處理上的成果。接下來,我們會(huì)持續(xù)給Flink社區(qū)貢獻(xiàn)其他方面的功能。我們期望每過幾個(gè)月就能看到技術(shù)上有一個(gè)比較大的亮點(diǎn)貢獻(xiàn)到社區(qū)。下一個(gè)亮點(diǎn)應(yīng)該是對機(jī)器學(xué)習(xí)的支持。要把機(jī)器學(xué)習(xí)支持好,有一系列的工作要做,包括引擎的功能,性能,和易用性。這里面大部分的工作我們已經(jīng)開發(fā)完成,并且很多功能都已經(jīng)在阿里巴巴內(nèi)部服務(wù)上線了。
除了技術(shù)上創(chuàng)新以及新功能之外,F(xiàn)link的易用性和外圍生態(tài)也非常重要。我們已經(jīng)啟動(dòng)了若干這方面的項(xiàng)目,包括Python以及Go等多語言支持,F(xiàn)link集群管理,Notebook,以及機(jī)器學(xué)習(xí)平臺等等。這些項(xiàng)目有些會(huì)成為Flink自身的一部分貢獻(xiàn)回社區(qū),有些不是。但它們都基于Flink,是Flink生態(tài)的一個(gè)很好的補(bǔ)充。獨(dú)立于Flink之外的那些項(xiàng)目,我們都也在認(rèn)真的考慮開源出來。總之,Blink在開源的第一天起,就已經(jīng)完全all-in的融入了Flink社區(qū),我們希望所有的開發(fā)者看到我們的誠意和決心。
未來,無論是功能還是生態(tài),我們都會(huì)在Flink社區(qū)加大投入,我們也將投入力量做 Flink 社區(qū)的運(yùn)營,讓 Flink 真正在中國、乃至全世界大規(guī)模地使用起來。我們衷心的希望更多的人加入,一起把Apache Flink開源社區(qū)做得更好!
閱讀原文
本文來自云棲社區(qū)合作伙伴“阿里技術(shù)”,如需轉(zhuǎn)載請聯(lián)系原作者。
文章版權(quán)歸作者所有,未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址:http://specialneedsforspecialkids.com/yun/11963.html
摘要:基于流處理機(jī)制實(shí)現(xiàn)批流融合相對基于批處理機(jī)制實(shí)現(xiàn)批流融合的思想更自然,更合理,也更有優(yōu)勢,因此阿里巴巴在基于支持大量核心實(shí)時(shí)計(jì)算場景的同時(shí),也在不斷改進(jìn)的架構(gòu),使其朝著真正批流融合的統(tǒng)一計(jì)算引擎方向前進(jìn)。 阿里妹導(dǎo)讀:2018年12月下旬,由阿里巴巴集團(tuán)主辦的Flink Forward China在北京國家會(huì)議中心舉行。Flink Forward是由Apache軟件基金會(huì)授權(quán)的全球范圍...
摘要:基于在阿里巴巴搭建的平臺于年正式上線,并從阿里巴巴的搜索和推薦這兩大場景開始實(shí)現(xiàn)。在經(jīng)過一番調(diào)研之后,阿里巴巴實(shí)時(shí)計(jì)算認(rèn)為是一個(gè)非常適合的選擇。接下來,我們聊聊阿里巴巴在層對又大刀闊斧地進(jìn)行了哪些改進(jìn)。 Apache Flink 概述 Apache Flink(以下簡稱Flink)是誕生于歐洲的一個(gè)大數(shù)據(jù)研究項(xiàng)目,原名StratoSphere。該項(xiàng)目是柏林工業(yè)大學(xué)的一個(gè)研究性項(xiàng)目,早期...
摘要:從長遠(yuǎn)來看,阿里決定用做一個(gè)統(tǒng)一的通用的大數(shù)據(jù)引擎作為未來的選型。在阿里的現(xiàn)狀基于在阿里巴巴搭建的平臺于年正式上線,并從阿里巴巴的搜索和推薦這兩大場景開始實(shí)現(xiàn)。目前阿里巴巴所有的業(yè)務(wù),包括阿里巴巴所有子公司都采用了基于搭建的實(shí)時(shí)計(jì)算平臺。 本文主要整理自阿里巴巴計(jì)算平臺事業(yè)部資深技術(shù)專家莫問在云棲大會(huì)的演講。 合抱之木,生于毫末 隨著人工智能時(shí)代的降臨,數(shù)據(jù)量的爆發(fā),在典型的大數(shù)據(jù)的業(yè)...
閱讀 1344·2023-04-26 00:35
閱讀 2713·2023-04-25 18:32
閱讀 3344·2021-11-24 11:14
閱讀 770·2021-11-22 15:24
閱讀 1417·2021-11-18 10:07
閱讀 6466·2021-09-22 10:57
閱讀 2773·2021-09-07 09:58
閱讀 3565·2019-08-30 15:54