一、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 cores，比如官網的例子：10 core運行5s，cost_cpu爲101005=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核數 小時。
Step3：
因爲客戶的業務系統空閒時間在晚上1點到早上6點，而且每天早上7點之前需要出每天數據批量任務的運行結果。在6點到7點之間，主要產出報表，因此只有5個小時可以運行批量任務。
Step4：
得到MaxCompute計算資源CU數量：202 CPU核數 小時 / 5小時 = 40.2 cores核數，也就是至少需要41 CU。因此建議客戶購買計算資源CU量爲 412 = 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/768984
2.包年包月項目作業使用按量付費資源：https://help.aliyun.com/document_detail/171280.html
3.包年包月作業優先級功能：https://help.aliyun.com/document_detail/175617.html