摘要： 大數據計算服務（MaxCompute）是一種快速、完全託管的 GB/TB/PB 級數據倉庫解決方案，目前已在阿里巴巴內部得到大規模應用。來自阿里媽媽基礎平臺大規模數據處理技術專家向大家分享了MaxCompute在阿里媽媽數據字化營銷解決方案上的典型應用經驗。首先介紹了廣告數據流，分析了MaxCompute 是如何解決廣告的問題；然後通過阿里媽媽內部的應用經典場景來介紹其如何使用MaxCompute；最後介紹了MaxCompute提供的高級配套能力以及在計算和存儲方面的優化。
演講嘉賓簡介：
樑時木(載思)，阿里媽媽基礎平臺大規模數據處理技術專家。
以下內容根據演講嘉賓視頻分享以及PPT整理而成。
本次的分享主要分為兩部分：
一、 題外話：該部分主要介紹在聽完之前的分享後，嘉賓的幾點個人感受 。
二、廣告數據流介紹： 該部分主要是對沒有中間商賺差價的廣告數據流的基本介紹以及為什麼MaxCompute能解決廣告的問題。
三、典型應用場景：該部分主要通過阿里媽媽內部的應用經典場景來介紹其如何使用MaxCompute，包括數據分層體系、報表和BI、搜索引擎索引構建和算法實驗。
四、高級功能和優化：該部分主要就阿里媽媽在五六年的MaxCompute內部使用和管理過程中的相關高級功能和優化進行公開分享，包括MaxCompute提供的高級配套能力以及在計算和存儲方面的優化。
一、題外話
開始之前先聊一點題外話，是我在聽完剛才的分享之後的幾點感受。其實我從2013年就開始在內部項目中使用MaxCompute,阿里媽媽作為第一批登月用戶，踩了很多坑。聽了剛才的分享，我的第一感受是，MaxCompute有好多功能我們都沒有關注過，作為一個資深用戶，很多功能都不知道聽起來好像有點不太合格，但轉念一想這可能是MaxCompute作為一個平臺、一個生態解決方案應該具備的一種能力。就是說它讓一個終端用戶只需要看到你所關注的東西，有一些你不太關注的，而對於整個生態鏈上又必須有的東西它可能潛移默化的幫你做了，在我看來這其實是一種很強的能力。在聽完分享後的另一個感受就是我還是蠻慶幸在阿里這邊做這些事情的，一些中小公司在基礎設施服務這塊很需要一些第三方平臺的支持，因為你會發現它們如果從頭搭建的話，成本會特別高，而MaxCompute、阿里包括釘釘這樣的產品，撇開商業化這個因素，它們更多的其實是幫助我們推動互聯網技術的進步，幫助我們做一些基礎上的事情，從而讓我們有更多的精力去關注與自己業務相關的事情。
二、廣告數據流
聊完題外話，下面正式開始我的分享。首先向大家介紹一下廣告數據流。下圖是廣告數據流的一個簡化版本，因為我們今天的主題是大數據相關的計算，所以我們站在整個數據流的角度簡化介紹傳統廣告，如搜索廣告和定向廣告。在圖中可以很清楚的看到，從角色上來說，比較受關注的是廣告主和網民兩個角色。
廣告主後臺
一般來講，廣告主首先會在廣告主後臺進行相關的廣告設置，舉個最簡單的例子，一個廣告主要做一次廣告投放，首先需要設置一些基本信息，如將廣告投給“來自北京”的“男性”，或者當用戶搜索“連衣裙”的時候將廣告投給他（她）。
投放引擎
廣告主做完設置之後，會用到最重要的一個服務，即投放引擎。它的作用是當廣大網民在百度或淘寶鍵入搜索信息後想其投放相關的廣告。比如淘寶搜索“連衣裙”，結果頁裡面顯示的一部分是自然搜索結果，還有一部分是帶有“廣告”圖標的結果，這些結果就是通過投放引擎投放給廣大網民的。
與網民最相關的兩個行為是廣告曝光和廣告點擊。當網民在使用某個平臺進行搜索的時候，比如淘寶，投放引擎裡面會用到兩個很關鍵的模塊來決定將什麼廣告投放給網民，即索引和算法：
· 索引構建。當用戶鍵入某個搜索關鍵詞後，如淘寶搜索“連衣裙”，會有上萬條商品滿足該關鍵詞，不可能將所有的商品都投放給用戶。 這個時候的解決方案是首先從廣告庫中查詢有多少廣告買了該商品，這個數據需要廣告主在後臺設置，即哪些廣告可以投放給該關鍵詞。
· 算法模型。假如有一萬個廣告候選集，相關的評分服務會根據一系列的特徵和後臺訓練出來的模型對所有的廣告進行打分排序，最終按照一定的規則展現給用戶。
反作弊
上面介紹的是網民看到廣告的過程，相應的在系統後臺會產生一些日誌，最典型的是廣告的曝光和點擊日誌，會用到反作弊的模塊。因為很多時候網民的行為不一定人操作的，有些是通過API或工具等惡意的手段進行競爭，反作弊模塊的作用就是對這些行為進行判斷並給出相應懲罰決策，如扣費。
基礎數據
經過反作弊模塊的數據我們認為是可信賴的，會將其存儲在基礎數據平臺中，此處的基礎數據平臺是一個抽象的概念，最終其實就是MaxCompute。
報表/BI
有了數據之後，最常見的兩個應用場景是做報表/BI分析和模型訓練。
· 報表/BI分析。主要有兩種情況，一種情況是廣告主在設置了廣告投放之後，想要了解廣告的投放效果，此時會有相應的統計數據到廣告主後臺；另一種情況下BI運營的人員也會對這些數據進行分析，如某些廣告位的表現情況。
· 模型訓練。前面已經提到，投放引擎第一步只能拿到一個很大的廣告候選集，如何篩選用戶預估分最高的廣告並投放給用戶是模型訓練這個模塊要做的事情。該模塊需要用已經存儲的原始基礎數據去跑各種各樣的模型，從最傳統的邏輯迴歸到現在的深度學習，跑完的數據再推送到投放引擎，這個時候就可以實現廣告的在線評分功能。
以上是廣告的簡要數據流的介紹，接下來分享為什麼我們這麼久以來一直堅持用MaxCompute。總結一下主要有三點，即數據友好、生態完善持續改進和性能強悍。
1) 用戶友好。從剛才的數據流介紹中，或多或少能看到一點，我們的應用場景有很多，比如反作弊的場景，再比如報表和BI分析的場景，針對此MaxCompute提供各種各樣的計算能力和豐富易用的編程接口。最傳統的是SQL的表達支持，如果SQL表達的語義不滿足要求，加UDF仍然解決不了問題，MaxCompute還支持用戶自己寫一個MapReduce，提供原始數據用戶可以自己去加工；還支持用戶做一些圖計算像Deep Learning；另外MaxCompute本身也是支持Batch和Streaming兩種功能，包括之前提到的Spark Streaming；還有一點也是我比較喜歡的，在Hadoop生態圈中，大家其實更多的看到的是HDFS文件路徑，那在MaxCompute中，我們更多的看到的是一堆一堆的表，表對用戶來講有Schema，比空洞的文件更容易理解一點，針對這些表MaxCompute提供API層面的操作支持，另外也提供相應的Function，包括UDF、UDTF類型的支持；同時MaxCompute還提供半結構化類型的支持，如Volume，支持用戶操作相關的Resource。上述介紹的功能為用戶的開發提供了便利。
2) 生態完善持續改進。MaxCompute是一個平臺，一個生態系統。在體驗過MaxCompute整套系統之後，我們發現其可以應用到我們開發、運維管理的整個過程中。從最開始數據產出之後，如果要加載到MaxCompute平臺中，可以通過“同步工具”來完成；數據同步之後，如果想要做數據處理，可以通過“DataWorks” 跑一些的簡單的模型來做數據分析和處理；複雜的數據處理可以通過“算法實驗平臺” 來完成，目前支持TensorFlow上的一些功能；數據處理完後，傳統的做法是隻看數據是否正確，但這對於系統管理人員來講是遠遠不夠的，還需要看結果好不好，是否有優化的空間，以保證投入產出比，比如傳統的離線任務，分配資源的方式是基於plan的模式，用戶需要預先預估一個instance需要多少CPU和Memory，但是會存在兩個明顯問題，一個是依靠經驗的估計是不準確的，另一個是現在的數據量是在不停變化的，無法很好地估計。針對這個需求，“數據治理”會給用戶相應的反饋。
3) 性能強悍。阿里媽媽作為業界數字化營銷的廠商來說，數據量非常大。目前使用MaxCompute已經可以完成EB級別的數據存儲；在具體的場景中，可以完成千億級樣本百億級特徵的訓練實驗；跑一個MapReduce或SQL的Job，MaxCompute可以實現十萬級實例的併發調度，後臺遠遠超過十萬實例的併發度；阿里媽媽一個BU，目前一天之內跑在MaxCompute的Job數已經達到十萬級別；最後是我們的報表數據，這其實也是最常見的一個場景，目前我們在MaxCompute的報表數據已經到千億級別。
三、幾個典型的應用場景
介紹完為什麼使用MaxCompute之後，再給大家分享一下阿里媽媽的幾個典型的應用場景中是如何使用MaxCompute的。
數據分層
前面介紹了廣告數據流，我們針對MaxCompute也對數據進行了劃分（如上圖所示），主要劃分為六層 。
1) 第一層是原始數據層，原始數據的來源一般有兩個，一個是我們的業務數據庫，比圖MySQL或Hbase,另一個是我們的業務訪問日誌，如剛才提到的廣告的曝光和點擊日誌，這些數據是放在我們的服務器上面的。
2) 第二層是ODS層，即通過同步工具同步到MaxCompute平臺的數據，與原始數據同Schema。原始數據要做離線處理的時候（包括Streaming處理），我們內部使用同步中心平臺進行全量和增量同步，同時也會使用TimeTunnel進行整個服務器日誌的採集。最終同步到MaxCompute平臺的數據與原始數據是同Schema的，但是它能以天級、小時級、分鐘級實時或準實時的將數據同步到離線平臺裡面。
3) 第三層是PDW/DWD。有了同步的數據後，大家知道，數據的格式是千奇百怪的，以日誌為例，我們線上迴流的日誌是遵循一定的協議的，想要把數據真正用起來還需要經過一系列的操作。第一步會進行數據清洗，包括上面提到的反作弊也是一種清洗的方式；然後會對數據進行簡單的拆解，將其拆解成可以理解的字段。
4) 第四層是中間層MID/DWB。數據量過大的情況之下，比如阿里媽媽一天產出的業務數據高達幾十億，這個數據量根本無法實現直接處理分析，所以我們的做法是使用中間層，對DWD數據進行上卷、字段篩選和Join，後續業務的應用基本上是基於中間層來做的。
5) 第五層是各種應用場景生成的數據層APP/ADS/DWS。具體的場景包括離線報表和BI、全量索引構建、模型訓練，後面會從這三個方面的的場景來具體介紹以下如何使用MaxCompute。
6) 最後是在線服務和在線數據存儲層。
報表和BI
首先介紹一下報表和BI是怎麼使用MaxCompute的。對於一般的用戶來說，我們只需要瞭解兩部分內容，包含什麼Table，用SQL怎麼處理它們。報表和BI具備以下兩個特點：
1) 二維表和圖表為主。對於廣告主來講，信息的呈現主要通過二維表來完成，通過過濾排序就能看到想要了解的結果；而對於運營人員來講，除了二維表之外，可能還需要一些圖表的具體分析。我們會提供這樣一種能力，這種能力就是，比如想要給廣告主來看的話，提供數據導出功能，將數據直接導到線上，供廣告主在後臺直接查看效果；其次在部門內部發送支持郵件；再次我們提供類似小站的功能，即個性化門戶站點，後面會通過簡單的demo進行展示。
2) 高度SQL。上述介紹的所有功能都是高度依賴SQL的，大部分情況下是不需要做一些Java開發的，也不需要去寫太多的UDF，用戶在報表和BI中只需要去寫SQL，有些甚至只需要拖拽幾下就可以得到想要的結果。
下圖是報表和BI使用MaxCompute的demo截圖。用戶輸入簡單SQL表達之後，通過簡單的預處理就能看到想要的數據，這個數據不僅可以在系統中查看，還可以通過郵件的方式發送，或者推送的線上進行展示。
索引構建
廣告主在後臺更改投放設置之後，一旦數據量達到百萬、千萬甚至上億級別的時候，需要針對在線查詢做專有的引擎服務。阿里媽媽廣告搜索引擎索引構建使用MaxCompute如上圖所示，使用的是Lambda架構，支持離線和在線，可以使用Batch和Streaming處理和消費。使用該架構的背景是當時阿里媽媽在做索引更新的時候，每天伴隨著各種各樣的實驗來查看效果，常常會加很多字段，而且這種情況下並行的需求很高，所以我們對系統的要求是必須支持高頻的快速迭代，當時我們定的目標是加一個字段要在半天或者一天之內搞定，並將結果推上線，同時要支持多人同時做這個事情，為了實現該需求，我們當時也做了一些類似於組件化的工作。
對於整個索引構建服務，由於時間關係在此只展示業務層，業務處理過程中需要面對各種異構數據源，圖左側數據源層（Data Source Layer），如業務數據（來自MySQL）、算法數據和其他外部數據，最終將其沉澱到業務層（Business Layer）引擎的索引中，使其支持各種各樣的查詢。數據從數據源層到業務層需要經過離線數據中心層（Offline DataCenter Layer）,分為上下兩部分，上半部分是批量層（Batch Layer），下半部分是Streaming層（Streaming Layer）。數據源的接入方式有兩種，一種是全量的方式，意思是將MaxCompute上面的一張表直接拖拽過來，然後跑一個離線的索引；但是還有一種情況，比如說廣告主做了一次改價，這種更改需要快速地反映到索引中，否則索引中一直存放的是舊信息，將會造成廣告主的投訴，因此除了全量流之外，還提供增量流，以將用戶的更改實施反饋到索引中。
· 離線部分。我們提供一個類似同步工具的服務，叫做Importer，它是基於MaxCompute來實現的，大部分功能是跑在MaxCompute上的，因為這裡面我們進行了組件化，需要進行一系列的類似於數據Combine、Merge的操作，還涉及到源數據的Schema和數據的多版本管理。離線數據存入ODPS中，通過Maxcompute的Batch views來查看。
· 在線部分。簡單來講，比如拿到一條MySQL增量，通過解析將其直接流入消息隊列中，然後通過相應的平臺包括Storm、Spark以及MaxCompute的Streaming等，利用和離線部分類似的組件跑索引。接下來通過Realtime views可以查到最新的數據，目前通過tair來實現。實時部分的數據每隔一定時間進行Merge，就會形成多版本的數據。它的作用有兩個，一個是將這些數據直接批量往在線部分去灌，尤其是在線上數據出問題、走增量流程很慢的時候；另一個是在做離線索引構建的時候，為了避免索引膨脹的問題，需要定期做一次離線全量，為了保證數據實時更新，需要有一條增量流在此期間往全量部分注入數據，為了避免因為服務宕機導致的效率低下，我們提供了多個版本增量數據的保存。
算法實驗
接下來介紹一下算法實驗使用MaxCompute的場景。不僅僅是算法實驗，包括我們每天往線上推我們的性能模型的時候，都是下圖這套流程。整個流程的輸入是線上日誌，比如哪些用戶瀏覽和點擊了哪些廣告，輸出是對用戶的瀏覽和點擊分析後抽取的特徵進行在線評分。中間大致可以抽象為六個步驟：
1) 數據處理。數據處理除了前面提到的清洗和過濾反作弊之外，做的最簡單的是將多份數據合併成一份數據，這裡面除了用到MapReduce和SQL之外，還用到了ShardJoin，是阿里媽媽和MaxCompute合作，為了應對在離線數據進行Join的過程中，兩邊數據都特別大時效率低的問題而開發的。原理很簡單，就是將右表拆成很多小塊，使用獨立RPC服務去查。數據處理在整個過程中的時間佔比約為20%。
2) 特徵提取。經過第一步之後輸出的結果是一整個不加處理的PV表，包含一系列的屬性字段，然後在此基礎上進行特徵提取，常用的是跑一個MapReduce，最重要的是有JNI的操作，實現特徵提取和特徵組合，生成唯一的key。比如我想要把UserId和Price聯合算出一個新的特徵。原始的特徵可能只有幾百個，但經過交叉、笛卡爾積等操作之後，特徵可能會達到幾百億，這個時候前面所提到的MaxCompute支持千億級別樣本、百億級別的計算能力便得到很好地發揮，這對於調度包括整個計算框架具有極其重要的意義。特徵提取在整個過程中的時間佔比約為15%。
3) 樣本生成。一條樣本出來後一般需要設置target和正負例，針對每一個特徵會生成一個全局id，最後進行序列化。之所以進行序列化是因為每個計算框架對於輸入樣本會有格式要求，序列化實際上是對輸入樣本進行相應的格式轉換。樣本生成在整個過程中的時間佔比約為15%。
4) 模型訓練。模型訓練的輸入是上一步產生的千億級別的樣本，輸出是每一個特徵的權重。比如“男性”這個特徵的權重，購買力是一顆星對應的特徵的權重。模型訓練在整個過程中的時間佔比是40%左右，這個時間和模型複雜度有關，比如說是運行了簡單的邏輯迴歸或者複雜的深度學習，時間是不同的。
5) 模型評估。有了訓練後的模型，接下來要進行評估，使用Auc評估訓練模型的效果。一般在樣本生成的時候會對樣本進行分類，分為訓練樣本和測試樣本，使用測試樣本對訓練好的模型進行評估。模型評估在整個過程中的時間佔比是5%。
6) 模型應用。模型評估達到一定標準之後就可以將訓練好的模型推到線上，這個過程比較複雜，包括數據導出、數據分發、加載、切換生成在線打分服務。模型應用在整個過程中的時間佔比是5%。
以上介紹的六個步驟和MaxCompute最相關的是數據處理（20%）、特徵提取（15%）、樣本生成（15%）和模型訓練（40%），時間佔比百分之九十以上的操作都是在MaxCompute進行的。
為了支撐算法實驗，我們基於MaxCompute搭建了算法實驗框架（如上圖所示）。整個模型訓練不需要開發太多的代碼，一般來講只需要做兩個方面的改動，傳統的邏輯迴歸需要增刪改特徵，深度學習中需要更改各種網絡，整個流程是高度一致的。因此我們將這個過程抽象成為Matrix的解決方案。這套解決方案對外來講是運行了一個pipeline，串聯一系列任務，這些任務最終運行在MaxCompute上面。對外提供Matrix Client，用戶大部分情況下只需要進行配置文件的修改，比如設置特徵抽取的方式，知道原表的Schema抽第幾行第幾個字段；抽取的特徵怎麼做組合，如第一個特徵和第二個特徵進行叉乘生成新的特徵；包括特徵選擇方式，如低頻特徵進行過濾。框架將上述功能組件化，用戶只需要像拼積木一樣將需要的功能拼接起來，每一個積木進行相應的配置，比如輸入表是什麼。樣本輸入模型之前，樣本的格式是固定的，在此基礎上我們實現了調度框架Husky，主要實現pipeline的管理，實現任務的最大化並行執行。其他功能由於時間關係在此不多做介紹。
四、高級功能和優化
高級配套能力
因為阿里媽媽在MaxCompute上曾經的資源使用量佔比達到三分之一，從計算到存儲。因此我們根據自己的經驗，接下來分享一下大家有可能用到的MaxCompute的一些高級功能和優化。
MaxCompute提供了我們認為比較重要的四個功能有：
1) 實時Dashboard和Logview。Logview前面已經介紹過了，通過它用戶可以不用再去扒日誌，可以很快速地查看任務情況，查找問題原因，另外還提供各種實時診斷的功能。當集群出現問題的時候實時Dashboard可以從從各個維度幫用戶分析當前運行集群的Project或Quta或任務相關信息，其後臺依賴於一系列的源數據管理。當然，MaxCompute能提供的功能遠不止實時Dashboard和Logview，但是這兩個功能在個人、集群管理過程是被高度依賴的。
2) 強大的調度策略。主要有三種：
· 第一種是交互式搶佔。傳統的搶佔方式比較粗暴，當用戶提交一個任務的時候，比如分Quta，無論是Hadoop還是MaxCompute，都會分析是minQuta還是maxQuta，這種情況下一定會涉及到共享與資源搶佔的問題。如果不搶佔，一個任務會跑很長時間；如果直接將任務停掉，已經運行起來的任務可能需要重新再運行，導致效率低下。交互式搶佔比較好地解決了這個問題，其提供了一種協議，這個協議需要和各個框架之間達成，比如說要kill掉某個任務之前，會在一定時間之前發送kill的命令，並給予任務指定的運行時間，如果這個時間結束之後仍然運行不完，則kill掉。
· 第二種是全局調度。阿里雲的機器已經達到了萬級，當某個集群的任務跑的很卡的時候，如果發現其他集群比較空閒，全局調度策略便可以發揮作用，將任務分配到較為空閒的集群上運行，這種調度過程對於用戶來講是透明的，用戶只能直觀地感受任務的運行速度發生變化。
· 第三種是兼顧All-or-nothing和Increment的資源分配方式。簡單來講，比如前者跑了圖計算的訓練模型，後者跑了SQL，這兩種計算的資源分配方式有很大不同。對於SQL來講，如果需要一千個實例來運行mapper，不用等到一千個實例攢夠了再去運行，可以拿到一個實例運行一個mapper,因為這種計算實例之間沒有信息交互；但是模型訓練是一輪一輪進行迭代的，第一輪迭代運行完之後才能開始運行第二輪迭代，因此註定需要所有的資源準備好了之後才能運行，因此阿里雲的調度人員在後臺做了很多兼顧這兩方面資源分配的工作。
3) 數據地圖。幫助的用戶描述數據、任務之間的關係，方便用戶後續業務的處理。
4) 數據治理。任務運行結束對於集群或者任務管理人員來講並沒有結束，還需要去看任務跑得好不好，這個時候服務治理就可以提供很多優化建議，比如某個數據跑到最後沒有人用，那與其相關的鏈路是否可以取消，這種治理不管對於內部系統還是外部系統來講可以節省很多的資源開銷。
計算優化
接下來就上面介紹的數據治理向大家分享一下我們的經驗。在數據治理計算優化方面，我們主要的用到了MaxCompute的以下四個功能：
1) 無用/相似任務分析。這個很容易理解，它可以幫助用戶分析出哪些任務是沒有用的，哪些任務是相似的，這需要依託於數據地圖的強大關係梳理能力分析出任務的有效性。
2) HBO (History-based optimization) + CBO (Cost-based optimization)。它其實解決的是優化的問題，在跑計算任務的時候，不管使用的是SQL還是MapReduce，一定會預先設定CPU和Memory的值，但是預先設定往往是不準確的。解決的方式有兩種，一種是先將任務運行一段時間，根據運行情況計算每個實例大概需要的CPU和Memory，這種方式就是History-based optimization；而第二種方式是Cost-based optimization，解決的是基於成本的優化，時間關係在此不多做介紹，後期如果大家感興趣的話，會組織相關的高階分享。
3) 列裁剪。它解決的問題是不用講整個表中的所有字段都列出來，比如Select *，根據SQL語義，它可以實現十個字段只需要加載前五個字段。這對於整個任務的執行效率包括整個磁盤的IO有很大益處。
4) Service Mode。傳統運行MapReduce的時候，會有shuffle的過程，這個過程會涉及到數據在Mapper和Reducer端的落盤，這個落盤操作是很耗時間的，對於一些中小型任務來講（可能只需要兩三分鐘就運行完），是不需要落盤操作的。MaxCompute會預判任務的執行時間，短小任務通過Service Mode的方式來降低任務的運行時間。
存儲優化
MaxCompute除了計算優化，還有存儲方面的優化。存儲優化主要體現在以下一個方面：
1) 無用數據分析和下線。這個前面也已經反覆介紹過了，可以幫助用戶分析無用的數據並下線，和無用Job分析是類似的原理。這裡的難點是“最後一公里”，即數據從離線平臺產出之後導到線上，最後這一公里的元素是很難去追蹤的，這依賴於工具和平臺高度的標準化，阿里內部的好處是這一塊已經做到了標準化。隨著後續阿里雲暴露的服務越來越多，這個難點將有希望被攻克，能夠幫用戶分析出來哪些數據是真的沒有人用。
2) 生命週期的優化。一份表到底要保存多少時間一開始是依靠人去估計和設置的，比如一年，但根據實際的訪問情況你會發現，保存一天或者三天就可以。這個時候依託於MaxCompute的數據治理，會幫助用戶分析出某張表適合的保存時間，這對於存儲的優化具有極其重要的意義。
3) Archive。數據是有冷熱之分的，尤其是分佈式文件存儲的時候，都是通過雙備份的方式來存儲數據，當然雙備份尤其意義在，比如可以讓你的數據更加可靠、不會丟失，但這樣帶來了一個問題是數據的存儲將會變得大。MaxCompute提供了冷數據策略，不做雙備份，通過一定的策略將數據變成1.5備份，用1.5倍的空間達到雙備份的效果。
4) Hash Clustering。這個屬於存儲和計算優化中和的事情。每次在做MapReduce的時候，中間可能需要做Join操作， 每次Join操作的時候可能會對某個表做Sort操作，但是Sort操作沒必要每次都去做，這樣就可以針對Sort操作提前做一些存儲上的優化。
下圖展示了的阿里媽媽預估的ODPS存儲消耗趨勢，可以很明顯的看到預期消耗隨著時間推移幾乎呈直線增長，但中間使用MaxCompute做了幾次優化之後，明顯感覺存儲消耗增長趨勢減緩。
介紹這麼多優化的功能，最終目的是希望大家對MaxCompute有更多的瞭解和期待，大家如果有更多的需求可以向MaxCompute平臺提出。