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分區裁剪也會失效。

上雲就看雲棲號：更多雲資訊，上雲案例，最佳實踐，產品入門，訪問：https://yqh.aliyun.com/

本文爲阿里雲原創內容，未經容許不得轉載。