一、MaxCompute資源規劃背景介紹
MaxCompute資源主要有兩類：存儲資源、計算資源(包含cpu和記憶體)。存儲資源用于存儲MaxCompute的庫表資料，計算資源用于運作sql、mr等任務。最佳的MaxCompute資源規劃方案能夠達到以下幾個目的：
• 資料存儲資源足夠，既能夠存儲目前的所有存量庫表資料，也能夠存儲未來一段時間的增量資料；
• 計算資源充足，但是不能浪費。計算資源量能夠滿足所有資料計算任務，且盡可能減少資源浪費情況。這樣耗費的資源費用最少；
• 被處理的資料量巨大、耗費計算資源較多的大型任務，可能會将quota group資源組耗盡，造成其他任務無法擷取到計算資源而阻塞。MaxCompute資源規劃方案必須能夠盡量避免這種情況；
• 不同優先級的計算任務能夠盡量互不幹擾，有限保證高優先級的任務擷取到足夠計算資源；
• 能夠滿足時段的差異化資源需求，滿足對資源隔離（生産/開發/自助分析）不同工作負載的能力，避免互相幹擾，同時更大化提高資源使用率。
MaxCompute資源規劃的最終目标就是能夠滿足上述幾點需求，企業客戶消耗最低資源費用的情況下，滿足資料存儲需求，以及資料處理任務對計算資源的需求。
本文内容主要基于阿裡公有雲MaxCompute環境。公有雲和專有雲環境的MaxCompute資源規劃有比較大的差異，比如：在公有雲環境，存儲資源和計算資源是使用整個阿裡雲區域的資源池，幾乎不用擔心底層到底有多少台伺服器進行支撐，可以近乎認為公有雲底層的資源池是無限的；但是在專有雲環境，整個專有雲都是企業客戶獨享的資源，必須根據存儲資源和計算資源量規劃伺服器數量&&伺服器規格。本文主要探讨公有雲MaxCompute的資源規劃。
二、MaxCompute存儲資源規劃
2.1 計存比
在介紹存儲方案選擇之前，先說一個常用的概念：“計存比”。計存比就是計算CU數量和實際存儲數量TB的比值。比如資源配置設定：50CU計算資源，存儲資料量是10TB。那麼，50CU/10TB=5，計存比=5。
2.2 存儲資源規劃建議
對于存儲資源，MaxCompute提供兩種計費方式：
• 按量付費：MaxCompute以小時級别采集每個項目空間下目前的存儲，并以 project 項目空間為基本機關，計算項目空間當天的存儲平均值。然後再乘以單價(元/GB/天)，最後的得到每天的存儲費用。
• 套餐資源：MaxCompute包年包月套餐包含預留的計算資源和存儲資源，每種套餐固定計算資源CU量和存儲資源。套餐中的存儲資源是指每天固定的存儲資源，超過的部分另外按量計費。套餐資源目前隻支援固定的幾個套餐，見下圖所示：
阿裡雲提供的第二種方案，三種套餐的計存比是固定的，而且計存比都在1左右。這種固定資源套餐的計存比偏低，适合存儲量大、計算任務較少的企業客戶。固定資源套餐的計算資源CU量是固定的，無法應對計算資源需求量猛增的情況。比如企業平時的資料批量處理任務可以正常運作，在雙11、618等大促活動期間的資料批量處理任務就會出現嚴重阻塞。
對于存儲資源規劃，筆者建議：
• 當預估企業客戶未來一段時間的資料存儲總量比較大（100TB以上）、計算任務少（計存比小于1.5），選擇阿裡雲的固定套餐資源；
• 當客戶需要更加靈活的存儲資源空間，同時計算資源CU量不受存儲空間限制，建議選擇按量付費方式。使用多少存儲空間，消耗多少存儲費用。至于計算資源CU規劃，按照企業客戶的實際需求，單獨進行規劃。
三、MaxCompute計算資源規劃
3.1 MaxCompute計算資源簡介
對于計算資源規劃，筆者首先建議：在項目測試階段，全部都采用按量付費方式。因為開發測試階段，消耗的計算資源CU數量不多，采用按量付費方式更加便宜。關于MaxCompute計算資源按量付費的計費規則，讀者可以詳細參考官網文檔：
https://help.aliyun.com/document_detail/112752.html項目開發完成，正式進入到上線階段，建議購買包年包月的計算資源CU配額，因為是固定的CU配額，不會在阿裡雲公共計算資源池去搶占計算資源，可以順利地為企業客戶預留足夠的CU資源。計費方式如下所示：
本章節主要介紹項目上線之後，如何購買合适的包年包月固定CU數量。對于計算資源規劃，本文介紹在項目實踐中常用的兩種方案：
方法1：
按照以往經驗先确定計存比，然後預估資料容量，最後得到計算計算資源CU量；
方法2：
選擇在項目正式上線前、或者在項目正式上線運作一小段時間之後，評估計算資源CU消耗的CPU總時長，然後再根據不同任務單獨消耗的CPU時長、任務的優先級、企業客戶要求每天所有任務必須在哪個時間段運作完成，綜合考慮這幾個因素，最後得到計算資源CU量的最小最大值，用數學表達式表示就是：
本文分兩個章節分别介紹這兩種常用的計算資源預估方法。
3.2按照計存比方法預估計算資源
第一步：評估存儲容量
按照3年項目周期計算：存儲容量 = 目前資料存量 + 每月預估資料增量*月數。目前資料存量很容易得到，在資料上雲完成之後就可以得到目前資料存量。每月預估資料增量需要在資料上雲之後兩三個月，根據增量總值除以月數，得到每月預估增量平均值。當然，如果還要考慮未來資料中台承載更多業務、每月資料增量會變大等因素，可以将目前計算得到的每月預估資料增量值乘以倍數。
建議每半年預估一次存儲總容量，然後每半年調整一次計算資源CU量。
第二步：預估計存比
按照項目開發測試階段、以及上線運作一兩個月的情況，可以大概預估計存比。根據實際情況，計存比一般配置2-10。如果客戶每天運作的資料批量處理任務很多，且sql程式計算複雜度高,計存比可以選擇10；如果客戶每天運作的資料批量處理任務比較少，且sql程式計算複雜度不高，計算比可以選擇2；如果客戶每天運作的資料批量處理任務适中，sql程式計算複雜度也适中，計存比可以選擇2-10之間的合适值。
建議每半年評估一次計存比，然後每半年調整一次計算資源CU量。
第三步：預估計算資源CU量
按照第一步預估的每半年存儲資源總量，結合每半年評估的計存比值，存儲資源總量 *計存比 = 計算資源CU總量。 預估得到計算資源CU總量，進而每半年利用該企業主賬号調整一次MaxCompute計算資源CU總量。
按照計存比預估企業項目需要消耗的計算資源CU總量，有很多需要預估的變量，包括資料存儲總量、計存比，很可能預估不準确。是以，該方法要求項目的技術負責人擁有較多的項目實施經驗，能夠在每一步預估都盡可能準确。
3.3按照項目實際消耗CU量進行資源劃分
選擇在項目正式上線前、或者在項目正式上線運作一小段時間之後，評估計算資源CU消耗的CPU總時長，然後再根據不同任務單獨消耗的CPU時長、任務的優先級、企業客戶要求每天所有任務必須在哪個時間段運作完成，綜合考慮這幾個因素，最後得到計算資源消耗費用最少的最佳CU數量。
3.3.1檢視計算資源消耗情況
在進行資源規劃之前，需要首先搞清楚過去一段時間MaxCompute計算資源的消耗情況。讀者可以參考
https://help.aliyun.com/document_detail/135432.html詳細介紹如何開通和檢視MaxCompute的information_schema資訊。MaxCompute中繼資料表有很多，本文隻需要利用到一張表：TASKS_HISTORY。這張中繼資料表記錄了所有MaxCompute 計算任務的資源消耗情況。讀者可以參考
https://help.aliyun.com/document_detail/135433.html#title-r2c-tak-zfi詳細介紹中繼資料表TASKS_HISTORY的字段資訊，其中最重要的字段資訊是：cost_cpu 和 cost_mem，分别表示：
本文主要借助CPU消耗量(也就是上圖的cost_cpu字段對應的每個任務消耗的cpu數量)進行計算資源CU數量的規劃。需要注意的是，cost_cpu字段的含義：MaxCompute計算任務作業的CPU消耗量。100表示1 core*s，比如官網的例子：10 core運作5s，cost_cpu為10*100*5=5000）。那麼cost_cpu字段表示的是“cpu核數消耗量 *100 *任務運作時間秒”。因為cost_cpu按照秒統計，對于實際項目評估太過于精細，我們通常将cost_cpu 除以 100、然後再除以3600，得到cores *h (cpu核數 *小時)。這樣友善評估實際項目在規定時間段内運作完所有任務需要quota group資源組的最少計算資源CU數量。
如下如所示某個MaxCompute project 的MaxCompute計算任務的資源消耗情況：
3.3.2 規劃計算資源CU數量
通過3.3.1章節的内容，我們可以檢視到MaxCompute project某一天運作的所有計算任務消耗的CPU核數*小時。
計算資源CU數量規劃的細則：
Step1：
首先，計算得到平均每天運作所有任務消耗的cost_cpu總和(需要除以100，才能得到真正的cpu核數 *秒，然後再除以 3600，得到消耗的 “cpu核數 *小時”)。舉個例子：MaxCompute project平均每天需要運作1000個任務，這些任務消耗的cost_cpu分别是 W1、W2 …… W1000。那麼需要将W1 + W2+ …… + W1000 得到每天運作所有任務消耗的cost_cpu總和Wz。
注意：資料中台一般會劃分6個MaxCompute project，分别是：
• ods_dev：貼源層開發測試project；
• ods_prod：貼源層生産project；
• cdm_dev：公共層開發測試project；
• cdm_prod：公共層生産project；
• ads_dev：應用層開發測試project；
• ads_prod：應用層生産project；
需要将這6個MaxCompute project的所有資料計算任務的cost_cpu相加得到cost_cpu總和Wz。
當然，大部分讀者使用MaxCompute進行資料處理，并非需要建設資料中台。任何需要使用MaxCompute進行資料處理的應用場景，都可以按照實際劃分的MaxCompute project，将這些MaxCompute project涵蓋的所有資料處理任務消耗的cost_cpu相加得到總和Wz。
Step2：
按照上述介紹的阿裡雲官網詳情介紹，cost_cpu需要除以100才是真正消耗的CPU核數。同時，cost_cpu按照秒進行度量，我們一般會按照小時進行度量。是以，需要将cost_cpu總和Wz除以100、再除以3600，最後得到平均每天運作所有任務消耗 “cpu核數 *小時”，本文假設這個值為W。
Step3：
咨詢客戶資料批量處理任務需要在每天的哪些時間段運作完成。舉個例子：客戶要求在深夜零點之後、淩晨6點之前必須将所有資料批量處理任務運作完成。那麼每天能夠運作的總時長都是6個小時。本文假設所有任務必須在N個小時運作完成。
Step4：
利用上述得到的每天所有任務[cpu核數 *小時 / 任務運作時長N個小時]，就可以得到該客戶的MaxCompute project需要配置設定的計算資源CU數量的最小值：W/N。
W/N的前提是資料處理任務的cost_cpu很穩定，而且在這N個小時内，所有任務都随時在運作，不存在任何空閑的時間。但是，實際項目可能會因為某些原因導緻資料計算任務運作時間延長（比如參與計算的資料量增加），相當于W會變大；同時，由于DataWorks/Dataphin排程任務還會産生很多延遲時間、任務擷取CU資源也會耽誤很多時間，這部分延遲時間會加大任務之間運作的時間間隔，真正用于運作任務的時間會小于N。
W/N的分母實際變大、分子實際變小，進而變相地要求增加計算資源，以便讓任務擷取更多資源進而運作地更加快速。是以一般情況下，會在上述得到的W/N結果基礎上增加一倍。
按照上述4個步驟，可以預估計算得到企業可以需要購買的CU數量。
3.3.3舉例規劃計算資源CU數量
某企業實施資料中台項目，劃分8個MaxCompute project。除了3.3.2章節介紹的6個MaxCompute project之外，還單獨規劃了兩個專門做資料清洗的MaxCompute project。當然，正如前文所述，讀者需要按照實際規劃的若幹個MaxCompute project進行計算。
Step1 和 Step2：
按照3.3.1章節介紹的方法統計過去15天，平均每天8個MaxCompute project消耗的“cpu核數 *小時”的總量為：202 CPU核數 *小時。
因為客戶的業務系統空閑時間在晚上1點到早上6點，而且每天早上7點之前需要出每天資料批量任務的運作結果。在6點到7點之間，主要産出報表，是以隻有5個小時可以運作批量任務。
得到MaxCompute計算資源CU數量：202 CPU核數 *小時 / 5小時 = 40.2 cores核數，也就是至少需要41 CU。是以建議客戶購買計算資源CU量為 41*2 = 82 CU數量。
根據預估計算結果，我們為客戶推薦購買的包年包月固定CU量為82個。先開通MaxCompute 計算資源quota group 資源組的包年包月固定CU資源：
然後配置總CU量為82個。
四、淺談MaxCompute group quota 資源劃分方法
筆者在第3章節詳細介紹如何根據最近一段時間的CU消耗情況，預估得到MaxCompute 計算資源CU數量。購買的MaxCompute quota group資源屬于“預設預付費Quota”，類似于開源hadoop yarn的root資源隊列。在實際項目開發過程中，還需要将“預設預付費Quota”再細分為若幹個“子quota group資源組”。當然，一般情況下建議1個MaxCompute project 劃分1個子quota group資源組。如何将“預設預付費Quota”劃分為若幹個子quota group資源組？這是本章節需要詳細介紹的内容。
4.1 fuxi伏羲資源排程系統原理簡介
為了便于讀者理fuxi排程系統關于資源組的資源配置設定和資源搶占機制，本文以開源hadoop yarn資源隊列進行類比。MaxCompute的“預設預付費Quota”類似于yarn的root資源隊列，這部分計算資源屬于“總計算資源組”，需要将總資源組進行細分。
假設我們購買的“預設預付費Quota”包含Dt個CU資源，然後“預設預付費Quota”被劃分了n個子資源組D1、D2 …… Dn 。這n個資源組必須設定兩個重要參數：資源組的“預留CU最小配額”minD1、minD2……minDn，以及“預留CU最大配額” maxD1、maxD2……maxDn。這n個資源組必須滿足以下條件：
•** minD1 + minD2 + …… + minDn = Dt
• 對于任意的子資源組的maxDi，maxDi <= Dt**
我們劃分子資源組必須滿足上述兩個條件。其中，每個MaxCompute project的min資源量表示該子資源組最低預留的CU數量，無論是否有任務送出，這個子資源組就會占用這麼多CU量；每個MaxCompute project的max資源量表示該子資源組能夠擷取到的最大CU數量，哪怕其他資源組全部都沒有任務運作，這個子資源組最多也隻能占用max的CU量。
如下圖所示，170個CU資源量的“預設預付費Quota”劃分了兩個子資源組：
從上圖我們看到，劃分的兩個子資源組yong_quota_group 和 fixed_quota_group設定的最小CU配額、最大CU配額，滿足上述兩個條件。
4.2 MaxCompute計算資源搶占機制
按照4.1介紹的内容，若幹個子資源組的max最大CU配額都可以設定為“預設預付費Quota”，那麼一旦所有資源組對應的MaxCompute project都瘋狂地運作任務，那麼必然存在資源搶占的問題。按照預設規則，MaxCompute資源組的資源搶占按照“fair scheduling”公平排程機制，先送出的任務優先擷取CU資源。那麼，如果某個MaxCompute project送出超大型任務，必然将會把CU資源消耗殆盡。此時，其他資源組對應的MaxCompute project送出的任務将會因為無法擷取到CU資源而被阻塞。
如何更加完美地劃分quota group資源組，并且為每個資源組配置設定最合理的 min資源配額、max資源配額？ 如何結合實際項目需求，合理安排任務運作的先後順序、以及任務運作排程的依賴關系？這是劃分子quota group資源組需要考慮的重點因素。
4.3 quota group資源組劃分
在第3章節詳細介紹如何預估計算企業客戶需要購買的包年包月預留CU量，也就是 “預設預付費Quota”，比如3.3.3章節的實際案例裡面介紹的170個CU。下一步就是建立子quota group資源組，并為每個quota group配置設定 min、max資源量。筆者結合多年hadoop yarn資源配置設定經驗，以及使用MaxCompute的一些經驗，總結了一些實際的經驗。
第1條方法：
每個MaxCompute project 對應1個獨立的quota group子資源組；
第2條方法：
每個quota group子資源組的min 資源量不小于 “預設預付費Quota”的5%，建議也不大于“預設預付費Quota”的20%。具體原因：如果将子資源組的min資源量設定太大，比如超過20%，那麼各個資源組的min資源量之和就會接近或者超過“預設預付費Quota”，那麼劃分子資源組将會失去意義，最終造成資源大量浪費。
第3條方法：
每個quota group子資源組的max 資源量不小于“預設預付費Quota”的40%，當然最大可以設定到“預設預付費Quota”。如果子資源組的max 資源量設太小，在叢集運作任務空閑的時候，資源會造成極大浪費。
除了上述三條基本方法之外，還有幾個比較實用的方法：
第4條方法：
對于企業客戶劃分的多個MaxCompute project，需要統計每個project 的cost_cpu消耗量“cpu核數 *小時”，并按照消耗量進行排序。消耗量最大的MaxCompute project對應的子資源組的max資源量可以設定為“預設預付費Quota”的80%以上，其他project對應的子資源組按照排序，設定的max資源量以此減少，直到最後的子資源組的max資源量不小于“預設預付費Quota”的40%。
第5條方法：考慮任務排程與依賴關系
對于很多企業客戶，使用DataWorks/Dataphin需要做任務排程。任務排程就必然有父子任務關系。比如筆者在本文列舉的實際案例，對于資料中台項目，劃分了8個MaxCompute project，分别是：資料清洗的兩個project、ods貼源層的兩個project、cdm公共層的兩個project、ads應用層的兩個project。每個project配置設定一個獨立的quota group子資源組。資料分層有嚴格的先後順序：資料清洗的任務是ods層任務的父任務；ods層任務是cdm層任務的父任務；cdm層任務是ads層任務的父任務，他們之間的任務排程關系如下所示：
對于這類常見的不同MaxCompute project的任務之間有嚴格的排程依賴關系，不能簡單的按照上述的方法設定資源組的min資源量和max資源量。因為上一個層次有幾百個任務需要運作、下一個層次也有幾百個任務需要運作，而且這些任務之間是混合運作的。比如：某個工作流的幾十個ods層任務運作完成，那麼接下來将會運作對應的幾十個cdm層任務；與此同時，資料清洗層和ods層還會運作新的任務；cdm層和ads層也會運作所有上遊都運作完成的任務。這些任務之間混合在一起運作，為資源組劃分資源量添加了很多變數。此時需要根據實際項目經驗，為這些資源組配置設定min資源量和max資源量。
比如筆者這邊的項目情況如下：資料清洗層因為涉及很多業務系統原始資料表的join操作，非常消耗CU資源；ods層經常是導入清洗之後的資料即可，不需要消耗太多資源；cdm層規範模組化，任務運作方法比較固定，因為我們在資料清洗層已經将資料做規範化處理，是以cdm層消耗的CU資源也很少；最後，将cdm的派生名額融合進ads層，需要做很多複雜的join操作，是以消耗的CU資源非常多。并且，從晚上1點到淩晨7點之間，這四個層次對應的項目運作消耗的資源量呈現“錯峰”情況。下圖是我們在進行測試環節統計的情況：
可以明顯看出來，四個層次運作任務的數量呈現“錯峰”情況，每個層次出現的任務高峰會以此延後一段時間，該層次MaxCompute project消耗的資源量也是呈現錯峰。鑒于上述場景分析，我們考慮在第4條方法的基礎上，将不同層次“錯峰”高峰運作的因素也考慮在内。盡可能讓消耗資源多的項目配置設定的max資源量更大，但是因為“錯峰”運作因素，消耗資源少的項目配置設定的max資源量也不能太小，盡可能配置設定大一些，讓資源得到合理應用。筆者為該項目設計4個quota 資源組：
• 資料清洗層project對應的quota 資源組：min資源量為“預設預付費Quota”的10%，max資源量為“預設預付費Quota”的70%；
• ods貼源層project對應的quota 資源組：min資源量為“預設預付費Quota”的10%，max資源量為“預設預付費Quota”的50%；
• cdm公共層project對應的quota 資源組：min資源量為“預設預付費Quota”的10%，max資源量為“預設預付費Quota”的50%；
• ads應用層project對應的quota 資源組：min資源量為“預設預付費Quota”的10%，max資源量為“預設預付費Quota”的80%。
五、總結
當然，實際如何為MaxCompute project劃分資源組？每個資源組的min/max資源量占據“預設預付費Quota”的百分比多少？需要綜合考慮不同MaxCompute project内部的資料處理任務的優先級、任務之間依賴關系、任務錯峰運作情況，還需要特别考慮某些超大型資料計算任務是否有必要與其他普通任務進行資源組隔離。
關于更多包年包月計算資源規劃建議：
1.包年包月資源分時設定：
https://developer.aliyun.com/article/7689842.包年包月項目作業使用按量付費資源：
https://help.aliyun.com/document_detail/171280.html3.包年包月作業優先級功能：
https://help.aliyun.com/document_detail/175617.html原創：阿裡雲智能 周江
歡迎掃碼加入 MaxCompute開發者社群釘釘群，或點選
點選連結申請加入。