現象：同樣的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掃描這部分數據時輸入量也隨之更大費用就上漲。
可能還有其他的情況目前還沒遇到，大家如果出現這類問題，不妨自己做一下分析。