現象：因業務需求新增了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分區裁剪也會失效。

原文鏈接
本文為云棲社區原創內容，未經允許不得轉載。

總結

以上是生活随笔為你收集整理的MaxCompute 费用暴涨之新增SQL分区裁剪失败的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。