MaxCompute 費用暴漲之存儲壓縮率下降致使SQL輸入量變大

現象：一樣的SQL，天天處理的數據行數差很少，可是費用忽然暴漲甚至會翻數倍。

分析：

咱們先明確MaxCompute SQL後付費的計費公式：一條SQL執行的費用=掃描輸入量 ️ SQL複雜度 ️ 0.3(￥/GB)。

變量主要是輸入量和複雜度，若是SQL沒有變動的狀況下複雜度度也沒有變化，那麼費用上漲主要緣由就是輸入量增長，所以咱們側重從輸入量去排查是什麼環節致使來了輸入量的增長。

排查：

挑兩個job的Logview查看輸入量，推薦用MaxCompute Studio的做業對比功能查看，做業對比功能使用方式能夠參考《MaxCompute Studio使用心得系列7——做業對比》。輸入量以下：

如上圖，數據行數差異沒有翻倍，可是大小(bytes)翻倍，基本能夠排除是由於數據量暴增致使。那麼數據行數增量不大，可是數據大小翻倍，無疑翻倍的這些數據確定是有了變化，好比某些列的值長度變大那麼size就變大，這個能夠從這些數據的上游鏈路去查是否有可能某些列的值長度變的很大，若是這個也能排除，那麼就能夠考慮存儲壓縮率了。

存儲在MaxCompute裏的數據是通過壓縮後存放的，而MaxCompute的存儲計費和SQL計費涉及到的數據量都是按這些數據存在MaxCompute裏壓縮後的量統計。

MaxCompute數據存儲壓縮沒有固定比例，跟表數據有關，如平均字段長度、惟一值個數、數據類似度等，通常說來，每一個表中都有存在1個或幾個對存儲空間影響比較的字段，這些字段就是影響壓縮效果的關鍵（能夠參考相關的存儲介紹文章）。知道這個知識點，咱們再去排查費用變化的這一天，輸入的這些數據產出的方式變化狀況。

數據產出方式變化咱們遇到的兩個例子：

• 數據中的時間字段計算方式變化。原來存儲時會處理成" yyyy-mm-dd 00:00:00"格式，此時針對這個字段yyyy-mm-dd這段重複度高，對壓縮算法比較友好，最終數據的壓縮率高。以後對這個字段就不進行任何處理直接是按實際時間"yyyy-mm-dd hh:mi:ss",重複率底，存儲壓縮率就下降，從而數據的size就更大，最終SQL掃描這部分數據時輸入量也就變大因此費用就上漲。
• 數據中的敏感字段計算方式變化。原來存儲時不通過任何處理，這個字段的數據相對比較有序，壓縮率也比較高。以後這個字段通過自定義函數進行加密，加密後的數據變成隨機無序，壓縮率就底，數據的size也就更大，最終SQL掃描這部分數據時輸入量也隨之更大費用就上漲。

可能還有其餘的狀況目前還沒遇到，你們若是出現這類問題，不妨本身作一下分析。

 

本文做者：海清

原文連接

本文爲雲棲社區原創內容，未經容許不得轉載。