现象：同样的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扫描这部分数据时输入量也随之更大费用就上涨。
可能还有其他的情况目前还没遇到，大家如果出现这类问题，不妨自己做一下分析。
