閱讀307 返回首頁    go 阿裏雲 go 技術社區[雲棲]


MaxCompute 2.0:阿裏巴巴的大數據進化之路

本次分享將主要圍繞以下三個方麵:

  • 阿裏雲大數據計算服務概述
  • 阿裏巴巴數據平台進化之路
  • MaxCompute 2.0 Moving forward 

 6107e043b66b272ab242a337278589132cd69dea


一、阿裏雲大數據計算服務概述

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

 

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

d86e1ac501a4f2ffd222e1fb711e9e1b2e277da2

每天有大概超過一萬四千名阿裏巴巴內部的開發者會在這個平台上進行開發,也就是每四個阿裏員工中就有一個在使用這個平台。每天有超過三百萬個作業在這個平台上運行,幾乎涵蓋了阿裏內部所有的數據體係,包括支付寶的芝麻信用分,淘寶商家的每日商鋪賬單以及“雙11”的大流量處理都是在這個平台上進行的。MaxCompute平台有上萬台服務器分布在多個不同地域的集群中,具備多集群的容災能力。在公共雲上,MaxCompute每年以250%的用戶量和計算量在增長。此外MaxCompute對接到專有雲平台上提供了幾十套的部署,這裏包括了大安全、水利等所有政府業務,也包括城市大腦項目,幾乎所有城市大腦項目的底層都是使用這套係統做存儲和大數據計算服務,以上就是對於MaxCompute平台的整體定位。

 

如下圖所示的是MaxCompute平台技術全景圖。其中最底層是計算平台,最下麵是數據流入流出的數據總線,稱為DataHub,它現在也為公有雲提供服務。數據會通過DataHub流入到MaxCompute大數據計算平台上來,在MaxCompute平台上會與包括人工智能平台在內的所有平台進行互動構成完整數據平台的計算體係。在這之上是開發套件,如Dataworks、MaxCompute Studio,其包括最基本的對數據的管理和認知、對於數據的開發以及對作業的開發和管理。針對於這樣的開發和基礎平台,向上提供的計算服務包括語音轉文本、光學文字識別、機器翻譯以及智能大腦這些業務類的產品。在應用層就包括了向淘寶、天貓等比較老牌的淘係產品以及比較新的高德、菜鳥網絡以及合一集團等提供所有的技術服務,以上就是MaxCompute平台對內和對外的整體布局。

9e52c3808fb828865f9affa06e12dbdfa6739eab

 

二、阿裏巴巴數據平台進化之路

接下來分享MaxCompute平台在過去的七八年時間裏是如何演化的。在淘係建立之初,在2009年之前使用基本都是IOE的係統,當時阿裏更加偏重電商係的係統,屬於垂直線的。當時每個BU都有自己的一套從上到下、從業務到平台的產品。2009年的時候,使用的數據庫基本都是Oracle,當是阿裏巴巴擁有亞洲最大的Oracle集群,所以在那個時候戲稱為Oracle之巔,當時的計算規模已經到達百TB的級別了。然後發現隨著淘寶運算量的發展,也隨著用戶量每年以百分之幾百甚至上千的增長速率不斷增加,Oracle集群無法承接所有業務的發展,所以當時思考的第二個項目就是Greemplum。因為Greenplum與Oracle的兼容度比較好,所以當時想到在Oracle遇到瓶頸的時候使用Greenplum做第二條的基礎發展路線。

22750cf25f722a2c2cfebc707709204b39115d02

在阿裏巴巴發展之初,各BU都以各自為戰的狀態發展,其實這也是各個公司在創立之初的普遍狀態。大約經過了一年多的時間,阿裏巴巴又遇到了Greenplum的天花板,此時的數據量大概比Oracle擴展了10倍。但是此時發現Greenplum在百台機器之後就很難再擴展上去了,但是即便是百台機器的規模對於阿裏這樣蓬勃發展的企業而言是遠遠不夠的。2009年9月阿裏雲啟動,當時給出的願景是要做一整套計算平台,其包括三大部分:底層的分布式存儲係統——盤古、分布式調度係統——伏羲、分布式大數據存儲服務——ODPS,也就是現在的MaxCompute。

 

大概花了一年的時間,第一個平台開始運行了,當時的ODPS就作為核心的計算引擎在其中發揮作用。到了2012年,這個平台基本上穩定了,這時候開始做到數據統一存儲、數據統一的標準化和安全統一管理。當做實現了上述目標之後,在2013年的時候開始大規模的商業化。當時做了一個“5K”項目,也就是單集群突破5千台,同時具備多集群的能力,這種二級擴展能力基本上就標誌著阿裏內部的數據平台的奠基基本完成。與此同時,因為在做這套產品時候,由於各個BU之間之前是各自為戰的,有很多的BU采用了開源的Hadoop體係,所以在當時有兩套體係同時存在,一套稱為雲梯1也就是基於開源體係的,另外一套叫做雲梯2就是阿裏內部自研體係的。那時候阿裏巴巴的Hadoop集群做到了亞洲最大規模,達到了500台,能夠提供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個項目的“登月”總共曆時了一年半的時間,將整個數據統一到了一起。

04c6792f80f8f2469e43b3fcaad14b4bc49c8f91

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

  • 保證能夠滿足當時Hadoop集群所能夠提供的功能,在性能方麵至少不會比其他平台差。
  • 在編程接口層麵,需要讓編程模型等多個方麵兼容。
  • 提供完善的上雲工具和數據遷移/對比工具,使得可以方便地從Hadoop體係中遷移到MaxCompute上來。
  • 由於不得不在業務進行中升級,和業務方一起做無縫升級方案,“在行駛的飛機上換引擎”。

18227cac308ae157216c886603b0af4915dbe04e

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

  • 打造了集團統一的大數據平台。“登月計算”將阿裏巴巴內部所有的機器資源、數據資源統一到了一起。因為數據具備“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優勢。

c263e06303c121f18a6fe9af59173bb2956b4d20

在引擎層麵,優化器除了可以基於代價還可以基於曆史運行信息進行優化。在運行時方麵,將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其實可以被采集下來同步到數據平台中。另外一部分數據源就是已有的存量數據。當擁有了這些數據之後可以通過主動拉取、手動上傳以及同步中心的方式將數據上傳到集群中來。之後就可以進入開發階段,開發階段又分為三個部分,第一個部分是數據發現,也就是究竟有什麼樣的數據可以用,通過ID的方式做作業的編寫或者做數據的編寫。在開發階段提供了通用計算、機器學習、圖計算以及流計算等。

feb10863d6f7c123f2ee2461e5685eac9d673fd5

在開發完成之後進入到生產階段,在生產階段的Workload就分成3部分、一類叫做Workflow,每個月生成一份賬單報表就是一個典型的Workflow任務,其特點就是具備周期性,比如每天、每小時或者每個月,這種類型的作業通常情況下作業量比較大,但是周期性卻是可以預測的。再往下就是Interactive Analysis,也就是交互式查詢,大家可能某一天希望看到數據上的某些統計信息,然後基於這些信息做商業決策,這也許會寫到明天的某一份報告裏,這種是與開發者做交互的,寫一個作業上去發現數據有問題再調整回來,然後來回做這樣的交互。第三點是基於時序或者流式的數據處理,這種處理比較典型的就是“雙11”數據大屏,它就是滾動的流式計算的典型特點,基本的生產場景就分為以上三大類。

 

這三大類場景的要求是各不相同的,在數據源層麵,對於數據的上傳,當數據量比較大的時候,隔離流控是一個技術要點。同時當進入到生產階段,數據的上傳上載需要具備完整性的檢查,包括需要進行規則檢查的補充。當數據上傳變成常規形態的時候,每天都會進行數據上傳的時候就有可能因為係統、應用或者數據源的問題導致數據斷裂,這種情況發生之後就需要係統具備補數據的能力。而係統也需要對於開發階段提供必要的支持,因為開發階段通常是小數據量的,代碼和腳本的更新速度比較快,可能經常處於試錯的過程,所以需要係統具備準實時的能力、開發效率和Debug效率,這實際上是對人提出的要求。當進入到生產階段的時候,通常情況下作業相對比較固定,資源和數據量消耗大,對於穩定性的要求就比較高,係統需要提供係統級別的優化能力以及運算能力。以上就是站在阿裏巴巴的角度看的從開發到上線的大數據典型場景的分析。

 

大數據計算 典型場景分析(從計算量和延遲的角度)

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

248a6654d4971f10816c777c392f539c03697b2e

在作業分析來看,主要分成三塊,其中最典型的數據清洗、數倉建立以及報表類的作業等通常情況下是以小時和天為單位運行的,按照阿裏巴巴的數據統計基本上20%這樣類型的任務會消耗掉80%的計算資源,這樣任務的特定就是基本上以定時任務為主,query是固定的,所以通常情況下運行效率比較高。而實時監控類型的作業就是典型的流計算業務,比如像監控報警、大屏廣播等。而交互式作業大致分成兩部分,一類是分析類的另外一類是BI類,BI類的意思是說大多數的人可能看不到Query和中間係統,隻能看到BI環境比如像阿裏雲對外推出的QuickBI,大家可以通過配置和拖拽的形式訪問係統,這種用戶通常是非技術人員,這對於係統的交互性要求比較高,因為其是在UI上進行工作的,同時對於這樣的工作一般有比較強的延時要求,一般是在秒級或者幾十秒之內完成這樣的作業,所以通常情況下數據量比較小,要求數據提前整理好。而交互分析的數據量處於中小級別,有一定的延遲要求。所以這樣不同任務對應的不同的技術優化方案,Data Workflow就偏向pipeline型的作業,提升運行性能和效率是關鍵,對於以開發類和BI類的作業為主的,作業量比較大占大頭,但是整體資源占用率比較低,對於這種類型開發效率和時序化是關鍵。今年在MaxCompute大數據平台的發展上,除了繼續提升整體係統效率以外,時序化和開發效率也是今年的重點。

 

大數據計算 交互式BI類場景分析

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

18f1899dd8bfc1b364464245059b633fb93c4a2b

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

  • 進程常住(以服務的形式Stand by),進程隨著作業完成之後不銷毀,一直處於等待狀態。
  • 進程可以做到作業間複用。
  • 網絡直連,避免落盤。
  • 事件驅動的調度方式。
  • 基於統計和曆史信息的自動切換,用戶不感知。

2156cd27e10e340ff376846920a3460574830251

下圖所展示的是交互式BI類場景下一個優化的例子。傳統基於MapReduce的方式拉起多個Mapper做Shuffle的時候數據會落到磁盤裏,然後再由下麵的Join去讀取,中間是割裂的,需要進行一次磁盤的數據交換,而MaxCompute的方式是做網絡直連,這樣的好處是不用等到第一個Session做完,第二個Session就可以啟動,而這樣同時也會帶來一個壞處就是當failover的時候Group就會變得很大,所以需要做的額外工作就是在內存中及時地進行Checkpoint,這個Checkpoint也可以做到SSD上或者另外一台機器上,這樣的方式既提高了效率也降低了延遲並且能夠保證failover Group不失效。

c3dfa2f627fd1e239d9371b19297b39741cdb49e

MaxCompute今年與Intel進行了合作在2017 BigBench新的大數據標準上做了評測,這個評測不再是簡單地進行Sort,它一共具有30多個Query,這裏麵包括了基本的SQL Query以及MapReduce Query以及機器學習的作業,其評測的標準除了規模以外也會關心性價比。目前MaxCompute是全球第一個將這些Query從10TB做到100TB級別的引擎,這樣的能力也是基於阿裏內部龐大的數據量的錘煉獲得的,其次MaxCompute是首個達到7000分的引擎,第三點是MaxCompute性價比的優勢,我們是首個基於公共雲的服務可以跑通整個Query的服務,總體而言費用也是非常便宜的。

fe7b3a54ec3641bf14db1496cf8b425221248cee

 

為什麼選擇MaxCompute作為大數據平台

2d46ea3c7ee000738a277d7234cb4c30c0b8a4f5

為什麼選擇MaxCompute作為大數據計算平台呢?在商業層麵來講,有以下幾點優點:

  • MaxCompute是一個開箱即用的係統,大家完全不用考慮係統的規模問題。
  • MaxCompute有很多性能層麵的評測和優化,可以實現性能和性價比的最優。
  • MaxCompute基於阿裏巴巴內部的非常豐富的安全體係保障多租戶情況下的數據安全。
  • MaxCompute可以支持多種分布式計算模型。
  • MaxCompute支持上雲工具,包括社區兼容和生態鏈。

 

從整體流程來看,如果用戶的數據已經在阿裏雲上了,那麼就可以非常容易地通過多種形式遷移到MaxCompute上來。如果數據在線下,可以通過專線或者VPN等形式在已有的數據集上通過各種同步工具遷移到雲上。在雲上可以通過數據集成和大數據項目的開發工具進行開發。針對普通的數據集成可以使用Data IDE以及專門的插件進行開發。當進入集群中使用平台做數據計算服務的時候,可以非常方便地實現與機器學習平台的聯動,也可以和阿裏雲的推薦引擎、報表分析產品工具等緊密地結合在一起。

7843e4cf1e54abde40864567dd4fc4c484de3cf2


6c4b69af9fd1b465628b63fcee73224de0b62357


MaxCompute招聘信息:DT時代,與堅持夢想者同行!


阿裏巴巴大數據-玩家社區 https://yq.aliyun.com/teams/6/

---阿裏大數據博文,問答,社群,實踐,有朋自遠方來,不亦說乎……

bba01b493e1c5d904e882b1c380673c6ebe49a98

最後更新:2017-10-20 14:03:30

  上一篇:go  2016—2017前端體係知識圖譜
  下一篇:go  linux雲服務器如何安裝nginx?