一、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計算資源按量付費的計費規則。

專案開發完成，正式進入到上線階段，建議購買包年包月的計算資源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計算資源的消耗情況。

詳細介紹如何開通和檢視MaxCompute的information_schema資訊。MaxCompute元資料表有很多，本文只需要利用到一張表：TASKS_HISTORY。這張元資料表記錄了所有MaxCompute 計算任務的資源消耗情況。詳細介紹元資料表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核數 *小時。

Step3：
因為客戶的業務系統空閒時間在晚上1點到早上6點，而且每天早上7點之前需要出每天資料批量任務的執行結果。在6點到7點之間，主要產出報表，因此只有5個小時可以執行批量任務。

Step4：
得到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內部的資料處理任務的優先順序、任務之間依賴關係、任務錯峰執行情況，還需要特別考慮某些超大型資料計算任務是否有必要與其他普通任務進行資源組隔離。

作者：阿里雲智慧 - 周江

原文連結

本文為阿里雲原創內容，未經允許不得轉載。