MaxCompute 费用暴涨之新增SQL分区裁剪失败

现象：因业务需求新增了SQL任务，这SQL扫描的表为分区表，且SQL条件里表只指定了一个分区，按指定的分区来看数据量并不大，可是SQL的费用很是高。费用比预想的结果相差几倍甚至10倍以上。

若只知道整体费用暴涨，可是没明确是什么任务暴涨，能够能够参考查看帐单详情-使用记录文档，找出费用异常的记录。

分析：咱们先明确MaxCompute SQL后付费的计费公式：一条SQL执行的费用=扫描输入量 ️ SQL复杂度 ️ 0.3(￥/GB)。

变量主要是输入量和复杂度，但实际上复杂度最高也就为4，由复杂度引发的费用暴涨是比较罕见，咱们不妨先把排查重点放在输入量上。

排查：
查看Logview的inputs信息

如上图会发现input的分区量是14个，这个与预想的（SQL条件中只指定一个分区）不一致。问题就出在这里，此时基本能够判断这个SQL的分区并无裁剪好，也就是说最终输入量不是一个分区而是多个或者全表。

输入的分区量和预计的不一致，排除SQL中确实没有对分区设置条件这因素，那么就是分区裁剪失效了。
已知的分区裁剪失效场景主要有：分区条件用了自定义函数进行裁剪；在 Join 关联时的 Where 条件中也有可能会失效。

执行explain sql语句;看执行结果，读取的分区都有哪些，如执行explain select seller_id from xxxxx_trd_slr_ord_1d where ds=rand(); 结果以下：

看上图中红框的内容，表示读取了表 xxxxx_trd_slr_ord_1d 的 1344 个分区，即该表的全部分区，若是直接执行这个sql，最终会由于全表扫描致使输入量增长从而费用增长。

关于分区裁剪失败场景(使用函数或者跟join关联有关的场景)分析能够参考文档《分区剪裁合理性评估》。你们在执行sql前若是对分区的裁剪有疑虑，不放执行一次explain sql语句;再执行SQL语句。

关于分区条件用自定义函数或者内置函数致使分区裁剪失效的解决方案：

• 内置函数目前已经都支持进行分区裁剪。

• 自定义函数须要支持分区裁剪有两种方式：

  • 在编写UDF的时候，UDF类上加入Annotation。@com.aliyun.odps.udf.annotation.UdfProperty(isDeterministic=true)

  注意： com.aliyun.odps.udf.annotation.UdfProperty定义在odps-sdk-udf.jar文件中。您须要把引用的odps-sdk-udf版本提升到0.30.x或以上。

  • 在SQL语句前设置Flag：set odps.sql.udf.ppr.deterministic = true;，此时SQL中全部的UDF均被视为deterministic。该操做执行的原理是作执行结果回填，可是结果回填存在限制，即最多回填1000个Partition。
    所以，若是UDF类加入Annotation，则可能会致使出现超过1000个回填结果的报错。此时您若是须要忽视此错误，能够经过设置Flag：set odps.sql.udf.ppr.to.subquery = false;全局关闭此功能。关闭后，UDF分区裁剪也会失效。

 

本文做者：海清 

原文连接

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