簡介：?本文主要介紹如何進行MaxCompute存儲資源和計算資源的評估及規(guī)劃管理。

一、MaxCompute資源規(guī)劃背景介紹

MaxCompute資源主要有兩類：存儲資源、計算資源(包含cpu和內存)。存儲資源用于存儲MaxCompute的庫表數據，計算資源用于運行sql、mr等任務。最佳的MaxCompute資源規(guī)劃方案能夠達到以下幾個目的：
? 數據存儲資源足夠，既能夠存儲當前的所有存量庫表數據，也能夠存儲未來一段時間的增量數據；
? 計算資源充足，但是不能浪費。計算資源量能夠滿足所有數據計算任務，且盡可能減少資源浪費情況。這樣耗費的資源費用最少；
? 被處理的數據量巨大、耗費計算資源較多的大型任務，可能會將quota group資源組耗盡，造成其他任務無法獲取到計算資源而阻塞。MaxCompute資源規(guī)劃方案必須能夠盡量避免這種情況；
? 不同優(yōu)先級的計算任務能夠盡量互不干擾，有限保證高優(yōu)先級的任務獲取到足夠計算資源；
? 能夠滿足時段的差異化資源需求，滿足對資源隔離（生產/開發(fā)/自助分析）不同工作負載的能力，避免相互干擾，同時更大化提高資源使用率。
MaxCompute資源規(guī)劃的最終目標就是能夠滿足上述幾點需求，企業(yè)客戶消耗最低資源費用的情況下，滿足數據存儲需求，以及數據處理任務對計算資源的需求。
本文內容主要基于阿里公有云MaxCompute環(huán)境。公有云和專有云環(huán)境的MaxCompute資源規(guī)劃有比較大的差異，比如：在公有云環(huán)境，存儲資源和計算資源是使用整個阿里云區(qū)域的資源池，幾乎不用擔心底層到底有多少臺服務器進行支撐，可以近乎認為公有云底層的資源池是無限的；但是在專有云環(huán)境，整個專有云都是企業(yè)客戶獨享的資源，必須根據存儲資源和計算資源量規(guī)劃服務器數量&&服務器規(guī)格。本文主要探討公有云MaxCompute的資源規(guī)劃。

二、MaxCompute存儲資源規(guī)劃

2.1 計存比

在介紹存儲方案選擇之前，先說一個常用的概念：“計存比”。計存比就是計算CU數量和實際存儲數量TB的比值。比如資源分配：50CU計算資源，存儲數據量是10TB。那么，50CU/10TB=5，計存比=5。

2.2 存儲資源規(guī)劃建議

對于存儲資源，MaxCompute提供兩種計費方式：
? 按量付費：MaxCompute以小時級別采集每個項目空間下當前的存儲，并以 project 項目空間為基本單位，計算項目空間當天的存儲平均值。然后再乘以單價(元/GB/天)，最后的得到每天的存儲費用。

? 套餐資源：MaxCompute包年包月套餐包含預留的計算資源和存儲資源，每種套餐固定計算資源CU量和存儲資源。套餐中的存儲資源是指每天固定的存儲資源，超過的部分另外按量計費。套餐資源目前只支持固定的幾個套餐，見下圖所示：

阿里云提供的第二種方案，三種套餐的計存比是固定的，而且計存比都在1左右。這種固定資源套餐的計存比偏低，適合存儲量大、計算任務較少的企業(yè)客戶。固定資源套餐的計算資源CU量是固定的，無法應對計算資源需求量猛增的情況。比如企業(yè)平時的數據批量處理任務可以正常運行，在雙11、618等大促活動期間的數據批量處理任務就會出現嚴重阻塞。
對于存儲資源規(guī)劃，筆者建議：
? 當預估企業(yè)客戶未來一段時間的數據存儲總量比較大（100TB以上）、計算任務少（計存比小于1.5），選擇阿里云的固定套餐資源；
? 當客戶需要更加靈活的存儲資源空間，同時計算資源CU量不受存儲空間限制，建議選擇按量付費方式。使用多少存儲空間，消耗多少存儲費用。至于計算資源CU規(guī)劃，按照企業(yè)客戶的實際需求，單獨進行規(guī)劃。

三、MaxCompute計算資源規(guī)劃

3.1 MaxCompute計算資源簡介

對于計算資源規(guī)劃，筆者首先建議：在項目測試階段，全部都采用按量付費方式。因為開發(fā)測試階段，消耗的計算資源CU數量不多，采用按量付費方式更加便宜。關于MaxCompute計算資源按量付費的計費規(guī)則，讀者可以詳細參考官網文檔：https://help.aliyun.com/document_detail/112752.html
項目開發(fā)完成，正式進入到上線階段，建議購買包年包月的計算資源CU配額，因為是固定的CU配額，不會在阿里云公共計算資源池去搶占計算資源，可以順利地為企業(yè)客戶預留足夠的CU資源。計費方式如下所示：

本章節(jié)主要介紹項目上線之后，如何購買合適的包年包月固定CU數量。對于計算資源規(guī)劃，本文介紹在項目實踐中常用的兩種方案：
方法1：
按照以往經驗先確定計存比，然后預估數據容量，最后得到計算計算資源CU量；
方法2：
選擇在項目正式上線前、或者在項目正式上線運行一小段時間之后，評估計算資源CU消耗的CPU總時長，然后再根據不同任務單獨消耗的CPU時長、任務的優(yōu)先級、企業(yè)客戶要求每天所有任務必須在哪個時間段運行完成，綜合考慮這幾個因素，最后得到計算資源CU量的最小最大值，用數學表達式表示就是：

本文分兩個章節(jié)分別介紹這兩種常用的計算資源預估方法。

3.2按照計存比方法預估計算資源

第一步：評估存儲容量
按照3年項目周期計算：存儲容量 = 當前數據存量 + 每月預估數據增量*月數。當前數據存量很容易得到，在數據上云完成之后就可以得到當前數據存量。每月預估數據增量需要在數據上云之后兩三個月，根據增量總值除以月數，得到每月預估增量平均值。當然，如果還要考慮未來數據中臺承載更多業(yè)務、每月數據增量會變大等因素，可以將當前計算得到的每月預估數據增量值乘以倍數。
建議每半年預估一次存儲總容量，然后每半年調整一次計算資源CU量。
第二步：預估計存比
按照項目開發(fā)測試階段、以及上線運行一兩個月的情況，可以大概預估計存比。根據實際情況，計存比一般配置2-10。如果客戶每天運行的數據批量處理任務很多，且sql程序計算復雜度高,計存比可以選擇10；如果客戶每天運行的數據批量處理任務比較少，且sql程序計算復雜度不高，計算比可以選擇2；如果客戶每天運行的數據批量處理任務適中，sql程序計算復雜度也適中，計存比可以選擇2-10之間的合適值。
建議每半年評估一次計存比，然后每半年調整一次計算資源CU量。
第三步：預估計算資源CU量
按照第一步預估的每半年存儲資源總量，結合每半年評估的計存比值，存儲資源總量 *計存比 = 計算資源CU總量。 預估得到計算資源CU總量，進而每半年利用該企業(yè)主賬號調整一次MaxCompute計算資源CU總量。
按照計存比預估企業(yè)項目需要消耗的計算資源CU總量，有很多需要預估的變量，包括數據存儲總量、計存比，很可能預估不準確。因此，該方法要求項目的技術負責人擁有較多的項目實施經驗，能夠在每一步預估都盡可能準確。

3.3按照項目實際消耗CU量進行資源劃分

選擇在項目正式上線前、或者在項目正式上線運行一小段時間之后，評估計算資源CU消耗的CPU總時長，然后再根據不同任務單獨消耗的CPU時長、任務的優(yōu)先級、企業(yè)客戶要求每天所有任務必須在哪個時間段運行完成，綜合考慮這幾個因素，最后得到計算資源消耗費用最少的最佳CU數量。

3.3.1查看計算資源消耗情況

在進行資源規(guī)劃之前，需要首先搞清楚過去一段時間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數量的規(guī)劃。需要注意的是，cost_cpu字段的含義：MaxCompute計算任務作業(yè)的CPU消耗量。100表示1 core*s，比如官網的例子：10 core運行5s，cost_cpu為10*100*5=5000）。那么cost_cpu字段表示的是“cpu核數消耗量 *100 *任務運行時間秒”。因為cost_cpu按照秒統(tǒng)計，對于實際項目評估太過于精細，我們通常將cost_cpu 除以 100、然后再除以3600，得到cores *h (cpu核數 *小時)。這樣方便評估實際項目在規(guī)定時間段內運行完所有任務需要quota group資源組的最少計算資源CU數量。
如下如所示某個MaxCompute project 的MaxCompute計算任務的資源消耗情況：

3.3.2 規(guī)劃計算資源CU數量

通過3.3.1章節(jié)的內容，我們可以查看到MaxCompute project某一天運行的所有計算任務消耗的CPU核數*小時。
計算資源CU數量規(guī)劃的細則：
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：貼源層開發(fā)測試project；
? ods_prod：貼源層生產project；
? cdm_dev：公共層開發(fā)測試project；
? cdm_prod：公共層生產project；
? ads_dev：應用層開發(fā)測試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很穩(wěn)定，而且在這N個小時內，所有任務都隨時在運行，不存在任何空閑的時間。但是，實際項目可能會因為某些原因導致數據計算任務運行時間延長（比如參與計算的數據量增加），相當于W會變大；同時，由于DataWorks/Dataphin調度任務還會產生很多延遲時間、任務獲取CU資源也會耽誤很多時間，這部分延遲時間會加大任務之間運行的時間間隔，真正用于運行任務的時間會小于N。
W/N的分母實際變大、分子實際變小，進而變相地要求增加計算資源，以便讓任務獲取更多資源進而運行地更加快速。因此一般情況下，會在上述得到的W/N結果基礎上增加一倍。
按照上述4個步驟，可以預估計算得到企業(yè)可以需要購買的CU數量。

3.3.3舉例規(guī)劃計算資源CU數量

某企業(yè)實施數據中臺項目，劃分8個MaxCompute project。除了3.3.2章節(jié)介紹的6個MaxCompute project之外，還單獨規(guī)劃了兩個專門做數據清洗的MaxCompute project。當然，正如前文所述，讀者需要按照實際規(guī)劃的若干個MaxCompute project進行計算。
Step1 和 Step2：
按照3.3.1章節(jié)介紹的方法統(tǒng)計過去15天，平均每天8個MaxCompute project消耗的“cpu核數 *小時”的總量為：202 CPU核數 *小時。
Step3：
因為客戶的業(yè)務系統(tǒng)空閑時間在晚上1點到早上6點，而且每天早上7點之前需要出每天數據批量任務的運行結果。在6點到7點之間，主要產出報表，因此只有5個小時可以運行批量任務。
Step4：
得到MaxCompute計算資源CU數量：202 CPU核數 *小時 / 5小時 = 40.2 cores核數，也就是至少需要41 CU。因此建議客戶購買計算資源CU量為 41*2 = 82 CU數量。
根據預估計算結果，我們?yōu)榭蛻敉扑]購買的包年包月固定CU量為82個。先開通MaxCompute 計算資源quota group 資源組的包年包月固定CU資源：

然后配置總CU量為82個。

四、淺談MaxCompute group quota 資源劃分方法

筆者在第3章節(jié)詳細介紹如何根據最近一段時間的CU消耗情況，預估得到MaxCompute 計算資源CU數量。購買的MaxCompute quota group資源屬于“默認預付費Quota”，類似于開源hadoop yarn的root資源隊列。在實際項目開發(fā)過程中，還需要將“默認預付費Quota”再細分為若干個“子quota group資源組”。當然，一般情況下建議1個MaxCompute project 劃分1個子quota group資源組。如何將“默認預付費Quota”劃分為若干個子quota group資源組？這是本章節(jié)需要詳細介紹的內容。

4.1 fuxi伏羲資源調度系統(tǒng)原理簡介

為了便于讀者理fuxi調度系統(tǒng)關于資源組的資源分配和資源搶占機制，本文以開源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都瘋狂地運行任務，那么必然存在資源搶占的問題。按照默認規(guī)則，MaxCompute資源組的資源搶占按照“fair scheduling”公平調度機制，先提交的任務優(yōu)先獲取CU資源。那么，如果某個MaxCompute project提交超大型任務，必然將會把CU資源消耗殆盡。此時，其他資源組對應的MaxCompute project提交的任務將會因為無法獲取到CU資源而被阻塞。
如何更加完美地劃分quota group資源組，并且為每個資源組分配最合理的 min資源配額、max資源配額？ 如何結合實際項目需求，合理安排任務運行的先后順序、以及任務運行調度的依賴關系？這是劃分子quota group資源組需要考慮的重點因素。

4.3 quota group資源組劃分

在第3章節(jié)詳細介紹如何預估計算企業(yè)客戶需要購買的包年包月預留CU量，也就是 “默認預付費Quota”，比如3.3.3章節(jié)的實際案例里面介紹的170個CU。下一步就是創(chuàng)建子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條方法：
對于企業(yè)客戶劃分的多個MaxCompute project，需要統(tǒng)計每個project 的cost_cpu消耗量“cpu核數 *小時”，并按照消耗量進行排序。消耗量最大的MaxCompute project對應的子資源組的max資源量可以設置為“默認預付費Quota”的80%以上，其他project對應的子資源組按照排序，設置的max資源量以此減少，直到最后的子資源組的max資源量不小于“默認預付費Quota”的40%。
第5條方法：考慮任務調度與依賴關系
對于很多企業(yè)客戶，使用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資源量。
比如筆者這邊的項目情況如下：數據清洗層因為涉及很多業(yè)務系統(tǒng)原始數據表的join操作，非常消耗CU資源；ods層經常是導入清洗之后的數據即可，不需要消耗太多資源；cdm層規(guī)范建模，任務運行方法比較固定，因為我們在數據清洗層已經將數據做規(guī)范化處理，因此cdm層消耗的CU資源也很少；最后，將cdm的派生指標融合進ads層，需要做很多復雜的join操作，因此消耗的CU資源非常多。并且，從晚上1點到凌晨7點之間，這四個層次對應的項目運行消耗的資源量呈現“錯峰”情況。下圖是我們在進行測試環(huán)節(jié)統(tǒng)計的情況：

可以明顯看出來，四個層次運行任務的數量呈現“錯峰”情況，每個層次出現的任務高峰會以此延后一段時間，該層次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內部的數據處理任務的優(yōu)先級、任務之間依賴關系、任務錯峰運行情況，還需要特別考慮某些超大型數據計算任務是否有必要與其他普通任務進行資源組隔離。

?

原文鏈接
本文為阿里云原創(chuàng)內容，未經允許不得轉載。

總結

以上是生活随笔為你收集整理的浅谈MaxCompute资源规划管理及评估的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。