使用split_size優化的ODPS SQL的場景

使用split_size優化的ODPS SQL的場景

首先有兩個大背景須要說明以下：
說明1：split_size，設定一個map的最大數據輸入量，單位M，默認256M。用戶能夠經過控制這個變量，從而達到對map端輸入的控制。設置語句：set odps.sql.mapper.split.size=256。通常在調整這個設置時，每每是發現一個map instance處理的數據行數太多。

說明2：小文件越多，須要instance資源也越多，MaxCompute對單個Instance能夠處理的小文件數限制爲120個，如此形成浪費資源，影響總體的執行性能（文件的大小小於塊Block 64M的文件）。

場景一：單記錄數據存儲太少

原始Logview Detail：

能夠發現Job只調起一個Map Instance，供處理了156M的數據，但這些數據共有5千多萬的記錄（單記錄平均3個byte），花費了25分鐘。
此外，從TimeLine看能夠發現，整個Job耗費43分鐘，map佔用了超過60%的時間。故可對map進行優化。

優化手段：調小split_size爲16M

優化以後的logview：

優化後，能夠發現，Job調起了7個Map Instance，耗時4分鐘；某一個Map處理了27M的數據，6百萬記錄。（這裏能夠看出set split_size只是向Job提出申請，單不會嚴格生效，Job仍是會根據現有的資源狀況等來調度Instance）由於Map的變多，Join和Reduce的instance也有增長。整個Job的執行時間也降低到7分鐘。

場景二：用MapJoin實現笛卡爾積

原始logview：

能夠發現，Job調起了4個Map，花費了3個小時沒有跑完；查看詳細Log，某一個Map由於笛卡爾的緣故，生成的數據量暴漲。
綜合考慮，由於該語句使用Mapjoin生成笛卡爾積，再篩選符合條件的記錄，兩件事情都由map一次性完成，故對map進行優化。

策略調低split_size
優化後的logview：

優化後，能夠看到，Job調度了38個map，單一map的生成數據量降低了，總體map階段耗時也降低到37分鐘。
回頭追朔這個問題的根源，主要是由於使用mapjoin笛卡爾積的方式來實現udf條件關聯的join，致使數據量暴漲。故使用這種方式來優化，看起來並不能從根本解決問題，故咱們須要考慮更好的方式來實現相似邏輯。

 

---

本文做者：禕休

原文連接

本文爲雲棲社區原創內容，未經容許不得轉載。