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

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

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

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

2.1 計存比

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

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

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

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

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

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

3.1 MaxCompute計算資源簡介

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

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

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

3.2按照計存比方法預(yù)估計算資源

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

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

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

3.3.1查看計算資源消耗情況

在進行資源規(guī)劃之前，需要首先搞清楚過去一段時間MaxCompute計算資源的消耗情況。讀者可以參考https://help.aliyun.com/document_detail/135432.html
詳細介紹如何開通和查看MaxCompute的information_schema信息。MaxCompute元數(shù)據(jù)表有很多，本文只需要利用到一張表：TASKS_HISTORY。這張元數(shù)據(jù)表記錄了所有MaxCompute 計算任務(wù)的資源消耗情況。讀者可以參考?
https://help.aliyun.com/document_detail/135433.html#title-r2c-tak-zfi
詳細介紹元數(shù)據(jù)表TASKS_HISTORY的字段信息，其中最重要的字段信息是：cost_cpu 和 cost_mem，分別表示：

本文主要借助CPU消耗量(也就是上圖的cost_cpu字段對應(yīng)的每個任務(wù)消耗的cpu數(shù)量)進行計算資源CU數(shù)量的規(guī)劃。需要注意的是，cost_cpu字段的含義：MaxCompute計算任務(wù)作業(yè)的CPU消耗量。100表示1 core*s，比如官網(wǎng)的例子：10 core運行5s，cost_cpu為10*100*5=5000）。那么cost_cpu字段表示的是“cpu核數(shù)消耗量 *100 *任務(wù)運行時間秒”。因為cost_cpu按照秒統(tǒng)計，對于實際項目評估太過于精細，我們通常將cost_cpu 除以 100、然后再除以3600，得到cores *h (cpu核數(shù) *小時)。這樣方便評估實際項目在規(guī)定時間段內(nèi)運行完所有任務(wù)需要quota group資源組的最少計算資源CU數(shù)量。
如下如所示某個MaxCompute project 的MaxCompute計算任務(wù)的資源消耗情況：

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

通過3.3.1章節(jié)的內(nèi)容，我們可以查看到MaxCompute project某一天運行的所有計算任務(wù)消耗的CPU核數(shù)*小時。
計算資源CU數(shù)量規(guī)劃的細則：
Step1：
首先，計算得到平均每天運行所有任務(wù)消耗的cost_cpu總和(需要除以100，才能得到真正的cpu核數(shù) *秒，然后再除以 3600，得到消耗的 “cpu核數(shù) *小時”)。舉個例子：MaxCompute project平均每天需要運行1000個任務(wù)，這些任務(wù)消耗的cost_cpu分別是 W1、W2 …… W1000。那么需要將W1 + W2+ …… + W1000 得到每天運行所有任務(wù)消耗的cost_cpu總和Wz。
注意：數(shù)據(jù)中臺一般會劃分6個MaxCompute project，分別是：
? ods_dev：貼源層開發(fā)測試project；
? ods_prod：貼源層生產(chǎn)project；
? cdm_dev：公共層開發(fā)測試project；
? cdm_prod：公共層生產(chǎn)project；
? ads_dev：應(yīng)用層開發(fā)測試project；
? ads_prod：應(yīng)用層生產(chǎn)project；
需要將這6個MaxCompute project的所有數(shù)據(jù)計算任務(wù)的cost_cpu相加得到cost_cpu總和Wz。
當(dāng)然，大部分讀者使用MaxCompute進行數(shù)據(jù)處理，并非需要建設(shè)數(shù)據(jù)中臺。任何需要使用MaxCompute進行數(shù)據(jù)處理的應(yīng)用場景，都可以按照實際劃分的MaxCompute project，將這些MaxCompute project涵蓋的所有數(shù)據(jù)處理任務(wù)消耗的cost_cpu相加得到總和Wz。
Step2：
按照上述介紹的阿里云官網(wǎng)詳情介紹，cost_cpu需要除以100才是真正消耗的CPU核數(shù)。同時，cost_cpu按照秒進行度量，我們一般會按照小時進行度量。因此，需要將cost_cpu總和Wz除以100、再除以3600，最后得到平均每天運行所有任務(wù)消耗 “cpu核數(shù) *小時”，本文假設(shè)這個值為W。
Step3：
咨詢客戶數(shù)據(jù)批量處理任務(wù)需要在每天的哪些時間段運行完成。舉個例子：客戶要求在深夜零點之后、凌晨6點之前必須將所有數(shù)據(jù)批量處理任務(wù)運行完成。那么每天能夠運行的總時長都是6個小時。本文假設(shè)所有任務(wù)必須在N個小時運行完成。
Step4：
利用上述得到的每天所有任務(wù)[cpu核數(shù) *小時 / 任務(wù)運行時長N個小時]，就可以得到該客戶的MaxCompute project需要分配的計算資源CU數(shù)量的最小值：W/N。
W/N的前提是數(shù)據(jù)處理任務(wù)的cost_cpu很穩(wěn)定，而且在這N個小時內(nèi)，所有任務(wù)都隨時在運行，不存在任何空閑的時間。但是，實際項目可能會因為某些原因?qū)е聰?shù)據(jù)計算任務(wù)運行時間延長（比如參與計算的數(shù)據(jù)量增加），相當(dāng)于W會變大；同時，由于DataWorks/Dataphin調(diào)度任務(wù)還會產(chǎn)生很多延遲時間、任務(wù)獲取CU資源也會耽誤很多時間，這部分延遲時間會加大任務(wù)之間運行的時間間隔，真正用于運行任務(wù)的時間會小于N。
W/N的分母實際變大、分子實際變小，進而變相地要求增加計算資源，以便讓任務(wù)獲取更多資源進而運行地更加快速。因此一般情況下，會在上述得到的W/N結(jié)果基礎(chǔ)上增加一倍。
按照上述4個步驟，可以預(yù)估計算得到企業(yè)可以需要購買的CU數(shù)量。

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

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

然后配置總CU量為82個。

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

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

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

為了便于讀者理fuxi調(diào)度系統(tǒng)關(guān)于資源組的資源分配和資源搶占機制，本文以開源hadoop yarn資源隊列進行類比。MaxCompute的“默認(rèn)預(yù)付費Quota”類似于yarn的root資源隊列，這部分計算資源屬于“總計算資源組”，需要將總資源組進行細分。
假設(shè)我們購買的“默認(rèn)預(yù)付費Quota”包含Dt個CU資源，然后“默認(rèn)預(yù)付費Quota”被劃分了n個子資源組D1、D2 …… Dn 。這n個資源組必須設(shè)置兩個重要參數(shù)：資源組的“預(yù)留CU最小配額”minD1、minD2……minDn，以及“預(yù)留CU最大配額” maxD1、maxD2……maxDn。這n個資源組必須滿足以下條件：
?** minD1 + minD2 + …… + minDn = Dt
? 對于任意的子資源組的maxDi，maxDi <= Dt**
我們劃分子資源組必須滿足上述兩個條件。其中，每個MaxCompute project的min資源量表示該子資源組最低預(yù)留的CU數(shù)量，無論是否有任務(wù)提交，這個子資源組就會占用這么多CU量；每個MaxCompute project的max資源量表示該子資源組能夠獲取到的最大CU數(shù)量，哪怕其他資源組全部都沒有任務(wù)運行，這個子資源組最多也只能占用max的CU量。
如下圖所示，170個CU資源量的“默認(rèn)預(yù)付費Quota”劃分了兩個子資源組：

從上圖我們看到，劃分的兩個子資源組yong_quota_group 和 fixed_quota_group設(shè)置的最小CU配額、最大CU配額，滿足上述兩個條件。

4.2 MaxCompute計算資源搶占機制

按照4.1介紹的內(nèi)容，若干個子資源組的max最大CU配額都可以設(shè)置為“默認(rèn)預(yù)付費Quota”，那么一旦所有資源組對應(yīng)的MaxCompute project都瘋狂地運行任務(wù)，那么必然存在資源搶占的問題。按照默認(rèn)規(guī)則，MaxCompute資源組的資源搶占按照“fair scheduling”公平調(diào)度機制，先提交的任務(wù)優(yōu)先獲取CU資源。那么，如果某個MaxCompute project提交超大型任務(wù)，必然將會把CU資源消耗殆盡。此時，其他資源組對應(yīng)的MaxCompute project提交的任務(wù)將會因為無法獲取到CU資源而被阻塞。
如何更加完美地劃分quota group資源組，并且為每個資源組分配最合理的 min資源配額、max資源配額？ 如何結(jié)合實際項目需求，合理安排任務(wù)運行的先后順序、以及任務(wù)運行調(diào)度的依賴關(guān)系？這是劃分子quota group資源組需要考慮的重點因素。

4.3 quota group資源組劃分

在第3章節(jié)詳細介紹如何預(yù)估計算企業(yè)客戶需要購買的包年包月預(yù)留CU量，也就是 “默認(rèn)預(yù)付費Quota”，比如3.3.3章節(jié)的實際案例里面介紹的170個CU。下一步就是創(chuàng)建子quota group資源組，并為每個quota group分配 min、max資源量。筆者結(jié)合多年hadoop yarn資源分配經(jīng)驗，以及使用MaxCompute的一些經(jīng)驗，總結(jié)了一些實際的經(jīng)驗。
第1條方法：
每個MaxCompute project 對應(yīng)1個獨立的quota group子資源組；
第2條方法：
每個quota group子資源組的min 資源量不小于 “默認(rèn)預(yù)付費Quota”的5%，建議也不大于“默認(rèn)預(yù)付費Quota”的20%。具體原因：如果將子資源組的min資源量設(shè)置太大，比如超過20%，那么各個資源組的min資源量之和就會接近或者超過“默認(rèn)預(yù)付費Quota”，那么劃分子資源組將會失去意義，最終造成資源大量浪費。
第3條方法：
每個quota group子資源組的max 資源量不小于“默認(rèn)預(yù)付費Quota”的40%，當(dāng)然最大可以設(shè)置到“默認(rèn)預(yù)付費Quota”。如果子資源組的max 資源量設(shè)太小，在集群運行任務(wù)空閑的時候，資源會造成極大浪費。
除了上述三條基本方法之外，還有幾個比較實用的方法：
第4條方法：
對于企業(yè)客戶劃分的多個MaxCompute project，需要統(tǒng)計每個project 的cost_cpu消耗量“cpu核數(shù) *小時”，并按照消耗量進行排序。消耗量最大的MaxCompute project對應(yīng)的子資源組的max資源量可以設(shè)置為“默認(rèn)預(yù)付費Quota”的80%以上，其他project對應(yīng)的子資源組按照排序，設(shè)置的max資源量以此減少，直到最后的子資源組的max資源量不小于“默認(rèn)預(yù)付費Quota”的40%。
第5條方法：考慮任務(wù)調(diào)度與依賴關(guān)系
對于很多企業(yè)客戶，使用DataWorks/Dataphin需要做任務(wù)調(diào)度。任務(wù)調(diào)度就必然有父子任務(wù)關(guān)系。比如筆者在本文列舉的實際案例，對于數(shù)據(jù)中臺項目，劃分了8個MaxCompute project，分別是：數(shù)據(jù)清洗的兩個project、ods貼源層的兩個project、cdm公共層的兩個project、ads應(yīng)用層的兩個project。每個project分配一個獨立的quota group子資源組。數(shù)據(jù)分層有嚴(yán)格的先后順序：數(shù)據(jù)清洗的任務(wù)是ods層任務(wù)的父任務(wù)；ods層任務(wù)是cdm層任務(wù)的父任務(wù)；cdm層任務(wù)是ads層任務(wù)的父任務(wù)，他們之間的任務(wù)調(diào)度關(guān)系如下所示：

對于這類常見的不同MaxCompute project的任務(wù)之間有嚴(yán)格的調(diào)度依賴關(guān)系，不能簡單的按照上述的方法設(shè)置資源組的min資源量和max資源量。因為上一個層次有幾百個任務(wù)需要運行、下一個層次也有幾百個任務(wù)需要運行，而且這些任務(wù)之間是混合運行的。比如：某個工作流的幾十個ods層任務(wù)運行完成，那么接下來將會運行對應(yīng)的幾十個cdm層任務(wù)；與此同時，數(shù)據(jù)清洗層和ods層還會運行新的任務(wù)；cdm層和ads層也會運行所有上游都運行完成的任務(wù)。這些任務(wù)之間混合在一起運行，為資源組劃分資源量添加了很多變數(shù)。此時需要根據(jù)實際項目經(jīng)驗，為這些資源組分配min資源量和max資源量。
比如筆者這邊的項目情況如下：數(shù)據(jù)清洗層因為涉及很多業(yè)務(wù)系統(tǒng)原始數(shù)據(jù)表的join操作，非常消耗CU資源；ods層經(jīng)常是導(dǎo)入清洗之后的數(shù)據(jù)即可，不需要消耗太多資源；cdm層規(guī)范建模，任務(wù)運行方法比較固定，因為我們在數(shù)據(jù)清洗層已經(jīng)將數(shù)據(jù)做規(guī)范化處理，因此cdm層消耗的CU資源也很少；最后，將cdm的派生指標(biāo)融合進ads層，需要做很多復(fù)雜的join操作，因此消耗的CU資源非常多。并且，從晚上1點到凌晨7點之間，這四個層次對應(yīng)的項目運行消耗的資源量呈現(xiàn)“錯峰”情況。下圖是我們在進行測試環(huán)節(jié)統(tǒng)計的情況：

可以明顯看出來，四個層次運行任務(wù)的數(shù)量呈現(xiàn)“錯峰”情況，每個層次出現(xiàn)的任務(wù)高峰會以此延后一段時間，該層次MaxCompute project消耗的資源量也是呈現(xiàn)錯峰。鑒于上述場景分析，我們考慮在第4條方法的基礎(chǔ)上，將不同層次“錯峰”高峰運行的因素也考慮在內(nèi)。盡可能讓消耗資源多的項目分配的max資源量更大，但是因為“錯峰”運行因素，消耗資源少的項目分配的max資源量也不能太小，盡可能分配大一些，讓資源得到合理應(yīng)用。筆者為該項目設(shè)計4個quota 資源組：
? 數(shù)據(jù)清洗層project對應(yīng)的quota 資源組：min資源量為“默認(rèn)預(yù)付費Quota”的10%，max資源量為“默認(rèn)預(yù)付費Quota”的70%；
? ods貼源層project對應(yīng)的quota 資源組：min資源量為“默認(rèn)預(yù)付費Quota”的10%，max資源量為“默認(rèn)預(yù)付費Quota”的50%；
? cdm公共層project對應(yīng)的quota 資源組：min資源量為“默認(rèn)預(yù)付費Quota”的10%，max資源量為“默認(rèn)預(yù)付費Quota”的50%；
? ads應(yīng)用層project對應(yīng)的quota 資源組：min資源量為“默認(rèn)預(yù)付費Quota”的10%，max資源量為“默認(rèn)預(yù)付費Quota”的80%。

五、總結(jié)

當(dāng)然，實際如何為MaxCompute project劃分資源組？每個資源組的min/max資源量占據(jù)“默認(rèn)預(yù)付費Quota”的百分比多少？需要綜合考慮不同MaxCompute project內(nèi)部的數(shù)據(jù)處理任務(wù)的優(yōu)先級、任務(wù)之間依賴關(guān)系、任務(wù)錯峰運行情況，還需要特別考慮某些超大型數(shù)據(jù)計算任務(wù)是否有必要與其他普通任務(wù)進行資源組隔離。

?

原文鏈接
本文為阿里云原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。