使用split_size優(yōu)化的ODPS SQL的場(chǎng)景

首先有兩個(gè)大背景需要說明如下：
說明1：split_size，設(shè)定一個(gè)map的最大數(shù)據(jù)輸入量，單位M，默認(rèn)256M。用戶可以通過控制這個(gè)變量，從而達(dá)到對(duì)map端輸入的控制。設(shè)置語句：set odps.sql.mapper.split.size=256。一般在調(diào)整這個(gè)設(shè)置時(shí)，往往是發(fā)現(xiàn)一個(gè)map instance處理的數(shù)據(jù)行數(shù)太多。

說明2：小文件越多，需要instance資源也越多，MaxCompute對(duì)單個(gè)Instance可以處理的小文件數(shù)限制為120個(gè)，如此造成浪費(fèi)資源，影響整體的執(zhí)行性能（文件的大小小于塊Block 64M的文件）。

場(chǎng)景一：單記錄數(shù)據(jù)存儲(chǔ)太少

原始Logview Detail：

可以發(fā)現(xiàn)Job只調(diào)起一個(gè)Map Instance，供處理了156M的數(shù)據(jù)，但這些數(shù)據(jù)共有5千多萬的記錄（單記錄平均3個(gè)byte），花費(fèi)了25分鐘。
此外，從TimeLine看可以發(fā)現(xiàn)，整個(gè)Job耗費(fèi)43分鐘，map占用了超過60%的時(shí)間。故可對(duì)map進(jìn)行優(yōu)化。

優(yōu)化手段：調(diào)小split_size為16M

優(yōu)化之后的logview：

優(yōu)化后，可以發(fā)現(xiàn)，Job調(diào)起了7個(gè)Map Instance，耗時(shí)4分鐘；某一個(gè)Map處理了27M的數(shù)據(jù)，6百萬記錄。（這里可以看出set split_size只是向Job提出申請(qǐng)，單不會(huì)嚴(yán)格生效，Job還是會(huì)根據(jù)現(xiàn)有的資源情況等來調(diào)度Instance）因?yàn)镸ap的變多，Join和Reduce的instance也有增加。整個(gè)Job的執(zhí)行時(shí)間也下降到7分鐘。

場(chǎng)景二：用MapJoin實(shí)現(xiàn)笛卡爾積

原始logview：

可以發(fā)現(xiàn)，Job調(diào)起了4個(gè)Map，花費(fèi)了3個(gè)小時(shí)沒有跑完；查看詳細(xì)Log，某一個(gè)Map因?yàn)榈芽柕木壒?#xff0c;生成的數(shù)據(jù)量暴漲。
綜合考慮，因?yàn)樵撜Z句使用Mapjoin生成笛卡爾積，再篩選符合條件的記錄，兩件事情都由map一次性完成，故對(duì)map進(jìn)行優(yōu)化。

策略調(diào)低split_size
優(yōu)化后的logview：
![]

優(yōu)化后，可以看到，Job調(diào)度了38個(gè)map，單一map的生成數(shù)據(jù)量下降了，整體map階段耗時(shí)也下降到37分鐘。
回頭追朔這個(gè)問題的根源，主要是因?yàn)槭褂胢apjoin笛卡爾積的方式來實(shí)現(xiàn)udf條件關(guān)聯(lián)的join，導(dǎo)致數(shù)據(jù)量暴漲。故使用這種方式來優(yōu)化，看起來并不能從根本解決問題，故我們需要考慮更好的方式來實(shí)現(xiàn)類似邏輯。

?

一站式開發(fā)者服務(wù)，海量學(xué)習(xí)資源0元起！
阿里熱門開源項(xiàng)目、機(jī)器學(xué)習(xí)干貨、開發(fā)者課程/工具、小微項(xiàng)目、移動(dòng)研發(fā)等海量資源；更有開發(fā)者福利Kindle、技術(shù)圖書幸運(yùn)抽獎(jiǎng)，100%中--》https://www.aliyun.com/acts/product-section-2019/developer?utm_content=g_1000047140

原文鏈接
本文為云棲社區(qū)原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。

總結(jié)

以上是生活随笔為你收集整理的使用split_size优化的ODPS SQL的场景的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。