[[237596]]

一、阿里云大數(shù)據(jù)計(jì)算服務(wù)概述

阿里巴巴大數(shù)據(jù)計(jì)算服務(wù)MaxCompute的前身叫做ODPS，是阿里巴巴內(nèi)部統(tǒng)一的大數(shù)據(jù)平臺(tái)，其實(shí)從ODPS到MaxCompute的轉(zhuǎn)變就是整個(gè)阿里巴巴大數(shù)據(jù)平臺(tái)的演化過程。所以在本次會(huì)著重分享阿里巴巴大數(shù)據(jù)在過去七八年的時(shí)間所走過的路以及后續(xù)技術(shù)發(fā)展大方向。

[[237597]]

首先做一個(gè)基本的定位，大家可以看到下面這張圖是一個(gè)航空母艦戰(zhàn)隊(duì)。如果把阿里巴巴整體數(shù)據(jù)體系比作這個(gè)戰(zhàn)隊(duì)，那么MaxCompute就是中間的那艘航空母艦，幾乎阿里巴巴99%的數(shù)據(jù)存儲(chǔ)以及95%的計(jì)算能力都在這個(gè)平臺(tái)上產(chǎn)生。

每天有大概超過一萬四千名阿里巴巴內(nèi)部的開發(fā)者會(huì)在這個(gè)平臺(tái)上進(jìn)行開發(fā)，也就是每四個(gè)阿里員工中就有一個(gè)在使用這個(gè)平臺(tái)。每天有超過三百萬個(gè)作業(yè)在這個(gè)平臺(tái)上運(yùn)行，幾乎涵蓋了阿里內(nèi)部所有的數(shù)據(jù)體系，包括支付寶的芝麻信用分，淘寶商家的每日商鋪賬單以及“雙11”的大流量處理都是在這個(gè)平臺(tái)上進(jìn)行的。

MaxCompute平臺(tái)有上萬臺(tái)服務(wù)器分布在多個(gè)不同地域的集群中，具備多集群的容災(zāi)能力。在公共云上，MaxCompute每年以250%的用戶量和計(jì)算量在增長。此外MaxCompute對接到專有云平臺(tái)上提供了幾十套的部署，這里包括了大安全、水利等所有政府業(yè)務(wù)，也包括城市大腦項(xiàng)目，幾乎所有城市大腦項(xiàng)目的底層都是使用這套系統(tǒng)做存儲(chǔ)和大數(shù)據(jù)計(jì)算服務(wù)，以上就是對于MaxCompute平臺(tái)的整體定位。

如下圖所示的是MaxCompute平臺(tái)技術(shù)全景圖。其中最底層是計(jì)算平臺(tái)，最下面是數(shù)據(jù)流入流出的數(shù)據(jù)總線，稱為DataHub，它現(xiàn)在也為公有云提供服務(wù)。數(shù)據(jù)會(huì)通過DataHub流入到MaxCompute大數(shù)據(jù)計(jì)算平臺(tái)上來，在MaxCompute平臺(tái)上會(huì)與包括人工智能平臺(tái)在內(nèi)的所有平臺(tái)進(jìn)行互動(dòng)構(gòu)成完整數(shù)據(jù)平臺(tái)的計(jì)算體系。

在這之上是開發(fā)套件，如Dataworks、MaxCompute Studio，其包括最基本的對數(shù)據(jù)的管理和認(rèn)知、對于數(shù)據(jù)的開發(fā)以及對作業(yè)的開發(fā)和管理。針對于這樣的開發(fā)和基礎(chǔ)平臺(tái)，向上提供的計(jì)算服務(wù)包括語音轉(zhuǎn)文本、光學(xué)文字識別、機(jī)器翻譯以及智能大腦這些業(yè)務(wù)類的產(chǎn)品。在應(yīng)用層就包括了向淘寶、天貓等比較老牌的淘系產(chǎn)品以及比較新的高德、菜鳥網(wǎng)絡(luò)以及合一集團(tuán)等提供所有的技術(shù)服務(wù)，以上就是MaxCompute平臺(tái)對內(nèi)和對外的整體布局。

二、阿里巴巴數(shù)據(jù)平臺(tái)進(jìn)化之路

接下來分享MaxCompute平臺(tái)在過去的七八年時(shí)間里是如何演化的。在淘系建立之初，在2009年之前使用基本都是IOE的系統(tǒng)，當(dāng)時(shí)阿里更加偏重電商系的系統(tǒng)，屬于垂直線的。當(dāng)時(shí)每個(gè)BU都有自己的一套從上到下、從業(yè)務(wù)到平臺(tái)的產(chǎn)品。2009年的時(shí)候，使用的數(shù)據(jù)庫基本都是Oracle，當(dāng)時(shí)阿里巴巴擁有亞洲最大的Oracle集群，所以在那個(gè)時(shí)候戲稱為Oracle之巔，當(dāng)時(shí)的計(jì)算規(guī)模已經(jīng)到達(dá)百TB的級別了。

然后發(fā)現(xiàn)隨著淘寶運(yùn)算量的發(fā)展，也隨著用戶量每年以百分之幾百甚至上千的增長速率不斷增加，Oracle集群無法承接所有業(yè)務(wù)的發(fā)展，所以當(dāng)時(shí)思考的第二個(gè)項(xiàng)目就是Greemplum。因?yàn)镚reenplum與Oracle的兼容度比較好，所以當(dāng)時(shí)想到在Oracle遇到瓶頸的時(shí)候使用Greenplum做第二條的基礎(chǔ)發(fā)展路線。

在阿里巴巴發(fā)展之初，各BU都以各自為戰(zhàn)的狀態(tài)發(fā)展，其實(shí)這也是各個(gè)公司在創(chuàng)立之初的普遍狀態(tài)。大約經(jīng)過了一年多的時(shí)間，阿里巴巴又遇到了Greenplum的天花板，此時(shí)的數(shù)據(jù)量大概比Oracle擴(kuò)展了10倍。但是此時(shí)發(fā)現(xiàn)Greenplum在百臺(tái)機(jī)器之后就很難再擴(kuò)展上去了，但是即便是百臺(tái)機(jī)器的規(guī)模對于阿里這樣蓬勃發(fā)展的企業(yè)而言是遠(yuǎn)遠(yuǎn)不夠的。

2009年9月阿里云啟動(dòng)，當(dāng)時(shí)給出的愿景是要做一整套計(jì)算平臺(tái)，其包括三大部分：底層的分布式存儲(chǔ)系統(tǒng)——盤古、分布式調(diào)度系統(tǒng)——伏羲、分布式大數(shù)據(jù)存儲(chǔ)服務(wù)——ODPS，也就是現(xiàn)在的MaxCompute。

大概花了一年的時(shí)間，第一個(gè)平臺(tái)開始運(yùn)行了，當(dāng)時(shí)的ODPS就作為核心的計(jì)算引擎在其中發(fā)揮作用。

到了2012年，這個(gè)平臺(tái)基本上穩(wěn)定了，這時(shí)候開始做到數(shù)據(jù)統(tǒng)一存儲(chǔ)、數(shù)據(jù)統(tǒng)一的標(biāo)準(zhǔn)化和安全統(tǒng)一管理。當(dāng)做實(shí)現(xiàn)了上述目標(biāo)之后，在2013年的時(shí)候開始大規(guī)模的商業(yè)化。當(dāng)時(shí)做了一個(gè)“5K”項(xiàng)目，也就是單集群突破5千臺(tái)，同時(shí)具備多集群的能力，這種二級擴(kuò)展能力基本上就標(biāo)志著阿里內(nèi)部的數(shù)據(jù)平臺(tái)的奠基基本完成。

與此同時(shí)，因?yàn)樵谧鲞@套產(chǎn)品時(shí)候，由于各個(gè)BU之間之前是各自為戰(zhàn)的，有很多的BU采用了開源的Hadoop體系，所以在當(dāng)時(shí)有兩套體系同時(shí)存在，一套稱為云梯1也就是基于開源體系的，另外一套叫做云梯2就是阿里內(nèi)部自研體系的。那時(shí)候阿里巴巴的Hadoop集群做到了亞洲最大規(guī)模，達(dá)到了5000臺(tái)，能夠提供PB級別的數(shù)據(jù)處理能力。

2014年到2015年，因?yàn)橛袃商准夹g(shù)體系并立，所以阿里內(nèi)部做了一個(gè)決定就是將整個(gè)技術(shù)體系進(jìn)行統(tǒng)一，所以啟動(dòng)了“登月”計(jì)劃。而在“登月”的過程中必須要考慮幾個(gè)需求：

• 多集群的能力
• 良好的安全性
• 海量的數(shù)據(jù)處理能力并且需要具備金融級的穩(wěn)定性。

基于上述需求，阿里巴巴當(dāng)時(shí)選擇了云梯2系統(tǒng)，也就是今天大家看到的MaxCompute。

2016年到2017年，MaxCompute開始對內(nèi)支撐所有的業(yè)務(wù)，并且也開始對外提供服務(wù)。多集群擴(kuò)展到超過萬臺(tái)，并且開始全球化的部署，現(xiàn)在MaxCompute在美東、美西、新加坡、日本、澳大利亞、香港、德國以及俄羅斯都部署了集群。

登月計(jì)劃 —— 一個(gè)統(tǒng)一的過程

接下來分享“登月”計(jì)劃和為什么選擇這樣的一條技術(shù)路線。正如上述所提到的在執(zhí)行“登月”計(jì)劃之前，各個(gè)BU之間存在著大大小小數(shù)十個(gè)計(jì)算平臺(tái)，這是業(yè)務(wù)初期的必然屬性。而在技術(shù)上最終出現(xiàn)了兩套體系，一套是基于開源的體系，另外一套則是基于自研的體系。其實(shí)這兩套體系在技術(shù)和架構(gòu)上來講或多或少都有相互的借鑒，但是在技術(shù)發(fā)展線路上又各不相同，在數(shù)據(jù)存儲(chǔ)格式、調(diào)度方法以及對外運(yùn)算接口上也是各不相同的。當(dāng)時(shí)遇到了以下幾個(gè)問題：

• 擴(kuò)展性差，在兩三年前的那個(gè)時(shí)候，Hadoop體系的NameNode，JobTracker，HiveServer等都還是單點(diǎn)系統(tǒng)，在穩(wěn)定性層面上存在一定的問題。
• 性能低，在5K及以上的規(guī)模上引擎性能的提升有限，也就是在5K以下基本上可以做到線性擴(kuò)展，但是超過5千臺(tái)之后可能就會(huì)有問題。
• 安全性不夠高，這一點(diǎn)是非常值得關(guān)注的問題。因?yàn)檎麄€(gè)阿里巴巴在萬人級別的規(guī)模上是一套標(biāo)準(zhǔn)的多租戶體系。所謂多租戶就是阿里有很多個(gè)BU，每個(gè)BU之下有很多個(gè)部門，每個(gè)部門之下還有組和員工，那么每個(gè)BU以及每個(gè)部門之間獲取的權(quán)限應(yīng)該是不同的，對于如何在數(shù)據(jù)安全的前提下進(jìn)行共享的要求非常高，對此基于文件的授權(quán)體系不能滿足靈活要求。
• 穩(wěn)定性比較差，不能支持多個(gè)集群和跨集群容災(zāi)。

并且當(dāng)時(shí)代碼雖然開源但反饋回社區(qū)的周期很長，很多集群變成事實(shí)上的“自研”系統(tǒng)；這又進(jìn)一步導(dǎo)致的版本不統(tǒng)一，各個(gè)集群無法互聯(lián)互通！當(dāng)時(shí)出現(xiàn)的問題就是淘寶的數(shù)據(jù)，天貓都無法使用，小微金融的數(shù)據(jù)其他的BU也無法使用，互相申請權(quán)限非常困難，整個(gè)體系無法打通。但是大家都知道阿里巴巴不是依靠實(shí)體資產(chǎn)，阿里巴巴沒有商品和倉儲(chǔ)，內(nèi)部最為核心的就是數(shù)據(jù)資產(chǎn)。如果在平臺(tái)性的體系中，數(shù)據(jù)無法做到互聯(lián)互通和高效運(yùn)轉(zhuǎn)，那么就會(huì)對公司發(fā)展造成很大的危害。

所以阿里巴巴就經(jīng)歷了這樣的一個(gè)“漫長”和“昂貴”的登月過程。在登月計(jì)劃中，阿里巴巴集團(tuán)層面牽頭，其中有名有姓的項(xiàng)目大概有24個(gè)，當(dāng)時(shí)的登月1號是阿里金融，登月2號是淘寶，這24個(gè)項(xiàng)目的“登月”總共歷時(shí)了一年半的時(shí)間，將整個(gè)數(shù)據(jù)統(tǒng)一到了一起。

為了保障“登月計(jì)劃”的順利實(shí)施，當(dāng)時(shí)MaxCompute平臺(tái)做了這樣的幾件事情：

• 保證能夠滿足當(dāng)時(shí)Hadoop集群所能夠提供的功能，在性能方面至少不會(huì)比其他平臺(tái)差。
• 在編程接口層面，需要讓編程模型等多個(gè)方面兼容。
• 提供完善的上云工具和數(shù)據(jù)遷移/對比工具，使得可以方便地從Hadoop體系中遷移到MaxCompute上來。
• 由于不得不在業(yè)務(wù)進(jìn)行中升級，和業(yè)務(wù)方一起做無縫升級方案，“在行駛的飛機(jī)上換引擎”。

在實(shí)現(xiàn)了統(tǒng)一之后大致有這樣三點(diǎn)好處：

• 打造了集團(tuán)統(tǒng)一的大數(shù)據(jù)平臺(tái)。“登月計(jì)劃”將阿里巴巴內(nèi)部所有的機(jī)器資源、數(shù)據(jù)資源統(tǒng)一到了一起。因?yàn)閿?shù)據(jù)具備“1+1>2”的特性，所有的數(shù)據(jù)貫通之后，集群整體的利用效率、員工的工作效率以及數(shù)據(jù)流轉(zhuǎn)等方面就變得非常高效的。到目前阿里集團(tuán)內(nèi)部計(jì)算業(yè)務(wù)運(yùn)行于MaxCompute集群上，總存儲(chǔ)能力達(dá)到EB級別，每天運(yùn)行ODPS_TASK超過幾百萬。
• 新平臺(tái)是安全的，同時(shí)可管理、能開放。因?yàn)榘⒗锇桶蛢?nèi)部存儲(chǔ)的數(shù)據(jù)和其他的廠商并不一樣，阿里巴巴內(nèi)部很多數(shù)據(jù)都是交易或者金融數(shù)據(jù)，所以對于數(shù)據(jù)的安全性要求非常高，比如同一張表中不同的字段對于不同的用戶而言權(quán)限應(yīng)該是不同的，MaxCompute平臺(tái)提供了這種細(xì)粒度的安全性。在登月的過程中，不僅將數(shù)據(jù)統(tǒng)一到了一起，還實(shí)現(xiàn)了數(shù)據(jù)分級打標(biāo)、數(shù)據(jù)脫敏、ODPS授權(quán)流程、虛擬域接入在云端查詢版等工作。
• 新平臺(tái)具備高性能和全面的數(shù)據(jù)統(tǒng)一。隨著把數(shù)據(jù)統(tǒng)一到一起，阿里巴巴在管理平臺(tái)上也做了統(tǒng)一化，比如統(tǒng)一的調(diào)度中心、同步工具和數(shù)據(jù)地圖等，通過這些將阿里的數(shù)據(jù)體系進(jìn)行全面的統(tǒng)一。而且新平臺(tái)因?yàn)榻?jīng)過了很多的業(yè)務(wù)錘煉和梳理以及人員的整合，整個(gè)團(tuán)隊(duì)在一個(gè)比較大的規(guī)模上可以投入到一個(gè)平臺(tái)上做更好的性能優(yōu)化和功能調(diào)優(yōu)，所以在2014年存儲(chǔ)資源優(yōu)化節(jié)約幾百PB，通過梳理，各業(yè)務(wù)團(tuán)隊(duì)的作業(yè)數(shù)/計(jì)算量分別有30%-50%的下降，一些歷史遺留問題得到全面的清理。

三、MaxCompute 2.0 Now and moving forward

接下來分享當(dāng)阿里巴巴具備了內(nèi)部統(tǒng)一的大數(shù)據(jù)平臺(tái)之后，未來在基礎(chǔ)和業(yè)務(wù)上應(yīng)該如何做。

MaxCompute 2.0 架構(gòu)持續(xù)升級

在2016年杭州云棲大會(huì)上，阿里巴巴發(fā)布了MaxCompute 2.0，那個(gè)時(shí)候推出了全新的SQL引擎并且提供非結(jié)構(gòu)化處理能力，在2017年MaxCompute做了持續(xù)的創(chuàng)新和優(yōu)化。

如下圖所示，MaxCompute 2.0實(shí)現(xiàn)了很多的技術(shù)創(chuàng)新，最上面MaxCompute提供了DataWorks開發(fā)套件以及MaxCompute Studio；在運(yùn)算模式上可以支持多種，比如批處理、交互式、內(nèi)存以及迭代等。再往下在接口層面，今年會(huì)推出一個(gè)新的查詢語言叫做NewSQL，它是阿里巴巴定義的一套新的大數(shù)據(jù)語言，這套語言兼容傳統(tǒng)SQL特性，同時(shí)又提供imperative與declarative優(yōu)勢。

在引擎層面，優(yōu)化器除了可以基于代價(jià)還可以基于歷史運(yùn)行信息進(jìn)行優(yōu)化。在運(yùn)行時(shí)方面，將IO做成了全異步化。在元數(shù)據(jù)管理、資源調(diào)度和任務(wù)調(diào)度方面主要做了兩件事，一個(gè)是做到了Bubble Based Scheduling，也就是當(dāng)將所有作業(yè)數(shù)據(jù)連接到一起進(jìn)行Bubble Shuffle的時(shí)候，要求上下游是完全拉起的，這對于資源的消耗是非常高的，而Bubble是通過做一個(gè)合理的failover 的Group在資源和效率上找到一個(gè)平衡點(diǎn)；另外一點(diǎn)是今年著眼于生態(tài)和開放性，可以和Hadoop以及Spark等集群做靈活的互動(dòng)，這是今年在生態(tài)層面的發(fā)力。

在底層，MaxCompute今年除了提供原始的文件格式之外還提供了Index的支持，提供了AliORC，它與社區(qū)原生ORC兼容，性能卻更高。此外，MaxCompute今年還開始做分級存儲(chǔ)，除了內(nèi)存和緩存以外，還會(huì)在SSD、SSD的HDD以及冷備壓縮存儲(chǔ)上做分層存儲(chǔ)，今年其實(shí)在內(nèi)部已經(jīng)提供了超密存儲(chǔ)的機(jī)型，未來也會(huì)逐步地轉(zhuǎn)移到公有云上來。

大數(shù)據(jù)計(jì)算 典型場景分析（從開發(fā)到上線）

下圖所示的是大數(shù)據(jù)計(jì)算的典型場景分析，這也是阿里內(nèi)部大多數(shù)員工以及云上的經(jīng)常會(huì)接觸的事情。通常情況下，一套大數(shù)據(jù)體系的建立需要分成這樣幾個(gè)過程，需要從數(shù)據(jù)源到開發(fā)階段再到生產(chǎn)階段。

首先，數(shù)據(jù)源可以是應(yīng)用，也可以是應(yīng)用的服務(wù)，也可能來自應(yīng)用的log日志。一方面可以將應(yīng)用的信息通過log或者message的方式上傳上來，另一方面很多數(shù)據(jù)信息其實(shí)落在DB中，DB的binlog其實(shí)可以被采集下來同步到數(shù)據(jù)平臺(tái)中。

另外一部分?jǐn)?shù)據(jù)源就是已有的存量數(shù)據(jù)。當(dāng)擁有了這些數(shù)據(jù)之后可以通過主動(dòng)拉取、手動(dòng)上傳以及同步中心的方式將數(shù)據(jù)上傳到集群中來。之后就可以進(jìn)入開發(fā)階段，開發(fā)階段又分為三個(gè)部分，第一個(gè)部分是數(shù)據(jù)發(fā)現(xiàn)，也就是究竟有什么樣的數(shù)據(jù)可以用，通過IDE的方式做作業(yè)的編寫或者做數(shù)據(jù)的編寫。在開發(fā)階段提供了通用計(jì)算、機(jī)器學(xué)習(xí)、圖計(jì)算以及流計(jì)算等。

在開發(fā)完成之后進(jìn)入到生產(chǎn)階段，在生產(chǎn)階段的Workload就分成3部分、一類叫做Workflow，每個(gè)月生成一份賬單報(bào)表就是一個(gè)典型的Workflow任務(wù)，其特點(diǎn)就是具備周期性，比如每天、每小時(shí)或者每個(gè)月，這種類型的作業(yè)通常情況下作業(yè)量比較大，但是周期性卻是可以預(yù)測的。

再往下就是Interactive Analysis，也就是交互式查詢，大家可能某一天希望看到數(shù)據(jù)上的某些統(tǒng)計(jì)信息，然后基于這些信息做商業(yè)決策，這也許會(huì)寫到明天的某一份報(bào)告里，這種是與開發(fā)者做交互的，寫一個(gè)作業(yè)上去發(fā)現(xiàn)數(shù)據(jù)有問題再調(diào)整回來，然后來回做這樣的交互。

第三點(diǎn)是基于時(shí)序或者流式的數(shù)據(jù)處理，這種處理比較典型的就是“雙11”數(shù)據(jù)大屏，它就是滾動(dòng)的流式計(jì)算的典型特點(diǎn)，基本的生產(chǎn)場景就分為以上三大類。

這三大類場景的要求是各不相同的，在數(shù)據(jù)源層面，對于數(shù)據(jù)的上傳，當(dāng)數(shù)據(jù)量比較大的時(shí)候，隔離流控是一個(gè)技術(shù)要點(diǎn)。同時(shí)當(dāng)進(jìn)入到生產(chǎn)階段，數(shù)據(jù)的上傳上載需要具備完整性的檢查，包括需要進(jìn)行規(guī)則檢查的補(bǔ)充。當(dāng)數(shù)據(jù)上傳變成常規(guī)形態(tài)的時(shí)候，每天都會(huì)進(jìn)行數(shù)據(jù)上傳的時(shí)候就有可能因?yàn)橄到y(tǒng)、應(yīng)用或者數(shù)據(jù)源的問題導(dǎo)致數(shù)據(jù)斷裂，這種情況發(fā)生之后就需要系統(tǒng)具備補(bǔ)數(shù)據(jù)的能力。

而系統(tǒng)也需要對于開發(fā)階段提供必要的支持，因?yàn)殚_發(fā)階段通常是小數(shù)據(jù)量的，代碼和腳本的更新速度比較快，可能經(jīng)常處于試錯(cuò)的過程，所以需要系統(tǒng)具備準(zhǔn)實(shí)時(shí)的能力、開發(fā)效率和Debug效率，這實(shí)際上是對人提出的要求。當(dāng)進(jìn)入到生產(chǎn)階段的時(shí)候，通常情況下作業(yè)相對比較固定，資源和數(shù)據(jù)量消耗大，對于穩(wěn)定性的要求就比較高，系統(tǒng)需要提供系統(tǒng)級別的優(yōu)化能力以及運(yùn)算能力。以上就是站在阿里巴巴的角度看的從開發(fā)到上線的大數(shù)據(jù)典型場景的分析。

大數(shù)據(jù)計(jì)算 典型場景分析（從計(jì)算量和延遲的角度）

下圖所示的是一個(gè)從計(jì)算量和延遲的角度看的數(shù)據(jù)軸，從數(shù)據(jù)量上看，從100GB到10TB再往上，最高可以到PB級別，在“雙11”當(dāng)天，MaxCompute平臺(tái)處理了上百PB的數(shù)據(jù)。在延遲的角度，會(huì)達(dá)到非常低的延遲狀態(tài)?？梢钥吹綀D中的橘色斜線，其含義是當(dāng)對于數(shù)據(jù)量以及實(shí)時(shí)性的要求越高成本就會(huì)越高，所以大數(shù)據(jù)計(jì)算的要求就是將這個(gè)軸一直向上移動(dòng)，也就是能夠在更短的時(shí)間內(nèi)處理更大量的數(shù)據(jù)的時(shí)候成本越來越低。

在作業(yè)分析來看，主要分成三塊，其中最典型的數(shù)據(jù)清洗、數(shù)倉建立以及報(bào)表類的作業(yè)等通常情況下是以小時(shí)和天為單位運(yùn)行的，按照阿里巴巴的數(shù)據(jù)統(tǒng)計(jì)基本上20%這樣類型的任務(wù)會(huì)消耗掉80%的計(jì)算資源，這樣任務(wù)的特定就是基本上以定時(shí)任務(wù)為主，query是固定的，所以通常情況下運(yùn)行效率比較高。而實(shí)時(shí)監(jiān)控類型的作業(yè)就是典型的流計(jì)算業(yè)務(wù)，比如像監(jiān)控報(bào)警、大屏廣播等。

而交互式作業(yè)大致分成兩部分，一類是分析類的另外一類是BI類，BI類的意思是說大多數(shù)的人可能看不到Query和中間系統(tǒng)，只能看到BI環(huán)境比如像阿里云對外推出的QuickBI，大家可以通過配置和拖拽的形式訪問系統(tǒng)，這種用戶通常是非技術(shù)人員，這對于系統(tǒng)的交互性要求比較高，因?yàn)槠涫窃赨I上進(jìn)行工作的，同時(shí)對于這樣的工作一般有比較強(qiáng)的延時(shí)要求，一般是在秒級或者幾十秒之內(nèi)完成這樣的作業(yè)，所以通常情況下數(shù)據(jù)量比較小，要求數(shù)據(jù)提前整理好。

交互分析的數(shù)據(jù)量處于中小級別，有一定的延遲要求。所以這樣不同任務(wù)對應(yīng)的不同的技術(shù)優(yōu)化方案，Data Workflow就偏向pipeline型的作業(yè)，提升運(yùn)行性能和效率是關(guān)鍵，對于以開發(fā)類和BI類的作業(yè)為主的，作業(yè)量比較大占大頭，但是整體資源占用率比較低，對于這種類型開發(fā)效率和時(shí)序化是關(guān)鍵。今年在MaxCompute大數(shù)據(jù)平臺(tái)的發(fā)展上，除了繼續(xù)提升整體系統(tǒng)效率以外，時(shí)序化和開發(fā)效率也是今年的重點(diǎn)。

大數(shù)據(jù)計(jì)算 交互式BI類場景分析

在這三種Workload中重點(diǎn)分享一下其中比較基本的BI類的作業(yè)。為了實(shí)現(xiàn)這樣的業(yè)務(wù)所以對于實(shí)時(shí)性有更高的要求，比如onlineJob的優(yōu)化、熱表Cache、Index Support等，還要有更優(yōu)的查詢計(jì)劃、運(yùn)行時(shí)的優(yōu)化、生態(tài)連接、存儲(chǔ)格式的進(jìn)一步提升，需要在數(shù)據(jù)上支持Index使得在進(jìn)行運(yùn)算的時(shí)候可以將數(shù)據(jù)聚集到更小的規(guī)模上去，以上這些都是相關(guān)的優(yōu)化。

如下圖所示的是OnlineJob的基本設(shè)計(jì)思想，OnlineJob主要是針對中等規(guī)模、低延遲的交互式場景，并且提供了可靠的服務(wù)，目前在阿里巴巴內(nèi)部60%的作業(yè)都以這種方式來運(yùn)行。這個(gè)模式主要使用了這樣的幾點(diǎn)技術(shù)：

• 進(jìn)程常住（以服務(wù)的形式Stand by），進(jìn)程隨著作業(yè)完成之后不銷毀，一直處于等待狀態(tài)。
• 進(jìn)程可以做到作業(yè)間復(fù)用。
• 網(wǎng)絡(luò)直連，避免落盤。
• 事件驅(qū)動(dòng)的調(diào)度方式。
• 基于統(tǒng)計(jì)和歷史信息的自動(dòng)切換，用戶不感知。

下圖所展示的是交互式BI類場景下一個(gè)優(yōu)化的例子。傳統(tǒng)基于MapReduce的方式拉起多個(gè)Mapper做Shuffle的時(shí)候數(shù)據(jù)會(huì)落到磁盤里，然后再由下面的Join去讀取，中間是割裂的，需要進(jìn)行一次磁盤的數(shù)據(jù)交換，而MaxCompute的方式是做網(wǎng)絡(luò)直連，這樣的好處是不用等到第一個(gè)Session做完，第二個(gè)Session就可以啟動(dòng)，而這樣同時(shí)也會(huì)帶來一個(gè)壞處就是當(dāng)failover的時(shí)候Group就會(huì)變得很大。

所以需要做的額外工作就是在內(nèi)存中及時(shí)地進(jìn)行Checkpoint，這個(gè)Checkpoint也可以做到SSD上或者另外一臺(tái)機(jī)器上，這樣的方式既提高了效率也降低了延遲并且能夠保證failover Group不失效。

MaxCompute今年與Intel進(jìn)行了合作在2017 BigBench新的大數(shù)據(jù)標(biāo)準(zhǔn)上做了評測，這個(gè)評測不再是簡單地進(jìn)行Sort，它一共具有30多個(gè)Query，這里面包括了基本的SQL Query以及MapReduce Query以及機(jī)器學(xué)習(xí)的作業(yè)，其評測的標(biāo)準(zhǔn)除了規(guī)模以外也會(huì)關(guān)心性價(jià)比。

目前MaxCompute是全球第一個(gè)將這些Query從10TB做到100TB級別的引擎，這樣的能力也是基于阿里內(nèi)部龐大的數(shù)據(jù)量的錘煉獲得的，其次MaxCompute是首個(gè)達(dá)到7000分的引擎，第三點(diǎn)是MaxCompute性價(jià)比的優(yōu)勢，我們是首個(gè)基于公共云的服務(wù)可以跑通整個(gè)Query的服務(wù)，總體而言費(fèi)用也是非常便宜的。

為什么選擇MaxCompute作為大數(shù)據(jù)平臺(tái)

為什么選擇MaxCompute作為大數(shù)據(jù)計(jì)算平臺(tái)呢？在商業(yè)層面來講，有以下幾點(diǎn)優(yōu)點(diǎn)：

• MaxCompute是一個(gè)開箱即用的系統(tǒng)，大家完全不用考慮系統(tǒng)的規(guī)模問題。
• MaxCompute有很多性能層面的評測和優(yōu)化，可以實(shí)現(xiàn)性能和性價(jià)比的最優(yōu)。
• MaxCompute基于阿里巴巴內(nèi)部的非常豐富的安全體系保障多租戶情況下的數(shù)據(jù)安全。
• MaxCompute可以支持多種分布式計(jì)算模型。
• MaxCompute支持上云工具，包括社區(qū)兼容和生態(tài)鏈。

從整體流程來看，如果用戶的數(shù)據(jù)已經(jīng)在阿里云上了，那么就可以非常容易地通過多種形式遷移到MaxCompute上來。如果數(shù)據(jù)在線下，可以通過專線或者VPN等形式在已有的數(shù)據(jù)集上通過各種同步工具遷移到云上。

在云上可以通過數(shù)據(jù)集成和大數(shù)據(jù)項(xiàng)目的開發(fā)工具進(jìn)行開發(fā)。針對普通的數(shù)據(jù)集成可以使用Data IDE以及專門的插件進(jìn)行開發(fā)。當(dāng)進(jìn)入集群中使用平臺(tái)做數(shù)據(jù)計(jì)算服務(wù)的時(shí)候，可以非常方便地實(shí)現(xiàn)與機(jī)器學(xué)習(xí)平臺(tái)的聯(lián)動(dòng)，也可以和阿里云的推薦引擎、報(bào)表分析產(chǎn)品工具等緊密地結(jié)合在一起。

【本文為51CTO專欄作者“阿里巴巴官方技術(shù)”原創(chuàng)稿件，轉(zhuǎn)載請聯(lián)系原作者】

戳這里，看該作者更多好文