幫助企業作好MaxCompute大數據平臺成本優化的最佳實踐

時間 2019-12-19

標籤幫助企業作好 maxcompute 數據平臺成本優化最佳實踐简体版

原文原文鏈接

阿里雲大數據計算服務MaxCompute經過靈活性、簡單性和創新爲您企業的業務環境帶來了變革，可是您企業是否經過其實現了本來預期的節省成本的目標呢?本文中，咱們將爲廣大讀者諸君介紹優化您企業MaxCompute開銷的一些關鍵性的策略。　　html

自從MaxCompute於2010年進入市場以來，計算服務MaxCompute就已然永遠地改變了整個IT世界了。儘管其價格優點已經領先業界了，但仍然有許多企業客戶瞭解到，遷移到公共雲服務並不老是可以幫助他們實現預期的成本節約的目標。
這並不意味着遷移到公共雲服務是一個錯誤。公共雲服務在敏捷性、響應性、簡化操做和提升創新方面提供了巨大的優點。前端

這方面的錯誤在於：假設在不實施管理和自動化的狀況下遷移到公共雲服務，也能帶來成本的節約。爲了應對不斷上漲的雲基礎設施成本，咱們建議您企業組織不妨參考和借鑑本文中所介紹的這些最佳實踐方案，以減低和優化成本，並實現您企業環境的價值最大化。java

接下來，咱們主要從計算、存儲、數據同步、平常帳單分析幾個點來展開優化實踐，幫助企業作到節省預算。sql

優化控制計算成本

一、經過計費提醒估算計算成本

1.1 使用DataWorks 成本估計提醒

step1 經過DataWorks進入 Project工做區數據庫

step2 進入數據開發網絡

step3 新建腳本文件函數

step4 輸入SQL後，點擊「成本估計「按鈕。工具

1.2 使用Cost SQL費用計算

step1 啓動MaxCompute客戶端 ;安裝及配置項目參照：https://help.aliyun.com/document_detail/27804.html性能

step2 輸入cost +sql語句計費估算代碼：測試

step3 根據返回的輸入數據量*複雜度*0.3元/GB/複雜度估算價格。

Input:44066219424 Bytes/10243 x Complexity:1.0 x 0.3元/GB/複雜度 =12.31元

1.3 使用MaxCompute Stuido費用計算

step1 啓動MaxCompute Stuido客戶端 ;安裝及配置項目參照：https://help.aliyun.com/document_detail/50892.html

step2 輸入cost +sql語句計費估算代碼獲取估算量：

step3根據返回的輸入數據量*複雜度*0.3元/GB/複雜度估算價格。Input:919168 Bytes/10243 x Complexity:1.0 x 0.3元/GB/複雜度 =2.57元

1.4 使用產品價格計算器

目前價格計算器支持預付費估算，

step1 打開計算器計算器：https://www.aliyun.com/price/product#/maxcompute/calculator

step2 輸入所須要的存儲數量量（GB、TB或PB）

step3 輸入查詢所須要的計算資源CU（最低10CU），輸入數據下載量（GB、TB或PB），系統能夠爲您自動估算費用。

二、經過優化SQL來控制計算成本

作優化前，你們先來了解一下MaxCompute SQL的技術原理，對後續的優化工做會更加容易理解。

https://help.aliyun.com/document_detail/27989.html

2.1 列裁剪

在讀數據的時候，只讀取查詢中須要用到的列，而忽略其餘列，避免使用select * 全表掃描引發的錯誤及資源浪費。例如，對於查詢：

其中，T 包含 5 個列 (a,b,c,d,e)，列 c，d 將會被忽略，只會讀取a, b, e 列

2.2 分區裁剪

分區剪裁是指對分區列指定過濾條件，使得只讀取表的部分分區數據，避免全表掃描引發的錯誤及資源浪費。例如，對於下列查詢：

partitiondate =「2017-10-01」只掃描2017年10月1日的分區

分區裁剪注意事情：

用戶常常以爲已經對分區列作了限制了，但實際仍是產生了大量費用。咱們看一下如何作好分區裁剪，https://lark.alipay.com/eric.jia/maxcompute_0/ap0ei5

2.3 SQL關鍵字的優化

有一些優化方式官網上已經寫出來了，好比避免使用select *，讀取分區表時必定要對分區進行過濾。其餘的優化方式就須要咱們本身去摸索了。

計費的SQL關鍵字包括：Join / Group By / Order By / Distinct /窗口函數/ Insert into

減小full outer join的使用，改成union all；

在union all內部儘量不使用group by，改成在外層統一group by；

臨時導出的數據若是須要排序，儘可能在導出後使用excel等工具進行排序，避免使用order by；

根據優化原則，儘可能避免使用distinct關鍵字，改成多套一層group by；

儘可能避免使用Insert into方式寫入數據，能夠考慮增長一個分區字段；

做用：經過下降SQL複雜度，來節省SQL的費用。

2.4 禁止全表掃描

您能夠經過設置參數來關閉全表掃描功能，這樣也能夠避免過分資源浪費。

例如，

說明：限制掃描全表。默認狀況下true，容許掃描全表；不然爲false，若是掃描全表，則拋異常。

2.5 不要運行查詢來探索或預覽表數據

若是您想預覽表數據，可使用表預覽選項查看數據，而不會產生費用。

MaxCompute支持下列數據預覽選項：

在DataWorks用戶界面中，在數據開發-表查詢信息頁上，單擊表進行數據預覽。

在CLT使用read命令並指定預覽的行數。

在MaxCompute Studio雙擊表進行表數據預覽。

2.6 在經過MaxCompute計算和經過RDS計算中尋找平衡

因爲MaxCompute的查詢響應是分鐘級，不適合直接用於前端查詢。因此計算出的結果數據都會被保存到外部存儲中，而對於大部分人來講，關係型數據庫是最優先的選擇。

因此這裏就會涉及到一個「度」的問題。要把數據計算到什麼程度，纔會存放到MYSQL中？

（好比如今的用戶登錄日誌表、用戶維度表）

（好比近一週各省份、地市登錄人數、近一週天天登錄人數、近一週每種註冊渠道的登錄人數）

徹底計算

直接出最終結果。前端展現時，不作任何判斷、聚合、關聯字典表、甚至不帶where條件。

（結果表1：省份ID、省份名稱、地市ID、地市名稱、登錄人數）

（結果表2：日期、登錄人數）

（結果表3：註冊渠道ID、註冊渠道描述、登錄人數）

理解難度：1⭐

溝通難度：1⭐

MaxCompute費用：4⭐

下行流量：2⭐

離線數據維護成本：2⭐

適度計算

後續關聯字段表等簡單步驟直接在關係型數據庫中計算

（結果表1：省份ID、地市ID、登錄人數）

（結果表2：日期、登錄人數）

（結果表3：註冊渠道ID、登錄人數）

理解難度：2⭐

溝通難度：2⭐

MaxCompute費用：3⭐

下行流量：1⭐

離線數據維護成本：1⭐

輕度計算

後續大量計算任務直接在關係型數據庫中計算

（結果表：用戶ID、登錄日期、省份ID、地市ID、註冊渠道ID）

理解難度：5⭐

溝通難度：5⭐

MaxCompute費用：2⭐

下行流量：5⭐

離線數據維護成本：1⭐

三、MR做業計算控制成本

作優化前，你們先來了解一下MapReduce的技術原理，對後續的優化工做會更加容易理解。https://help.aliyun.com/document_detail/27875.html?spm=5176.100239.blogcont78108.99.BPYOnj#h1-u5904u7406u6D41u7A0B

3.1 設置合理的參數

split size

map默認的split size是256MB，split size的大小決定了map的個數多少，若是用戶的代碼邏輯比較耗時，map須要較長時間結束，能夠經過JobConf#setSplitSize方法適當調小split size的大小。然而split size也不宜設置過小，不然會佔用過多的計算資源。

MapReduce reduce instance

單個 job 默認 reduce instance 個數爲 map instance 個數的1/4，用戶設置做爲最終的 reduce instance 個數，範圍 [0, 2000]，數量越多，計算時消耗越多，成本越高，應合理設置。

3.2 MR減小中間環節

若是有多個MR做業，之間有關聯關係，前一個做業的輸出是後一個做業的輸入，能夠考慮採用Pipeline的模式，將多個串行的MR做業合併爲一個，這樣能夠用更少的做業數量完成一樣的任務，一方面減小中間落表形成的的多餘磁盤IO，提高性能；另外一方面減小做業數量使調度更加簡單，加強流程的可維護性。具體使用方法參見Pipeline示例。

3.3 輸入表的列裁剪

對於列數特別多的輸入表，Map階段處理只須要其中的某幾列，能夠經過在添加輸入表時明確指定輸入的列，減小輸入量；
例如只須要c1,c2倆列，能夠這樣設置：

設置以後，你在map裏的讀取到的Record也就只有c1,c2倆列，若是以前是使用列名獲取Record數據的，不會有影響，而用下標獲取的須要注意這個變化。

3.4 避免資源重複讀取

資源的讀取儘可能放置到setup階段讀取，避免資源的屢次讀取的性能損失，另外系統也有64次讀取的限制，資源的讀取參見使用資源示例。

3.5 減小對象構造開銷

對於Map/Reduce階段每次都會用到的一些java對象，避免在map/reduce函數裏構造，能夠放到setup階段，避免屢次構造產生的開銷；

3.6 合理選擇partition column或自定義partitioner

合理選擇partition columns，可使用JobConf#setPartitionColumns這個方法進行設置（默認是key schema定義的column），設置後數據將按照指定的列計算hash值分發到reduce中去, 避免數據傾斜致使做業長尾現象，若有必要也能夠選擇自定義partitioner，自定義partitioner的使用方法以下：

在jobconf裏進行設置：

另外須要在jobconf裏明確指定reducer的個數：

3.7 合理使用combiner

若是map的輸出結果中有不少重複的key，能夠合併後輸出，combine後能夠減小網絡帶寬傳輸和必定shuffle的開銷，若是map輸出原本就沒有多少重複的，就不要用combiner，用了反而可能會有一些額外的開銷。combiner實現的是和reducer相同的接口，例如一個WordCount程序的combiner能夠定義以下：

四、計費模式轉換

4.1 後付費轉預付費

當後付費產生的帳單超出您的企業預算時，您能夠轉換爲預付費，將CU計算資源包月。

注意事項：請合理評估計算做業性能與時間關係，不少企業轉爲預付費後，因爲購買的CU數量少，做業計算週期長，達不到預期，又轉回後付費。

合理預估預付費CU資源方法參照（僅供參考）：

SQL估算資源建議：show -p後，經過logview查看歷史做業平均消耗的worker數量，一個worker 近似1CU；

MR估算資源建議：show -p後，經過logview查看歷史做業平均消耗的cost * min計算時，cost數量近似CU。

4.2 預付費+後付費混合模式

當企業預算有限時，能夠選擇此模式，將非週期性的大規模數據處理做業放到後付費模式上。將週期性的消耗計算資源少的做業放到預付費模式。數據能夠存儲在預付費模式下，後付費模式不用存儲數據，經過跨表計算省去一份存儲成本。注意：不一樣帳號下跨表計算須要經過Grant受權來實現，參考：https://help.aliyun.com/document_detail/27927.html

案例分析：這個案例是後付費月帳單1萬元的3個月計算消耗明細，Max最大200CU，平時用到30CU；

此方案的結構能夠優化爲：

最經濟型：月4500元（30CU，不預留水位）+1800 元(1000GB數據*1.5複雜度*0.3元/GB/複雜度*4次)，節節省：3700元/月，雖然節省較多，但數據業務的增加會遇到水位線瓶頸，須要按期擴展CU。

次經濟性：月7500元（50CU，預留30%水位）+1800 元(1000GB數據*1.5複雜度*0.3元/GB/複雜度*4次)

節省：節省800元/月，雖然節省少，但資源還比原來更充裕了。

優化控制存儲成本

一、設置合理的表生命週期

MaxCompute中存儲資源是很是寶貴的。能夠根據數據自己的使用狀況，對錶設置生命週期，MaxCompute會及時刪除超過生命週期的數據，達到節省存儲空間的目的。好比

建立一張生命週期爲100的表。若是這張表或者分區的最後修改時間超過了100天將會被刪掉。須要注意的是生命週期是以分區爲最小單位的，因此一個分區表，若是部分分區達到了生命週期的閥值，那麼這些分區會被直接刪掉，未達到生命週期閥值的分區不受影響。
另外能夠經過命令

修改已經建立好的表的生命週期。

二、合理設置數據分區

MaxCompute將分區列的每一個值做爲一個分區(目錄)。用戶能夠指定多級分區，即將表的多個字段做爲表的分區，分區之間正如多級目錄的關係。在使用數據時若是指定了須要訪問的分區名稱，則只會讀取相應的分區，避免全表掃描，提升處理效率，下降費用。

假如最小統計週期爲天，宜採用日期做爲分區字段。天天將數據覆蓋遷移到指定分區，再讀取指定分區的數據進行下游統計。

假如最小統計週期爲小時，宜採用日期+小時做爲分區字段。每小時將數據覆蓋遷移到指定分區，再讀取指定分區的數據進行下游統計。若小時調度的統計任務也按天分區，數據每小時追加，則每小時將多讀取大量的無用數據，增長的流入數據量，增長了沒必要要的費用。

分區字段不必定非得是時間，根據實際須要，也可使用其餘的枚舉值個數相對固定的字段，好比渠道、好比國家省份地市。或者使用時間和其餘字段共同做爲分區字段。

優化控制數據同步成本

一、儘量使用經典網絡和VPC網絡

經過使用內部網絡（經典網絡、VPC）實現零成本數據導入、導出。

網絡設置參考：https://help.aliyun.com/document_detail/34951.html

二、合理利用ECS的公共下載資源

不少企業客戶ECS帶寬是包月的，可使用Tunnel等數據同步工具，將MaxCompute數據同步到ECS上，而後下載到本地。下載方法參考：

https://help.aliyun.com/document_detail/53093.html

三、Tunnl文件上傳優化

當文件量小的時候，會消耗更多計算資源參與計算，建議文件量積累較大時一次性上傳，好比，用戶在調用tunnel sdk時當buffer達到64M時提交一次。

分析帳單與明細

一、帳單及時查看

養成按期查看帳單的好習慣，及時優化使用成本。經過阿里雲控制檯-消費-消費記錄-消費明細，查看MaxCompute/odps每日計費清單及帳單（計算、存儲、下載）明細。

案例分析：

場景1，查看昨天的收費狀況

出帳後，經過控制檯消費明細來查看。

出帳時間：

預付費出帳單時間第二天12點

後付費出帳單時間是第二天9點

step1 進入阿里雲控制檯-消費，https://expense.console.aliyun.com/#/

step2打開消費總覽，看到當月帳單。

step3點擊左側消費明細，根據產品分類Maxcompute及時間來篩選昨天的消費金額，https://expense.console.aliyun.com/#/consumption/list/flow/afterpay

step4點擊詳情，展開每一個項目的消費狀況，查看有無「貴」收費

如發現「貴「的項目，可根據存儲、計算、下載幾個場景對應到下面的解決方法。

場景2，分析某一天計算收費「貴「緣由

經過導出使用記錄，分析消費多的做業instance具體狀況。

step1打開消費明細後，看到帳單異常後，請到左側消費記錄下載導出使用記錄。

step2下載記錄後，打開excel表，定位異常數據的instanceid。

好比，計量信息編號20171106100629865g4iplf9這個SQL任務，產生的費用是SQL讀取量(7352600872/1024/1024/1024)*SQL複雜度 1 * 0.3元/GB/複雜度=2元，計算公式參考官網：https://help.aliyun.com/document_detail/27989.html?spm=5176.product27797.6.559.QL7dYV#h2-u6309u91CFu540Eu4ED8u8D39

step3查看這個「貴」instanceID 的logview

wait 20171106100629865g4iplf9

step4經過Logview咱們發現產生了全表掃描、長尾計算等問題，及時優化咱們的SQL/MR做業。

長尾優化參考：

場景3，分析存儲收取1分錢的緣由

經過導出使用記錄，分析消費多的存儲Storeage明細。

step1 下載記錄後，打開excel表。

step2 查看數據分類中的Storage，會發如今yinlin_test_huabei2_io Project下存儲了384字節數據。

按照官網存儲訂價規則，存儲(384/1024/1204)*0.0192元/GB不到1分錢，但官網提到小於等於512M數據最低收取1分錢。計算公式參考官網：https://help.aliyun.com/document_detail/27989.html?spm=5176.product27797.6.559.QL7dYV#h1-u5B58u50A8u8BA1u8D39

step3 若是這份數據是用來測試的，你能夠經過IDE刪除Project下的表數據。

場景4，分析數據上傳和下載是否產生了費用

部分用戶總擔憂數據同步會產生費用，咱們能夠經過分析帳單來解決。

step1 點擊消費明細詳情，查看上行、下載有無收費。

咱們能夠看到收費明細裏面並無上行計費項，因此用戶沒必要擔憂數據上傳產生了費用。

同時，咱們看到了下載產生了0.12元。

step2 經過導出使用記錄，分析消費多的下載消耗明細。

step3 能夠看到公網下行流量產生了一條約0.153GB（164223524byte）的下行流量，根據官網收費標準，0.153GB*0.8 元/GB=0.12元。計費公式參考：https://help.aliyun.com/document_detail/27989.html?spm=5176.product27797.6.559.QL7dYV#h1-u4E0Bu8F7Du8BA1u8D39

step4 下行優化

a 查看你的tunnel設置的service，是否設置成了公共網絡。參考：https://help.aliyun.com/document_detail/34951.html

b 若是你本地在蘇州，Region在華東2上海，那麼你能夠先經過華東2的ECS把數據下載到虛機，而後利用ECS包月下載資源。

結論

重要的是要記住，這些最佳實踐方法並不意味着是一次性的活動，而是持續性的過程。因爲大數據的動態性和不斷變化的性質，企業用戶成本優化的活動最好應不斷進行。