MaxComputeSql性能調優

摘要：   部分用戶(尤爲對外輸出)使用MaxCompute(原Odps)時，因爲對產品的使用層面和執行層面瞭解程度不一樣，致使提交的任務執行時間過長、佔用了較多集羣資源；嚴重的會致使失敗、不只須要投入支持同窗精力協助解決、也影響了用戶正常業務。 合併整理部分性能提高方法方

 

 轉載自xiaorui

   

 部分用戶(尤爲對外輸出)使用MaxCompute(原Odps)時，因爲對產品的使用層面和執行層面瞭解程度不一樣，致使提交的任務執行時間過長、佔用了較多集羣資源；嚴重的會致使失敗、不只須要投入支持同窗精力協助解決、也影響了用戶正常業務。 合併整理部分性能提高方法方便支持用戶查詢和優化Sql，提升效率；部分須要原來手動調優的如mapjoin、ppd謂詞下推注意分區位置等原有的調優設置在不斷衍進的產品中都已實現了自動化調優、 不一樣階段的產品調優參數和細節會有不一致、可是熟悉了調優思路和方法後能夠作到觸類旁通、逐步深刻。

 

一. 總體思路

 

      總體上，調優從底層到sql能夠有多個層面的調優，隨着產品的不斷完善，部分調優已經實現了自動化。若是用戶能熟悉常見的調優機制和執行原理，在開發執行sql、業務邏輯和相關參數設置調整來提升性能、能夠作到事半功倍。

 

      1.硬件及操做系統層面調優：包括磁盤I/O調優（多路複用等）、網絡調優（緩衝區大小、鏈接數放大等）、內存調優（虛擬內存設置、內存控制等）；

      2. 分佈式計算平臺及存儲層面調優：存儲格式設置、壓縮格式設置、RPC調用設置、鏈接數控制設置、調度機制設置、block及分片設置、執行資源設置等；

      3. 業務邏輯層面及參數調整，除總體執行的調優外，對不一樣類型的操做進行參數級別的調優、針對聚合、鏈接、一讀多寫等修改成不一樣的sql或者設置不一樣的參數能夠極大的提升性能；      

      4. Sql層面及應用層面的調優，重構sql寫法、合併sql，大小錶鏈接修改成mapjoin等，在odps2.0中已處理了自動mapjoin等、目前未升級用戶及對外輸出的用戶仍須要修改sql來支持；

      不一樣層面調優及優缺點見下：

 

二. 場景及調優列舉

 

1. 大小表關聯修改成mapjoin，增長Mapjoin hint

 

方法及注意事項：

全部指定的小表佔用的內存總和不超過 512M

多表Join時，最左邊的兩個表，不能同時是 Mapjoin 的表

不一樣的關聯方式（left/right/inner)，對錶的順序有要求

left outer join 左表必須爲大表

right outer join 右表必須爲大表

inner join 左右表皆可爲大表

full outer join 不能直接使用 mapjoin，修改成mapjoin + union all

最新的發佈版本上已經支持了automapjoin，能夠根據join表的大小自動把小錶轉爲mapjoin，對部分沒有顯示增長hint的sql和中間結果爲小表的sql進行自動優化

 

2. 數據傾斜

 

數據傾斜表現:

任務進度長時間維持在99%，查看監控，只有少許 reduce 子任務未完成

單一 reduce 記錄數與平均記錄數差別多大，最長時長遠大於平均時長

優化方法及注意事項：

 

聚合傾斜，設置參數：set odps.sql.groupby.skewindata=true

關聯傾斜，設置參數:set odps.sql.skewinfo=tab1:(col1,col2)[(v1,v2),(v3,v4),...|(v1,v2),(v3,v4),...];set odps.sql.optimize.skewjoin=true

關聯傾斜，同時大小表，考慮修改成mapjoin

具體問題具體分析：由於聚合key值null引發的數據傾斜，能夠修改null爲隨機值，打撒數據分發到不一樣的instance執行

 

3. Map 端一讀多寫

 

場景及優化：

屢次讀取同一張物理表，執行不一樣操做，寫入多張表；考慮與multiinsert 的聯繫和區別，是否合適作修改

創建臨時表，實現臨時表的並行化

 

注意事項：

 

優勢：大大節省了集羣的計算資源和磁盤I/O資源

缺點：寫的次數很是多時，可能致使性能問題，影響任務總體執行效率

 

4 分區裁剪

 

場景：事實表不少分區，數據量大

優化：避免全表掃描，減小資源浪費；關注分區裁剪有無生效，見下注意事項：從表設計、使用上注意，儘可能讓分區裁剪生效

注意事項：

過濾條件中的分區列上有UDF 則分區裁剪生效

表關聯時關聯條件中包含分區列：

出如今 on 條件中，分區裁剪生效

出如今 where 條件中，主表分區裁剪生效，其他可能失敗

 

5. SQL 合併

 

場景：

1. 屢次讀取相同的數據且源數據數據量大、性能差、費用高

2. 統一業務流程先後關聯sql或統計多種指標、篩選不一樣數據的sql

優化方法及注意事項：經過修改sql，合併爲1個sql執行，儘可能減小對相同數據源的讀取次數，達到一次掃描計算多個基礎統計量，一次掃描，處理多個篩選條件；如下調整列舉：

 

CASE … WHEN…：合併相同數據源的不一樣子查詢的關聯

動態分區&多路插入等：將知足不一樣條件的會員統計信息插入到不一樣的表或表分區中去

先後流程sql合併爲1個sql執行

 

6 使用窗口函數優化SQL

 

窗口函數：

1. 能夠進行靈活的分析處理工做

2. 使用 partition by 開窗，order by 排序

3. 能夠用 rows 指定開窗範圍

4.豐富的開窗函數

 

優化及注意事項：合理使用窗口函數，能夠減小Join次數，提升運行性能;不用窗口函數處理須要寫複雜sql的功能，用開窗函數能夠高效執行獲得預期結果。

 

原文連接

閱讀更多幹貨好文，請關注掃描如下二維碼：