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

发布于 3月13日  约 4 分钟

现象:因业务需求新增了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分区裁剪也会失效。

上云就看云栖号:更多云资讯,上云案例,最佳实践,产品入门,访问:https://yqh.aliyun.com/

本文为阿里云原创内容,未经允许不得转载。

阅读 89发布于 3月13日

推荐阅读
阿里云栖社区
用户专栏

汇集阿里技术精粹-yq.aliyun.com

11600 人关注
1539 篇文章
专栏主页
目录