最佳資源規劃方案可以達到如下目的：

• 存儲資源

  資源充足，既能夠存儲當前的所有存量數據，也能夠存儲未來一段時間的增量數據。

• 計算資源

  • 資源充足，且無浪費，能夠滿足所有計算作業的資源需求。

  • 不同優先級的作業可以互不干擾，優先保證高優先級的作業獲取到足夠的計算資源。

  • 當某些作業需要處理龐大的數據量且耗費計算資源較多時，可以同時確保其他作業能獲取到計算資源且不會阻塞運行。

  • 能夠滿足不同時段的差異化資源需求，根據不同項目的資源使用情況按照時段劃分資源，提高資源利用率。

按照計存比規劃計算資源的流程如下：

1. 預估存儲容量。

   存儲容量=當前數據存儲量+每月預估數據增量×月數。

   在項目上線之后就可以得到當前數據存儲量。每月預估數據增量需要在項目上線兩到三個月后，根據每月增量之和除以月數得到。如果還要考慮未來數據中臺會承載更多業務、每月數據增量會變大等因素，可以將當前計算得到的每月預估數據增量值乘以倍數。

2. 預估計存比。

   按照項目開發測試階段、以及上線運行一兩個月的情況，預估計存比。

   計存比一般規劃為2~10，后續根據規劃的計存比及預估存儲容量購買計算資源：

   • 如果項目每天運行的批量處理作業很多，且SQL程序計算復雜度高，計存比推薦規劃為10。

   • 如果項目每天運行的數據批量處理作業比較少，且SQL程序計算復雜度不高，計存比推薦規劃為2。

   • 如果項目每天運行的數據批量處理作業適中，SQL程序計算復雜度也適中，計存比可以規劃為2~10之間的值。

3. 預估計算資源數量。

   根據預估的存儲容量、計存比值預估計算資源數量。計算資源數量=預估存儲容量×預估計存比。

   說明

   按照計存比預估項目會消耗的計算資源數量時，存儲容量、計存比都屬于預估項，不夠精準。因此，該方法要求項目的技術負責人需要擁有較多的項目實施經驗，能夠在每一步預估都盡可能保證準確。

按照項目實際消耗的計算資源數量規劃計算資源的流程如下：

1. 查看項目的CPU消耗量。

   Information Schema提供的TASKS_HISTORY視圖記錄了MaxCompute項目中所有計算作業消耗的計算資源情況。您可以通過MaxCompute客戶端查詢TASKS_HISTORY視圖中的cost_cpu字段，基于該字段進一步計算消耗的資源數量。查詢TASKS_HISTORY視圖的命令示例如下：

   select * from information_schema.tasks_history where ...;

   cost_cpu代表MaxCompute計算作業的CPU消耗量。例如10 core運行5s，cost_cpu為10（CPU核數消耗量）×100（1 core×s）×5（任務運行時間，單位為秒）=5000。

2. 規劃計算資源數量。

   1. 計算賬戶下所有項目平均每天運行所有作業消耗的cost_cpu總和。

      假設某個MaxCompute項目平均每天會運行1000個作業，這些作業消耗的cost_cpu分別是W1~W1000。計算W1~W1000的和即可得到平均每天運行所有作業消耗的cost_cpu總和，假設總和為Wz。

      說明

      通常，數據中臺一般會劃分如下6個MaxCompute項目：

      • ods_dev：貼源層開發測試項目

      • ods_prod：貼源層生產項目

      • cdm_dev：公共層開發測試項目

      • cdm_prod：公共層生產項目

      • ads_dev：應用層開發測試項目

      • ads_prod：應用層生產項目

      該情況下，您需要計算上述6個項目的所有計算作業的cost_cpu總和。

   2. 基于計算得到的cost_cpu總和進行換算。

      因為cost_cpu按照秒統計，對于實際項目評估過于精細，通常將cost_cpu除以100，然后再除以3600，得到core×h（CPU核數消耗量×小時）。這樣方便評估實際項目在規定時間段內運行完所有作業需要的最少計算資源數量。假設該值為W。

   3. 確認作業需要在每天的哪些時間段完成運行。

      例如，客戶要求在00:00:00~06:00:00間所有數據批量處理作業必須完成運行。即每天能夠運行的總時長是6個小時。本文假設所有作業必須在N個小時內完成運行。

   4. 預估需要購買的計算資源最小值。

      基于前兩步得到的值（W和N）進行運算：W（CPU核數消耗量×小時）/N（作業運行時長N個小時），即可得到MaxCompute項目需要購買的計算資源數量的最小值。

      計算W/N的前提是數據處理作業的cost_cpu很穩定，而且在這N個小時內，所有作業都隨時在運行，不存在任何空閑的計算資源。但是，實際項目可能會因為某些原因導致作業運行時間延長（例如參與計算的數據量增加），相當于W會變大。同時，由于通過DataWorks或Dataphin運行調度作業還會產生很多延遲時間、作業獲取計算資源也會耽誤很多時間，這部分延遲時間會加大作業之間運行的時間間隔，真正用于運行作業的時間會小于N。W/N的分母實際變大、分子實際變小，進而變相地要求增加計算資源，以便讓作業獲取更多資源進而運行更加快速。因此，建議您在W/N結果基礎上增加一倍。