阿里妹導讀：很多童鞋在後臺留言，希望看到大資料相關的文章。因此，今天帶來一篇阿里資深專家觀滔在2017年雲棲大會的精彩分享，為大家展示阿里大資料計算服務的進化演進、以及MaxCompute解讀。

一、阿里雲大資料計算服務概述

阿里巴巴大資料計算服務MaxCompute的前身叫做ODPS，是阿里巴巴內部統一的大資料平臺，其實從ODPS到MaxCompute的轉變就是整個阿里巴巴大資料平臺的演化過程。所以在本次會著重分享阿里巴巴大資料在過去七八年的時間所走過的路以及後續技術發展大方向。

首先做一個基本的定位，大家可以看到下面這張圖是一個航空母艦戰隊。如果把阿里巴巴整體資料體系比作這個戰隊，那麼MaxCompute就是中間的那艘航空母艦，幾乎阿里巴巴99%的資料儲存以及95%的計算能力都在這個平臺上產生。

每天有大概超過一萬四千名阿里巴巴內部的開發者會在這個平臺上進行開發，也就是每四個阿里員工中就有一個在使用這個平臺。每天有超過三百萬個作業在這個平臺上執行，幾乎涵蓋了阿里內部所有的資料體系，包括支付寶的芝麻信用分，淘寶商家的每日商鋪賬單以及“雙11”的大流量處理都是在這個平臺上進行的。

MaxCompute平臺有上萬臺伺服器分佈在多個不同地域的叢集中，具備多叢集的容災能力。在公共雲上，MaxCompute每年以250%的使用者量和計算量在增長。此外MaxCompute對接到專有云平臺上提供了幾十套的部署，這裡包括了大安全、水利等所有政府業務，也包括城市大腦專案，幾乎所有城市大腦專案的底層都是使用這套系統做儲存和大資料計算服務，以上就是對於MaxCompute平臺的整體定位。

如下圖所示的是MaxCompute平臺技術全景圖。其中最底層是計算平臺，最下面是資料流入流出的資料匯流排，稱為DataHub，它現在也為公有云提供服務。資料會通過DataHub流入到MaxCompute大資料計算平臺上來，在MaxCompute平臺上會與包括人工智慧平臺在內的所有平臺進行互動構成完整資料平臺的計算體系。

在這之上是開發套件，如Dataworks、MaxCompute Studio，其包括最基本的對資料的管理和認知、對於資料的開發以及對作業的開發和管理。針對於這樣的開發和基礎平臺，向上提供的計算服務包括語音轉文字、光學文字識別、機器翻譯以及智慧大腦這些業務類的產品。在應用層就包括了向淘寶、天貓等比較老牌的淘系產品以及比較新的高德、菜鳥網路以及合一集團等提供所有的技術服務，以上就是MaxCompute平臺對內和對外的整體佈局。

二、阿里巴巴資料平臺進化之路

接下來分享MaxCompute平臺在過去的七八年時間裡是如何演化的。在淘系建立之初，在2009年之前使用基本都是IOE的系統，當時阿里更加偏重電商系的系統，屬於垂直線的。當時每個BU都有自己的一套從上到下、從業務到平臺的產品。2009年的時候，使用的資料庫基本都是Oracle，當時阿里巴巴擁有亞洲最大的Oracle叢集，所以在那個時候戲稱為Oracle之巔，當時的計算規模已經到達百TB的級別了。

然後發現隨著淘寶運算量的發展，也隨著使用者量每年以百分之幾百甚至上千的增長速率不斷增加，Oracle叢集無法承接所有業務的發展，所以當時思考的第二個專案就是Greemplum。因為Greenplum與Oracle的相容度比較好，所以當時想到在Oracle遇到瓶頸的時候使用Greenplum做第二條的基礎發展路線。

在阿里巴巴發展之初，各BU都以各自為戰的狀態發展，其實這也是各個公司在創立之初的普遍狀態。大約經過了一年多的時間，阿里巴巴又遇到了Greenplum的天花板，此時的資料量大概比Oracle擴充套件了10倍。但是此時發現Greenplum在百臺機器之後就很難再擴充套件上去了，但是即便是百臺機器的規模對於阿里這樣蓬勃發展的企業而言是遠遠不夠的。

2009年9月阿里雲啟動，當時給出的願景是要做一整套計算平臺，其包括三大部分：底層的分散式儲存系統——盤古、分散式排程系統——伏羲、分散式大資料儲存服務——ODPS，也就是現在的MaxCompute。

大概花了一年的時間，第一個平臺開始運行了，當時的ODPS就作為核心的計算引擎在其中發揮作用。

到了2012年，這個平臺基本上穩定了，這時候開始做到資料統一儲存、資料統一的標準化和安全統一管理。當做實現了上述目標之後，在2013年的時候開始大規模的商業化。當時做了一個“5K”專案，也就是單叢集突破5千臺，同時具備多叢集的能力，這種二級擴充套件能力基本上就標誌著阿里內部的資料平臺的奠基基本完成。

與此同時，因為在做這套產品時候，由於各個BU之間之前是各自為戰的，有很多的BU採用了開源的Hadoop體系，所以在當時有兩套體系同時存在，一套稱為雲梯1也就是基於開源體系的，另外一套叫做雲梯2就是阿里內部自研體系的。那時候阿里巴巴的Hadoop叢集做到了亞洲最大規模，達到了5000臺，能夠提供PB級別的資料處理能力。

2014年到2015年，因為有兩套技術體系並立，所以阿里內部做了一個決定就是將整個技術體系進行統一，所以啟動了“登月”計劃。而在“登月”的過程中必須要考慮幾個需求：

• 多叢集的能力
• 良好的安全性
• 海量的資料處理能力並且需要具備金融級的穩定性。

基於上述需求，阿里巴巴當時選擇了雲梯2系統，也就是今天大家看到的MaxCompute。

2016年到2017年，MaxCompute開始對內支撐所有的業務，並且也開始對外提供服務。多叢集擴充套件到超過萬臺，並且開始全球化的部署，現在MaxCompute在美東、美西、新加坡、日本、澳大利亞、香港、德國以及俄羅斯都部署了叢集。

登月計劃 —— 一個統一的過程

接下來分享“登月”計劃和為什麼選擇這樣的一條技術路線。正如上述所提到的在執行“登月”計劃之前，各個BU之間存在著大大小小數十個計算平臺，這是業務初期的必然屬性。而在技術上最終出現了兩套體系，一套是基於開源的體系，另外一套則是基於自研的體系。其實這兩套體系在技術和架構上來講或多或少都有相互的借鑑，但是在技術發展線路上又各不相同，在資料儲存格式、排程方法以及對外運算介面上也是各不相同的。當時遇到了以下幾個問題：

• 擴充套件性差，在兩三年前的那個時候，Hadoop體系的NameNode，JobTracker，HiveServer等都還是單點系統，在穩定性層面上存在一定的問題。
• 效能低，在5K及以上的規模上引擎效能的提升有限，也就是在5K以下基本上可以做到線性擴充套件，但是超過5千臺之後可能就會有問題。
• 安全性不夠高，這一點是非常值得關注的問題。因為整個阿里巴巴在萬人級別的規模上是一套標準的多租戶體系。所謂多租戶就是阿里有很多個BU，每個BU之下有很多個部門，每個部門之下還有組和員工，那麼每個BU以及每個部門之間獲取的許可權應該是不同的，對於如何在資料安全的前提下進行共享的要求非常高，對此基於檔案的授權體系不能滿足靈活要求。
• 穩定性比較差，不能支援多個叢集和跨叢集容災。

並且當時程式碼雖然開源但反饋回社群的週期很長，很多叢集變成事實上的“自研”系統；這又進一步導致的版本不統一，各個叢集無法互聯互通！當時出現的問題就是淘寶的資料，天貓都無法使用，小微金融的資料其他的BU也無法使用，互相申請許可權非常困難，整個體系無法打通。但是大家都知道阿里巴巴不是依靠實體資產，阿里巴巴沒有商品和倉儲，內部最為核心的就是資料資產。如果在平臺性的體系中，資料無法做到互聯互通和高效運轉，那麼就會對公司發展造成很大的危害。

所以阿里巴巴就經歷了這樣的一個“漫長”和“昂貴”的登月過程。在登月計劃中，阿里巴巴集團層面牽頭，其中有名有姓的專案大概有24個，當時的登月1號是阿里金融，登月2號是淘寶，這24個專案的“登月”總共歷時了一年半的時間，將整個資料統一到了一起。

為了保障“登月計劃”的順利實施，當時MaxCompute平臺做了這樣的幾件事情：

• 保證能夠滿足當時Hadoop叢集所能夠提供的功能，在效能方面至少不會比其他平臺差。
• 在程式設計介面層面，需要讓程式設計模型等多個方面相容。
• 提供完善的上雲工具和資料遷移/對比工具，使得可以方便地從Hadoop體系中遷移到MaxCompute上來。
• 由於不得不在業務進行中升級，和業務方一起做無縫升級方案，“在行駛的飛機上換引擎”。

在實現了統一之後大致有這樣三點好處：

• 打造了集團統一的大資料平臺。“登月計劃”將阿里巴巴內部所有的機器資源、資料資源統一到了一起。因為資料具備“1+1>2”的特性，所有的資料貫通之後，叢集整體的利用效率、員工的工作效率以及資料流轉等方面就變得非常高效的。到目前阿里集團內部計算業務運行於MaxCompute叢集上，總儲存能力達到EB級別，每天執行ODPS_TASK超過幾百萬。
• 新平臺是安全的，同時可管理、能開放。因為阿里巴巴內部儲存的資料和其他的廠商並不一樣，阿里巴巴內部很多資料都是交易或者金融資料，所以對於資料的安全性要求非常高，比如同一張表中不同的欄位對於不同的使用者而言許可權應該是不同的，MaxCompute平臺提供了這種細粒度的安全性。在登月的過程中，不僅將資料統一到了一起，還實現了資料分級打標、資料脫敏、ODPS授權流程、虛擬域接入在雲端查詢版等工作。
• 新平臺具備高效能和全面的資料統一。隨著把資料統一到一起，阿里巴巴在管理平臺上也做了統一化，比如統一的排程中心、同步工具和資料地圖等，通過這些將阿里的資料體系進行全面的統一。而且新平臺因為經過了很多的業務錘鍊和梳理以及人員的整合，整個團隊在一個比較大的規模上可以投入到一個平臺上做更好的效能優化和功能調優，所以在2014年儲存資源優化節約幾百PB，通過梳理，各業務團隊的作業數/計算量分別有30%-50%的下降，一些歷史遺留問題得到全面的清理。

三、MaxCompute 2.0 Now and moving forward

接下來分享當阿里巴巴具備了內部統一的大資料平臺之後，未來在基礎和業務上應該如何做。

MaxCompute 2.0 架構持續升級

在2016年杭州雲棲大會上，阿里巴巴釋出了MaxCompute 2.0，那個時候推出了全新的SQL引擎並且提供非結構化處理能力，在2017年MaxCompute做了持續的創新和優化。

如下圖所示，MaxCompute 2.0實現了很多的技術創新，最上面MaxCompute提供了DataWorks開發套件以及MaxCompute Studio；在運算模式上可以支援多種，比如批處理、互動式、記憶體以及迭代等。再往下在介面層面，今年會推出一個新的查詢語言叫做NewSQL，它是阿里巴巴定義的一套新的大資料語言，這套語言相容傳統SQL特性，同時又提供imperative與declarative優勢。

在引擎層面，優化器除了可以基於代價還可以基於歷史執行資訊進行優化。在執行時方面，將IO做成了全非同步化。在元資料管理、資源排程和任務排程方面主要做了兩件事，一個是做到了Bubble Based Scheduling，也就是當將所有作業資料連線到一起進行Bubble Shuffle的時候，要求上下游是完全拉起的，這對於資源的消耗是非常高的，而Bubble是通過做一個合理的failover 的Group在資源和效率上找到一個平衡點；另外一點是今年著眼於生態和開放性，可以和Hadoop以及Spark等叢集做靈活的互動，這是今年在生態層面的發力。

在底層，MaxCompute今年除了提供原始的檔案格式之外還提供了Index的支援，提供了AliORC，它與社群原生ORC相容，效能卻更高。此外，MaxCompute今年還開始做分級儲存，除了記憶體和快取以外，還會在SSD、SSD的HDD以及冷備壓縮儲存上做分層儲存，今年其實在內部已經提供了超密儲存的機型，未來也會逐步地轉移到公有云上來。

大資料計算 典型場景分析（從開發到上線）

下圖所示的是大資料計算的典型場景分析，這也是阿里內部大多數員工以及雲上的經常會接觸的事情。通常情況下，一套大資料體系的建立需要分成這樣幾個過程，需要從資料來源到開發階段再到生產階段。

首先，資料來源可以是應用，也可以是應用的服務，也可能來自應用的log日誌。一方面可以將應用的資訊通過log或者message的方式上傳上來，另一方面很多資料資訊其實落在DB中，DB的binlog其實可以被採集下來同步到資料平臺中。

另外一部分資料來源就是已有的存量資料。當擁有了這些資料之後可以通過主動拉取、手動上傳以及同步中心的方式將資料上傳到叢集中來。之後就可以進入開發階段，開發階段又分為三個部分，第一個部分是資料發現，也就是究竟有什麼樣的資料可以用，通過IDE的方式做作業的編寫或者做資料的編寫。在開發階段提供了通用計算、機器學習、圖計算以及流計算等。

在開發完成之後進入到生產階段，在生產階段的Workload就分成3部分、一類叫做Workflow，每個月生成一份賬單報表就是一個典型的Workflow任務，其特點就是具備週期性，比如每天、每小時或者每個月，這種型別的作業通常情況下作業量比較大，但是週期性卻是可以預測的。

再往下就是Interactive Analysis，也就是互動式查詢，大家可能某一天希望看到資料上的某些統計資訊，然後基於這些資訊做商業決策，這也許會寫到明天的某一份報告裡，這種是與開發者做互動的，寫一個作業上去發現數據有問題再調整回來，然後來回做這樣的互動。

第三點是基於時序或者流式的資料處理，這種處理比較典型的就是“雙11”資料大屏，它就是滾動的流式計算的典型特點，基本的生產場景就分為以上三大類。

這三大類場景的要求是各不相同的，在資料來源層面，對於資料的上傳，當資料量比較大的時候，隔離流控是一個技術要點。同時當進入到生產階段，資料的上傳上載需要具備完整性的檢查，包括需要進行規則檢查的補充。當資料上傳變成常規形態的時候，每天都會進行資料上傳的時候就有可能因為系統、應用或者資料來源的問題導致資料斷裂，這種情況發生之後就需要系統具備補資料的能力。

而系統也需要對於開發階段提供必要的支援，因為開發階段通常是小資料量的，程式碼和指令碼的更新速度比較快，可能經常處於試錯的過程，所以需要系統具備準實時的能力、開發效率和Debug效率，這實際上是對人提出的要求。當進入到生產階段的時候，通常情況下作業相對比較固定，資源和資料量消耗大，對於穩定性的要求就比較高，系統需要提供系統級別的優化能力以及運算能力。以上就是站在阿里巴巴的角度看的從開發到上線的大資料典型場景的分析。

大資料計算 典型場景分析（從計算量和延遲的角度）

下圖所示的是一個從計算量和延遲的角度看的資料軸，從資料量上看，從100GB到10TB再往上，最高可以到PB級別，在“雙11”當天，MaxCompute平臺處理了上百PB的資料。在延遲的角度，會達到非常低的延遲狀態。可以看到圖中的橘色斜線，其含義是當對於資料量以及實時性的要求越高成本就會越高，所以大資料計算的要求就是將這個軸一直向上移動，也就是能夠在更短的時間內處理更大量的資料的時候成本越來越低。

在作業分析來看，主要分成三塊，其中最典型的資料清洗、數倉建立以及報表類的作業等通常情況下是以小時和天為單位執行的，按照阿里巴巴的資料統計基本上20%這樣型別的任務會消耗掉80%的計算資源，這樣任務的特定就是基本上以定時任務為主，query是固定的，所以通常情況下執行效率比較高。而實時監控型別的作業就是典型的流計算業務，比如像監控報警、大屏廣播等。

而互動式作業大致分成兩部分，一類是分析類的另外一類是BI類，BI類的意思是說大多數的人可能看不到Query和中間系統，只能看到BI環境比如像阿里雲對外推出的QuickBI，大家可以通過配置和拖拽的形式訪問系統，這種使用者通常是非技術人員，這對於系統的互動性要求比較高，因為其是在UI上進行工作的，同時對於這樣的工作一般有比較強的延時要求，一般是在秒級或者幾十秒之內完成這樣的作業，所以通常情況下資料量比較小，要求資料提前整理好。

互動分析的資料量處於中小級別，有一定的延遲要求。所以這樣不同任務對應的不同的技術優化方案，Data Workflow就偏向pipeline型的作業，提升執行效能和效率是關鍵，對於以開發類和BI類的作業為主的，作業量比較大佔大頭，但是整體資源佔用率比較低，對於這種型別開發效率和時序化是關鍵。今年在MaxCompute大資料平臺的發展上，除了繼續提升整體系統效率以外，時序化和開發效率也是今年的重點。

大資料計算 互動式BI類場景分析

在這三種Workload中重點分享一下其中比較基本的BI類的作業。為了實現這樣的業務所以對於實時性有更高的要求，比如onlineJob的優化、熱表Cache、Index Support等，還要有更優的查詢計劃、執行時的優化、生態連線、儲存格式的進一步提升，需要在資料上支援Index使得在進行運算的時候可以將資料聚集到更小的規模上去，以上這些都是相關的優化。

如下圖所示的是OnlineJob的基本設計思想，OnlineJob主要是針對中等規模、低延遲的互動式場景，並且提供了可靠的服務，目前在阿里巴巴內部60%的作業都以這種方式來執行。這個模式主要使用了這樣的幾點技術：

• 程序常住（以服務的形式Stand by），程序隨著作業完成之後不銷燬，一直處於等待狀態。
• 程序可以做到作業間複用。
• 網路直連，避免落盤。
• 事件驅動的排程方式。
• 基於統計和歷史資訊的自動切換，使用者不感知。

下圖所展示的是互動式BI類場景下一個優化的例子。傳統基於MapReduce的方式拉起多個Mapper做Shuffle的時候資料會落到磁盤裡，然後再由下面的Join去讀取，中間是割裂的，需要進行一次磁碟的資料交換，而MaxCompute的方式是做網路直連，這樣的好處是不用等到第一個Session做完，第二個Session就可以啟動，而這樣同時也會帶來一個壞處就是當failover的時候Group就會變得很大。

所以需要做的額外工作就是在記憶體中及時地進行Checkpoint，這個Checkpoint也可以做到SSD上或者另外一臺機器上，這樣的方式既提高了效率也降低了延遲並且能夠保證failover Group不失效。

MaxCompute今年與Intel進行了合作在2017 BigBench新的大資料標準上做了評測，這個評測不再是簡單地進行Sort，它一共具有30多個Query，這裡麵包括了基本的SQL Query以及MapReduce Query以及機器學習的作業，其評測的標準除了規模以外也會關心價效比。

目前MaxCompute是全球第一個將這些Query從10TB做到100TB級別的引擎，這樣的能力也是基於阿里內部龐大的資料量的錘鍊獲得的，其次MaxCompute是首個達到7000分的引擎，第三點是MaxCompute價效比的優勢，我們是首個基於公共雲的服務可以跑通整個Query的服務，總體而言費用也是非常便宜的。

為什麼選擇MaxCompute作為大資料平臺

為什麼選擇MaxCompute作為大資料計算平臺呢？在商業層面來講，有以下幾點優點：

• MaxCompute是一個開箱即用的系統，大家完全不用考慮系統的規模問題。
• MaxCompute有很多效能層面的評測和優化，可以實現效能和價效比的最優。
• MaxCompute基於阿里巴巴內部的非常豐富的安全體系保障多租戶情況下的資料安全。
• MaxCompute可以支援多種分散式計算模型。
• MaxCompute支援上雲工具，包括社群相容和生態鏈。

從整體流程來看，如果使用者的資料已經在阿里雲上了，那麼就可以非常容易地通過多種形式遷移到MaxCompute上來。如果資料線上下，可以通過專線或者VPN等形式在已有的資料集上通過各種同步工具遷移到雲上。

在雲上可以通過資料整合和大資料專案的開發工具進行開發。針對普通的資料整合可以使用Data IDE以及專門的外掛進行開發。當進入叢集中使用平臺做資料計算服務的時候，可以非常方便地實現與機器學習平臺的聯動，也可以和阿里雲的推薦引擎、報表分析產品工具等緊密地結合在一起。

我的分享就到這兒，謝謝大家。

每天一篇技術文章，

看不過癮？

關注“阿里巴巴機器智慧”微信公眾號

發現更多AI乾貨。