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扫描这部分数据时输入量也随之更大费用就上涨。

可能还有其余的状况目前还没遇到，你们若是出现这类问题，不妨本身作一下分析。

原文连接 本文为云栖社区原创内容，未经容许不得转载。