精打細算使用MaxCompute搭建數倉
原文鏈接:http://click.aliyun.com/m/43695/
MaxCompute是一套阿裏自主研發的數據倉庫解決方案。產品除了功能、性能、簡單等優勢外,還能在費用上節省下一大筆前。墨跡天氣使用MaxCompute,除了性能和穩定性也有提升外,整體存儲和計算的費用比之前節省70%。這是如何做到的呢,這裏有一些常用的規則。
在討論如何做到之前,我們先看下MaxCompute是如何計費的。根據目前的文檔,目前的計費方式包含數據的存儲、數據的下載以及計算費用。其中計算費用又分I/O後付費和預付費兩種收費模式。I/O後付費根據實際的計算來進行收費;而預付費相當於包了幾個CU只有購買者可以使用,這幾個CU上隨便怎麽計算都不會產生計算費用。所以如何減少費用,也就是轉換成如何減少存儲的費用、如何減少下載的費用以及如何減少計算的費用。
存儲
數據存儲在MaxCompute上是使用列式存儲並有壓縮的,底層數據存儲方式不需要用戶自己維護。但是用戶可以通過減少存儲在MaxCompute上的數據量來減少存儲的費用。可以通過及時刪除不需要的數據來減少存儲費用。這裏需要推薦用一個叫生命周期(lifecycle)的功能來定時回收過期的數據。設置了生命周期後,如果是分區表,分區表裏的某個分區如果在指定的時間內數據沒發生變更,系統會認為這個分區已經不需要了,會自動刪除這個分區。如果是非分區表的話,指定的時間內沒有數據變化就會刪除這整張表。這個功能可以用來配置到一些歷史記錄表上,比如說如果不想要一年之前的歷史記錄,可以把表根據寫入時間做分區,然後設置生命周期為一年。數據寫入的時候,每天數據只寫入到當天的那個分區裏。一年後,之前的數據因為一整年都沒有數據寫入,觸發生命周期的條件,並後臺定時作業刪除對應的分區裏的數據。
在實際使用中,除了因為沒及時刪除過期不要的歷史記錄造成的額外的存儲費用外,更多的是因為對數據的管理不到位導致的一些不需要的表一直沒刪除導致的空間占用。仔細想想,在做查詢的時候使用Create table xx as select先存了一些臨時表,用好沒刪除一直放著占用從存儲空間,這種事情應該每個人都做過一些。但是如果你真的要去找找哪些數據需要刪除,哪些數據是業務數據不能動的時候,對著list tables;出來的幾百幾千張表也是很無從下手吧。對數據倉庫做好分層,做好命名規範,對於每一層根據使用需要配置不同的生命周期回收策略,用一個好的數據管理來保證數據倉庫的表的有序存儲,不僅能節省一筆存儲的錢,也能在實際使用的時候,快速找到需要的表,便於數據的管理和使用。而如果有一些計算過程產生的臨時表,後續又確定用不到的,可以在計算結束及時刪除。具體可以參考祎休寫的基於阿裏雲數加的企業大數據倉庫架構建設思路有比較詳細的說明。
下載
下載數據並非全部都會收費的,有一些情況下數據下載也不會產生費用。合理利用這些規則,選擇正確的下載方式就能減少下載的費用(而且下載不收費的方式也正好是下載最快的方式)。具體的規則可以參考文檔。
另外下載的費用,還和下載的文件的大小有關系。通過合理的表結構設置和數據生成方式,把每次需要下載的數據放到一張表(或一個分區)裏,減少下載量也是減少費用的一種策略。比如說需要下載3年級的學生信息的時候,下載全部的學生信息後再執行過濾,肯定比不過先根據年級對學生進行分區,然後只下載3年級的分區來的方法好。
計算
計算裏需要註意的相對會多一些。不過我們還是先看看計算的費用和什麽有關。先說I/O後付費,現在暫時還只是收取了SQL的費用,所以本文也只講SQL的部分。看到SQL的費用是根據輸入的數據量和SQL的算法復雜度有關的。
計算引擎在計算的時候,合理設置表的分區字段可以減少數據的輸入量。關於分區可以參考這裏。計算引擎在做執行計劃解析的時候,如果發現查詢過濾條件是用分區字段做過濾的時候,可以只讀計算涉及的分區的數據,從而減少輸入的數據量。
除了減少輸入的數據量,減少計算復雜度也是一種方法。算法復雜度的優化一般涉及到代碼層面的優化,而且有時候需要和業務結合起來。比如前面已經有過一些數據預處理知道本次計算的數據某個字段沒有重復,那這次計算的時候就可以少加一次distinct或者group by。通過代碼層面結合業務邏輯,一起優化SQL語句減少計算的復雜度,是減少計算費用的一種方法。
另外減少計算的次數也是一種方法。比如某幾個計算都需要用到某個實時表的數據,而且都是在某種過濾和匯總之後的再加工,那完全可以把中間可以復用的計算過程保存下來,在數據倉庫上做適量的輕度匯總甚至高度匯總。後續的計算可以拿匯總數據再做進一步的計算。這樣雖然中間多存了一些數據,但是後續的計算的時候可以少算一些邏輯。這是數據倉庫裏經常用到的空間換時間的方法。配合之前提到的生命周期,可以用最小的存儲費用的代價獲得最大的計算費用的減少。當然合理利用這種方法,除了可以減少計算費用外,因為減少重復計算,也可以減少計算的時間提高效率。
除了以上提到的這些,也可以考慮後付費的方式來跑計算,也就是計算費用是包年包月的。一般來說,滿足以下條件可以考慮使用後付費
任務大部分是周期任務,任務量比較均勻。如果任務以偶發性的臨時查詢為主可能不合適用後付費
任務的提交事件比較分散,如果都集中在某個時間點一起算的,也不太合適
經過一段時間的試運行,任務數量已經基本可以估計,不會短期內有比較的明顯的增加或者減少
如果不滿足這些 條件,者很容易出現在高峰期購買的CU不夠用,任務出現排隊;低谷的時候資源又利用不起來,造成浪費。
其他
關於費用,其實還有兩個非常關鍵的問題
1.我每天都花了多少錢,如何優化?
可以參考這裏,看看每天的賬單,通過檢查裏面的計算、存儲和下載分別產生了多少費用。從而從對應的角度去做優化。另外也可以在表格裏做金額的排序,看看金額最高的幾筆費用是什麽費用,看看能否針對性做一些優化。
2.我這個SQL提交後會產生多少費用?
如果產生的費用都不清楚,那提交一個SQL時心裏是沒底的。在大數據開發套件的數據開發裏,跑SQL會跳出消費提醒,從而提前知道提交後會產生的費用。如果發現金額特別高,可以考慮先做一些優化後再提交以免產生不必要的費用。如果是直接在MaxCompute客戶端裏跑SQL的話,可以用cost sql <SQL Sentence>;估算SQL的費用。
識別以下二維碼,閱讀更多幹貨
精打細算使用MaxCompute搭建數倉