摘要：?大數(shù)據(jù)計算服務（MaxCompute）是一種快速、完全托管的 GB/TB/PB 級數(shù)據(jù)倉庫解決方案，目前已在阿里巴巴內(nèi)部得到大規(guī)模應用。來自阿里媽媽基礎平臺大規(guī)模數(shù)據(jù)處理技術專家向大家分享了MaxCompute在阿里媽媽數(shù)據(jù)字化營銷解決方案上的典型應用經(jīng)驗。首先介紹了廣告數(shù)據(jù)流，分析了MaxCompute 是如何解決廣告的問題；然后通過阿里媽媽內(nèi)部的應用經(jīng)典場景來介紹其如何使用MaxCompute；最后介紹了MaxCompute提供的高級配套能力以及在計算和存儲方面的優(yōu)化。?

PPT材料下載地址：https://yq.aliyun.com/download/2730

視頻地址：https://edu.aliyun.com/lesson_1010_8790?spm=5176.10731542.0.0.Zy64Up#_8790

產(chǎn)品地址：https://www.aliyun.com/product/odps

演講嘉賓簡介：

梁時木(載思)，阿里媽媽基礎平臺大規(guī)模數(shù)據(jù)處理技術專家。

以下內(nèi)容根據(jù)演講嘉賓視頻分享以及PPT整理而成。

?

本次的分享主要分為兩部分：

一、?題外話：該部分主要介紹在聽完之前的分享后，嘉賓的幾點個人感受 。

二、廣告數(shù)據(jù)流介紹： 該部分主要是對沒有中間商賺差價的廣告數(shù)據(jù)流的基本介紹以及為什么MaxCompute能解決廣告的問題。

三、典型應用場景：該部分主要通過阿里媽媽內(nèi)部的應用經(jīng)典場景來介紹其如何使用MaxCompute，包括數(shù)據(jù)分層體系、報表和BI、搜索引擎索引構建和算法實驗。

四、高級功能和優(yōu)化：該部分主要就阿里媽媽在五六年的MaxCompute內(nèi)部使用和管理過程中的相關高級功能和優(yōu)化進行公開分享，包括MaxCompute提供的高級配套能力以及在計算和存儲方面的優(yōu)化。

?

一、題外話

?

開始之前先聊一點題外話，是我在聽完剛才的分享之后的幾點感受。其實我從2013年就開始在內(nèi)部項目中使用MaxCompute,阿里媽媽作為第一批登月用戶，踩了很多坑。聽了剛才的分享，我的第一感受是，MaxCompute有好多功能我們都沒有關注過，作為一個資深用戶，很多功能都不知道聽起來好像有點不太合格，但轉念一想這可能是MaxCompute作為一個平臺、一個生態(tài)解決方案應該具備的一種能力。就是說它讓一個終端用戶只需要看到你所關注的東西，有一些你不太關注的，而對于整個生態(tài)鏈上又必須有的東西它可能潛移默化的幫你做了，在我看來這其實是一種很強的能力。在聽完分享后的另一個感受就是我還是蠻慶幸在阿里這邊做這些事情的，一些中小公司在基礎設施服務這塊很需要一些第三方平臺的支持，因為你會發(fā)現(xiàn)它們?nèi)绻麖念^搭建的話，成本會特別高，而MaxCompute、阿里包括釘釘這樣的產(chǎn)品，撇開商業(yè)化這個因素，它們更多的其實是幫助我們推動互聯(lián)網(wǎng)技術的進步，幫助我們做一些基礎上的事情，從而讓我們有更多的精力去關注與自己業(yè)務相關的事情。

?

二、廣告數(shù)據(jù)流

?

聊完題外話，下面正式開始我的分享。首先向大家介紹一下廣告數(shù)據(jù)流。下圖是廣告數(shù)據(jù)流的一個簡化版本，因為我們今天的主題是大數(shù)據(jù)相關的計算，所以我們站在整個數(shù)據(jù)流的角度簡化介紹傳統(tǒng)廣告，如搜索廣告和定向廣告。在圖中可以很清楚的看到，從角色上來說，比較受關注的是廣告主和網(wǎng)民兩個角色。

?

?

廣告主后臺

?

一般來講，廣告主首先會在廣告主后臺進行相關的廣告設置，舉個最簡單的例子，一個廣告主要做一次廣告投放，首先需要設置一些基本信息，如將廣告投給“來自北京”的“男性”，或者當用戶搜索“連衣裙”的時候將廣告投給他（她）。

?

投放引擎

?

廣告主做完設置之后，會用到最重要的一個服務，即投放引擎。它的作用是當廣大網(wǎng)民在百度或淘寶鍵入搜索信息后想其投放相關的廣告。比如淘寶搜索“連衣裙”，結果頁里面顯示的一部分是自然搜索結果，還有一部分是帶有“廣告”圖標的結果，這些結果就是通過投放引擎投放給廣大網(wǎng)民的。

與網(wǎng)民最相關的兩個行為是廣告曝光和廣告點擊。當網(wǎng)民在使用某個平臺進行搜索的時候，比如淘寶，投放引擎里面會用到兩個很關鍵的模塊來決定將什么廣告投放給網(wǎng)民，即索引和算法：

·???????索引構建。當用戶鍵入某個搜索關鍵詞后，如淘寶搜索“連衣裙”，會有上萬條商品滿足該關鍵詞，不可能將所有的商品都投放給用戶。 這個時候的解決方案是首先從廣告庫中查詢有多少廣告買了該商品，這個數(shù)據(jù)需要廣告主在后臺設置，即哪些廣告可以投放給該關鍵詞。

·???????算法模型。假如有一萬個廣告候選集，相關的評分服務會根據(jù)一系列的特征和后臺訓練出來的模型對所有的廣告進行打分排序，最終按照一定的規(guī)則展現(xiàn)給用戶。

?

反作弊

?

上面介紹的是網(wǎng)民看到廣告的過程，相應的在系統(tǒng)后臺會產(chǎn)生一些日志，最典型的是廣告的曝光和點擊日志，會用到反作弊的模塊。因為很多時候網(wǎng)民的行為不一定人操作的，有些是通過API或工具等惡意的手段進行競爭，反作弊模塊的作用就是對這些行為進行判斷并給出相應懲罰決策，如扣費。

?

基礎數(shù)據(jù)

?

經(jīng)過反作弊模塊的數(shù)據(jù)我們認為是可信賴的，會將其存儲在基礎數(shù)據(jù)平臺中，此處的基礎數(shù)據(jù)平臺是一個抽象的概念，最終其實就是MaxCompute。

?

報表/BI

?

有了數(shù)據(jù)之后，最常見的兩個應用場景是做報表/BI分析和模型訓練。

·???????報表/BI分析。主要有兩種情況，一種情況是廣告主在設置了廣告投放之后，想要了解廣告的投放效果，此時會有相應的統(tǒng)計數(shù)據(jù)到廣告主后臺；另一種情況下BI運營的人員也會對這些數(shù)據(jù)進行分析，如某些廣告位的表現(xiàn)情況。

·???????模型訓練。前面已經(jīng)提到，投放引擎第一步只能拿到一個很大的廣告候選集，如何篩選用戶預估分最高的廣告并投放給用戶是模型訓練這個模塊要做的事情。該模塊需要用已經(jīng)存儲的原始基礎數(shù)據(jù)去跑各種各樣的模型，從最傳統(tǒng)的邏輯回歸到現(xiàn)在的深度學習，跑完的數(shù)據(jù)再推送到投放引擎，這個時候就可以實現(xiàn)廣告的在線評分功能。

?

以上是廣告的簡要數(shù)據(jù)流的介紹，接下來分享為什么我們這么久以來一直堅持用MaxCompute?？偨Y一下主要有三點，即數(shù)據(jù)友好、生態(tài)完善持續(xù)改進和性能強悍。

?

1)?????用戶友好。從剛才的數(shù)據(jù)流介紹中，或多或少能看到一點，我們的應用場景有很多，比如反作弊的場景，再比如報表和BI分析的場景，針對此MaxCompute提供各種各樣的計算能力和豐富易用的編程接口。最傳統(tǒng)的是SQL的表達支持，如果SQL表達的語義不滿足要求，加UDF仍然解決不了問題，MaxCompute還支持用戶自己寫一個MapReduce，提供原始數(shù)據(jù)用戶可以自己去加工；還支持用戶做一些圖計算像Deep Learning；另外MaxCompute本身也是支持Batch和Streaming兩種功能，包括之前提到的Spark Streaming；還有一點也是我比較喜歡的，在Hadoop生態(tài)圈中，大家其實更多的看到的是HDFS文件路徑，那在MaxCompute中，我們更多的看到的是一堆一堆的表，表對用戶來講有Schema，比空洞的文件更容易理解一點，針對這些表MaxCompute提供API層面的操作支持，另外也提供相應的Function，包括UDF、UDTF類型的支持；同時MaxCompute還提供半結構化類型的支持，如Volume，支持用戶操作相關的Resource。上述介紹的功能為用戶的開發(fā)提供了便利。

2)?????生態(tài)完善持續(xù)改進。MaxCompute是一個平臺，一個生態(tài)系統(tǒng)。在體驗過MaxCompute整套系統(tǒng)之后，我們發(fā)現(xiàn)其可以應用到我們開發(fā)、運維管理的整個過程中。從最開始數(shù)據(jù)產(chǎn)出之后，如果要加載到MaxCompute平臺中，可以通過“同步工具”來完成；數(shù)據(jù)同步之后，如果想要做數(shù)據(jù)處理，可以通過“DataWorks” 跑一些的簡單的模型來做數(shù)據(jù)分析和處理；復雜的數(shù)據(jù)處理可以通過“算法實驗平臺” 來完成，目前支持TensorFlow上的一些功能；數(shù)據(jù)處理完后，傳統(tǒng)的做法是只看數(shù)據(jù)是否正確，但這對于系統(tǒng)管理人員來講是遠遠不夠的，還需要看結果好不好，是否有優(yōu)化的空間，以保證投入產(chǎn)出比，比如傳統(tǒng)的離線任務，分配資源的方式是基于plan的模式，用戶需要預先預估一個instance需要多少CPU和Memory，但是會存在兩個明顯問題，一個是依靠經(jīng)驗的估計是不準確的，另一個是現(xiàn)在的數(shù)據(jù)量是在不停變化的，無法很好地估計。針對這個需求，“數(shù)據(jù)治理”會給用戶相應的反饋。

3)?????性能強悍。阿里媽媽作為業(yè)界數(shù)字化營銷的廠商來說，數(shù)據(jù)量非常大。目前使用MaxCompute已經(jīng)可以完成EB級別的數(shù)據(jù)存儲；在具體的場景中，可以完成千億級樣本百億級特征的訓練實驗；跑一個MapReduce或SQL的Job，MaxCompute可以實現(xiàn)十萬級實例的并發(fā)調度，后臺遠遠超過十萬實例的并發(fā)度；阿里媽媽一個BU，目前一天之內(nèi)跑在MaxCompute的Job數(shù)已經(jīng)達到十萬級別；最后是我們的報表數(shù)據(jù)，這其實也是最常見的一個場景，目前我們在MaxCompute的報表數(shù)據(jù)已經(jīng)到千億級別。

?

三、幾個典型的應用場景

?

介紹完為什么使用MaxCompute之后，再給大家分享一下阿里媽媽的幾個典型的應用場景中是如何使用MaxCompute的。

?

數(shù)據(jù)分層

?

?

前面介紹了廣告數(shù)據(jù)流，我們針對MaxCompute也對數(shù)據(jù)進行了劃分（如上圖所示），主要劃分為六層 。

1)?????第一層是原始數(shù)據(jù)層，原始數(shù)據(jù)的來源一般有兩個，一個是我們的業(yè)務數(shù)據(jù)庫，比圖MySQL或Hbase,另一個是我們的業(yè)務訪問日志，如剛才提到的廣告的曝光和點擊日志，這些數(shù)據(jù)是放在我們的服務器上面的。

2)?????第二層是ODS層，即通過同步工具同步到MaxCompute平臺的數(shù)據(jù)，與原始數(shù)據(jù)同Schema。原始數(shù)據(jù)要做離線處理的時候（包括Streaming處理），我們內(nèi)部使用同步中心平臺進行全量和增量同步，同時也會使用TimeTunnel進行整個服務器日志的采集。最終同步到MaxCompute平臺的數(shù)據(jù)與原始數(shù)據(jù)是同Schema的，但是它能以天級、小時級、分鐘級實時或準實時的將數(shù)據(jù)同步到離線平臺里面。

3)?????第三層是PDW/DWD。有了同步的數(shù)據(jù)后，大家知道，數(shù)據(jù)的格式是千奇百怪的，以日志為例，我們線上回流的日志是遵循一定的協(xié)議的，想要把數(shù)據(jù)真正用起來還需要經(jīng)過一系列的操作。第一步會進行數(shù)據(jù)清洗，包括上面提到的反作弊也是一種清洗的方式；然后會對數(shù)據(jù)進行簡單的拆解，將其拆解成可以理解的字段。

4)?????第四層是中間層MID/DWB。數(shù)據(jù)量過大的情況之下，比如阿里媽媽一天產(chǎn)出的業(yè)務數(shù)據(jù)高達幾十億，這個數(shù)據(jù)量根本無法實現(xiàn)直接處理分析，所以我們的做法是使用中間層，對DWD數(shù)據(jù)進行上卷、字段篩選和Join，后續(xù)業(yè)務的應用基本上是基于中間層來做的。

5)?????第五層是各種應用場景生成的數(shù)據(jù)層APP/ADS/DWS。具體的場景包括離線報表和BI、全量索引構建、模型訓練，后面會從這三個方面的的場景來具體介紹以下如何使用MaxCompute。

6)?????最后是在線服務和在線數(shù)據(jù)存儲層。

?

報表和BI

?

?

首先介紹一下報表和BI是怎么使用MaxCompute的。對于一般的用戶來說，我們只需要了解兩部分內(nèi)容，包含什么Table，用SQL怎么處理它們。報表和BI具備以下兩個特點：

1)?????二維表和圖表為主。對于廣告主來講，信息的呈現(xiàn)主要通過二維表來完成，通過過濾排序就能看到想要了解的結果；而對于運營人員來講，除了二維表之外，可能還需要一些圖表的具體分析。我們會提供這樣一種能力，這種能力就是，比如想要給廣告主來看的話，提供數(shù)據(jù)導出功能，將數(shù)據(jù)直接導到線上，供廣告主在后臺直接查看效果；其次在部門內(nèi)部發(fā)送支持郵件；再次我們提供類似小站的功能，即個性化門戶站點，后面會通過簡單的demo進行展示。

2)?????高度SQL。上述介紹的所有功能都是高度依賴SQL的，大部分情況下是不需要做一些Java開發(fā)的，也不需要去寫太多的UDF，用戶在報表和BI中只需要去寫SQL，有些甚至只需要拖拽幾下就可以得到想要的結果。

?

下圖是報表和BI使用MaxCompute的demo截圖。用戶輸入簡單SQL表達之后，通過簡單的預處理就能看到想要的數(shù)據(jù)，這個數(shù)據(jù)不僅可以在系統(tǒng)中查看，還可以通過郵件的方式發(fā)送，或者推送的線上進行展示。

?

?

索引構建

?

?

廣告主在后臺更改投放設置之后，一旦數(shù)據(jù)量達到百萬、千萬甚至上億級別的時候，需要針對在線查詢做專有的引擎服務。阿里媽媽廣告搜索引擎索引構建使用MaxCompute如上圖所示，使用的是Lambda架構，支持離線和在線，可以使用Batch和Streaming處理和消費。使用該架構的背景是當時阿里媽媽在做索引更新的時候，每天伴隨著各種各樣的實驗來查看效果，常常會加很多字段，而且這種情況下并行的需求很高，所以我們對系統(tǒng)的要求是必須支持高頻的快速迭代，當時我們定的目標是加一個字段要在半天或者一天之內(nèi)搞定，并將結果推上線，同時要支持多人同時做這個事情，為了實現(xiàn)該需求，我們當時也做了一些類似于組件化的工作。

對于整個索引構建服務，由于時間關系在此只展示業(yè)務層，業(yè)務處理過程中需要面對各種異構數(shù)據(jù)源，圖左側數(shù)據(jù)源層（Data Source Layer），如業(yè)務數(shù)據(jù)（來自MySQL）、算法數(shù)據(jù)和其他外部數(shù)據(jù)，最終將其沉淀到業(yè)務層（Business Layer）引擎的索引中，使其支持各種各樣的查詢。數(shù)據(jù)從數(shù)據(jù)源層到業(yè)務層需要經(jīng)過離線數(shù)據(jù)中心層（Offline DataCenter Layer）,分為上下兩部分，上半部分是批量層（Batch Layer），下半部分是Streaming層（Streaming Layer）。數(shù)據(jù)源的接入方式有兩種，一種是全量的方式，意思是將MaxCompute上面的一張表直接拖拽過來，然后跑一個離線的索引；但是還有一種情況，比如說廣告主做了一次改價，這種更改需要快速地反映到索引中，否則索引中一直存放的是舊信息，將會造成廣告主的投訴，因此除了全量流之外，還提供增量流，以將用戶的更改實施反饋到索引中。

·???????離線部分。我們提供一個類似同步工具的服務，叫做Importer，它是基于MaxCompute來實現(xiàn)的，大部分功能是跑在MaxCompute上的，因為這里面我們進行了組件化，需要進行一系列的類似于數(shù)據(jù)Combine、Merge的操作，還涉及到源數(shù)據(jù)的Schema和數(shù)據(jù)的多版本管理。離線數(shù)據(jù)存入ODPS中，通過Maxcompute的Batch views來查看。

·??????在線部分。簡單來講，比如拿到一條MySQL增量，通過解析將其直接流入消息隊列中，然后通過相應的平臺包括Storm、Spark以及MaxCompute的Streaming等，利用和離線部分類似的組件跑索引。接下來通過Realtime views可以查到最新的數(shù)據(jù)，目前通過tair來實現(xiàn)。實時部分的數(shù)據(jù)每隔一定時間進行Merge，就會形成多版本的數(shù)據(jù)。它的作用有兩個，一個是將這些數(shù)據(jù)直接批量往在線部分去灌，尤其是在線上數(shù)據(jù)出問題、走增量流程很慢的時候；另一個是在做離線索引構建的時候，為了避免索引膨脹的問題，需要定期做一次離線全量，為了保證數(shù)據(jù)實時更新，需要有一條增量流在此期間往全量部分注入數(shù)據(jù)，為了避免因為服務宕機導致的效率低下，我們提供了多個版本增量數(shù)據(jù)的保存。

?

算法實驗

?

?

接下來介紹一下算法實驗使用MaxCompute的場景。不僅僅是算法實驗，包括我們每天往線上推我們的性能模型的時候，都是下圖這套流程。整個流程的輸入是線上日志，比如哪些用戶瀏覽和點擊了哪些廣告，輸出是對用戶的瀏覽和點擊分析后抽取的特征進行在線評分。中間大致可以抽象為六個步驟：

1)?????數(shù)據(jù)處理。數(shù)據(jù)處理除了前面提到的清洗和過濾反作弊之外，做的最簡單的是將多份數(shù)據(jù)合并成一份數(shù)據(jù)，這里面除了用到MapReduce和SQL之外，還用到了ShardJoin，是阿里媽媽和MaxCompute合作，為了應對在離線數(shù)據(jù)進行Join的過程中，兩邊數(shù)據(jù)都特別大時效率低的問題而開發(fā)的。原理很簡單，就是將右表拆成很多小塊，使用獨立RPC服務去查。數(shù)據(jù)處理在整個過程中的時間占比約為20%。

2)?????特征提取。經(jīng)過第一步之后輸出的結果是一整個不加處理的PV表，包含一系列的屬性字段，然后在此基礎上進行特征提取，常用的是跑一個MapReduce，最重要的是有JNI的操作，實現(xiàn)特征提取和特征組合，生成唯一的key。比如我想要把UserId和Price聯(lián)合算出一個新的特征。原始的特征可能只有幾百個，但經(jīng)過交叉、笛卡爾積等操作之后，特征可能會達到幾百億，這個時候前面所提到的MaxCompute支持千億級別樣本、百億級別的計算能力便得到很好地發(fā)揮，這對于調度包括整個計算框架具有極其重要的意義。特征提取在整個過程中的時間占比約為15%。

3)?????樣本生成。一條樣本出來后一般需要設置target和正負例，針對每一個特征會生成一個全局id，最后進行序列化。之所以進行序列化是因為每個計算框架對于輸入樣本會有格式要求，序列化實際上是對輸入樣本進行相應的格式轉換。樣本生成在整個過程中的時間占比約為15%。

4)?????模型訓練。模型訓練的輸入是上一步產(chǎn)生的千億級別的樣本，輸出是每一個特征的權重。比如“男性”這個特征的權重，購買力是一顆星對應的特征的權重。模型訓練在整個過程中的時間占比是40%左右，這個時間和模型復雜度有關，比如說是運行了簡單的邏輯回歸或者復雜的深度學習，時間是不同的。

5)?????模型評估。有了訓練后的模型，接下來要進行評估，使用Auc評估訓練模型的效果。一般在樣本生成的時候會對樣本進行分類，分為訓練樣本和測試樣本，使用測試樣本對訓練好的模型進行評估。模型評估在整個過程中的時間占比是5%。

6)?????模型應用。模型評估達到一定標準之后就可以將訓練好的模型推到線上，這個過程比較復雜，包括數(shù)據(jù)導出、數(shù)據(jù)分發(fā)、加載、切換生成在線打分服務。模型應用在整個過程中的時間占比是5%。

?

以上介紹的六個步驟和MaxCompute最相關的是數(shù)據(jù)處理（20%）、特征提取（15%）、樣本生成（15%）和模型訓練（40%），時間占比百分之九十以上的操作都是在MaxCompute進行的。

?

?

?

為了支撐算法實驗，我們基于MaxCompute搭建了算法實驗框架（如上圖所示）。整個模型訓練不需要開發(fā)太多的代碼，一般來講只需要做兩個方面的改動，傳統(tǒng)的邏輯回歸需要增刪改特征，深度學習中需要更改各種網(wǎng)絡，整個流程是高度一致的。因此我們將這個過程抽象成為Matrix的解決方案。這套解決方案對外來講是運行了一個pipeline，串聯(lián)一系列任務，這些任務最終運行在MaxCompute上面。對外提供Matrix Client，用戶大部分情況下只需要進行配置文件的修改，比如設置特征抽取的方式，知道原表的Schema抽第幾行第幾個字段；抽取的特征怎么做組合，如第一個特征和第二個特征進行叉乘生成新的特征；包括特征選擇方式，如低頻特征進行過濾。框架將上述功能組件化，用戶只需要像拼積木一樣將需要的功能拼接起來，每一個積木進行相應的配置，比如輸入表是什么。樣本輸入模型之前，樣本的格式是固定的，在此基礎上我們實現(xiàn)了調度框架Husky，主要實現(xiàn)pipeline的管理，實現(xiàn)任務的最大化并行執(zhí)行。其他功能由于時間關系在此不多做介紹。

?

四、高級功能和優(yōu)化

?

高級配套能力

?

因為阿里媽媽在MaxCompute上曾經(jīng)的資源使用量占比達到三分之一，從計算到存儲。因此我們根據(jù)自己的經(jīng)驗，接下來分享一下大家有可能用到的MaxCompute的一些高級功能和優(yōu)化。

?

?

MaxCompute提供了我們認為比較重要的四個功能有：

1)?????實時Dashboard和Logview。Logview前面已經(jīng)介紹過了，通過它用戶可以不用再去扒日志，可以很快速地查看任務情況，查找問題原因，另外還提供各種實時診斷的功能。當集群出現(xiàn)問題的時候實時Dashboard可以從從各個維度幫用戶分析當前運行集群的Project或Quta或任務相關信息，其后臺依賴于一系列的源數(shù)據(jù)管理。當然，MaxCompute能提供的功能遠不止實時Dashboard和Logview，但是這兩個功能在個人、集群管理過程是被高度依賴的。

2)?????強大的調度策略。主要有三種：

·???????第一種是交互式搶占。傳統(tǒng)的搶占方式比較粗暴，當用戶提交一個任務的時候，比如分Quta，無論是Hadoop還是MaxCompute，都會分析是minQuta還是maxQuta，這種情況下一定會涉及到共享與資源搶占的問題。如果不搶占，一個任務會跑很長時間；如果直接將任務停掉，已經(jīng)運行起來的任務可能需要重新再運行，導致效率低下。交互式搶占比較好地解決了這個問題，其提供了一種協(xié)議，這個協(xié)議需要和各個框架之間達成，比如說要kill掉某個任務之前，會在一定時間之前發(fā)送kill的命令，并給予任務指定的運行時間，如果這個時間結束之后仍然運行不完，則kill掉。

·???????第二種是全局調度。阿里云的機器已經(jīng)達到了萬級，當某個集群的任務跑的很卡的時候，如果發(fā)現(xiàn)其他集群比較空閑，全局調度策略便可以發(fā)揮作用，將任務分配到較為空閑的集群上運行，這種調度過程對于用戶來講是透明的，用戶只能直觀地感受任務的運行速度發(fā)生變化。

·???????第三種是兼顧All-or-nothing和Increment的資源分配方式。簡單來講，比如前者跑了圖計算的訓練模型，后者跑了SQL，這兩種計算的資源分配方式有很大不同。對于SQL來講，如果需要一千個實例來運行mapper，不用等到一千個實例攢夠了再去運行，可以拿到一個實例運行一個mapper,因為這種計算實例之間沒有信息交互；但是模型訓練是一輪一輪進行迭代的，第一輪迭代運行完之后才能開始運行第二輪迭代，因此注定需要所有的資源準備好了之后才能運行，因此阿里云的調度人員在后臺做了很多兼顧這兩方面資源分配的工作。

3)?????數(shù)據(jù)地圖。幫助的用戶描述數(shù)據(jù)、任務之間的關系，方便用戶后續(xù)業(yè)務的處理。

4)?????數(shù)據(jù)治理。任務運行結束對于集群或者任務管理人員來講并沒有結束，還需要去看任務跑得好不好，這個時候服務治理就可以提供很多優(yōu)化建議，比如某個數(shù)據(jù)跑到最后沒有人用，那與其相關的鏈路是否可以取消，這種治理不管對于內(nèi)部系統(tǒng)還是外部系統(tǒng)來講可以節(jié)省很多的資源開銷。

?

計算優(yōu)化

?

?

?

接下來就上面介紹的數(shù)據(jù)治理向大家分享一下我們的經(jīng)驗。在數(shù)據(jù)治理計算優(yōu)化方面，我們主要的用到了MaxCompute的以下四個功能：

1)?????無用/相似任務分析。這個很容易理解，它可以幫助用戶分析出哪些任務是沒有用的，哪些任務是相似的，這需要依托于數(shù)據(jù)地圖的強大關系梳理能力分析出任務的有效性。

2)?????HBO?(History-based optimization) +?CBO?(Cost-based optimization)。它其實解決的是優(yōu)化的問題，在跑計算任務的時候，不管使用的是SQL還是MapReduce，一定會預先設定CPU和Memory的值，但是預先設定往往是不準確的。解決的方式有兩種，一種是先將任務運行一段時間，根據(jù)運行情況計算每個實例大概需要的CPU和Memory，這種方式就是History-based optimization；而第二種方式是Cost-based optimization，解決的是基于成本的優(yōu)化，時間關系在此不多做介紹，后期如果大家感興趣的話，會組織相關的高階分享。

3)?????列裁剪。它解決的問題是不用講整個表中的所有字段都列出來，比如Select *，根據(jù)SQL語義，它可以實現(xiàn)十個字段只需要加載前五個字段。這對于整個任務的執(zhí)行效率包括整個磁盤的IO有很大益處。

4)?????Service? Mode。傳統(tǒng)運行MapReduce的時候，會有shuffle的過程，這個過程會涉及到數(shù)據(jù)在Mapper和Reducer端的落盤，這個落盤操作是很耗時間的，對于一些中小型任務來講（可能只需要兩三分鐘就運行完），是不需要落盤操作的。MaxCompute會預判任務的執(zhí)行時間，短小任務通過Service Mode的方式來降低任務的運行時間。

?

存儲優(yōu)化

?

MaxCompute除了計算優(yōu)化，還有存儲方面的優(yōu)化。存儲優(yōu)化主要體現(xiàn)在以下一個方面：

1)?????無用數(shù)據(jù)分析和下線。這個前面也已經(jīng)反復介紹過了，可以幫助用戶分析無用的數(shù)據(jù)并下線，和無用Job分析是類似的原理。這里的難點是“最后一公里”，即數(shù)據(jù)從離線平臺產(chǎn)出之后導到線上，最后這一公里的元素是很難去追蹤的，這依賴于工具和平臺高度的標準化，阿里內(nèi)部的好處是這一塊已經(jīng)做到了標準化。隨著后續(xù)阿里云暴露的服務越來越多，這個難點將有希望被攻克，能夠幫用戶分析出來哪些數(shù)據(jù)是真的沒有人用。

2)?????生命周期的優(yōu)化。一份表到底要保存多少時間一開始是依靠人去估計和設置的，比如一年，但根據(jù)實際的訪問情況你會發(fā)現(xiàn)，保存一天或者三天就可以。這個時候依托于MaxCompute的數(shù)據(jù)治理，會幫助用戶分析出某張表適合的保存時間，這對于存儲的優(yōu)化具有極其重要的意義。

3)?????Archive。數(shù)據(jù)是有冷熱之分的，尤其是分布式文件存儲的時候，都是通過雙備份的方式來存儲數(shù)據(jù)，當然雙備份尤其意義在，比如可以讓你的數(shù)據(jù)更加可靠、不會丟失，但這樣帶來了一個問題是數(shù)據(jù)的存儲將會變得大。MaxCompute提供了冷數(shù)據(jù)策略，不做雙備份，通過一定的策略將數(shù)據(jù)變成1.5備份，用1.5倍的空間達到雙備份的效果。

4)?????Hash Clustering。這個屬于存儲和計算優(yōu)化中和的事情。每次在做MapReduce的時候，中間可能需要做Join操作， 每次Join操作的時候可能會對某個表做Sort操作，但是Sort操作沒必要每次都去做，這樣就可以針對Sort操作提前做一些存儲上的優(yōu)化。

?

下圖展示了的阿里媽媽預估的ODPS存儲消耗趨勢，可以很明顯的看到預期消耗隨著時間推移幾乎呈直線增長，但中間使用MaxCompute做了幾次優(yōu)化之后，明顯感覺存儲消耗增長趨勢減緩。

?

?

介紹這么多優(yōu)化的功能，最終目的是希望大家對MaxCompute有更多的了解和期待，大家如果有更多的需求可以向MaxCompute平臺提出。

?

如需了解更多關于MaxCompute產(chǎn)品和技術信息，可加入“MaxCompute開發(fā)者交流”釘釘群；

群號11782920，或掃描如下二維碼加入釘釘群。

本文為阿里云原創(chuàng)內(nèi)容，未經(jīng)允許不得轉載。

云棲號 - 上云就看云棲號

總結

以上是生活随笔為你收集整理的阿里妈妈数据字化营销与MaxCompute的不解之缘的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。