作者：梁時木 ( 載思 ) 阿裡集團 阿裡媽媽事業群 技術專家
摘要： 大資料計算服務（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平台提出。