作者:dantezhao?|?簡書?|?CSDN?|?GITHUB
文章推薦:http://dantezhao.com/readme
個(gè)人主頁:http://dantezhao.com
0x00 前言
數(shù)據(jù)傾斜是大數(shù)據(jù)領(lǐng)域繞不開的攔路虎,當(dāng)你所需處理的數(shù)據(jù)量到達(dá)了上億甚至是千億條的時(shí)候,數(shù)據(jù)傾斜將是橫在你面前一道巨大的坎。
邁的過去,將會海闊天空!邁不過去,就要做好準(zhǔn)備:很可能有幾周甚至幾月都要頭疼于數(shù)據(jù)傾斜導(dǎo)致的各類詭異的問題。
文章結(jié)構(gòu)
先大致解釋一下什么是數(shù)據(jù)傾斜再根據(jù)幾個(gè)場景來描述一下數(shù)據(jù)傾斜產(chǎn)生的情況詳細(xì)分析一下在Hadoop和Spark中產(chǎn)生數(shù)據(jù)傾斜的原因如何解決(優(yōu)化)數(shù)據(jù)傾斜問題?0x01 什么是數(shù)據(jù)傾斜
簡單的講,數(shù)據(jù)傾斜就是我們在計(jì)算數(shù)據(jù)的時(shí)候,數(shù)據(jù)的分散度不夠,導(dǎo)致大量的數(shù)據(jù)集中到了一臺或者幾臺機(jī)器上計(jì)算,這些數(shù)據(jù)的計(jì)算速度遠(yuǎn)遠(yuǎn)低于平均計(jì)算速度,導(dǎo)致整個(gè)計(jì)算過程過慢。
一、關(guān)鍵字:數(shù)據(jù)傾斜
相信大部分做數(shù)據(jù)的童鞋們都會遇到數(shù)據(jù)傾斜,數(shù)據(jù)傾斜會發(fā)生在數(shù)據(jù)開發(fā)的各個(gè)環(huán)節(jié)中,比如:
用 Hive 算數(shù)據(jù)的時(shí)候 reduce 階段卡在 99.99%用 Spark Streaming 做實(shí)時(shí)算法時(shí)候,一直會有 executor 出現(xiàn) OOM 的錯(cuò)誤,但是其余的 executor 內(nèi)存使用率卻很低。這些問題經(jīng)常會困擾我們,辛辛苦苦等了幾個(gè)小時(shí)的數(shù)據(jù)就是跑不出來,心里多難過啊。
例子很多,這里先隨便舉兩個(gè),后文會詳細(xì)的說明。
二、關(guān)鍵字:千億級
為什么要突出這么大數(shù)據(jù)量?先說一下筆者自己最初對數(shù)據(jù)量的理解:
數(shù)據(jù)量大就了不起了?數(shù)據(jù)量少,機(jī)器也少,計(jì)算能力也是有限的,因此難度也是一樣的。憑什么數(shù)據(jù)量大就會有數(shù)據(jù)傾斜,數(shù)據(jù)量小就沒有?
這樣理解也有道理,但是比較片面,舉兩個(gè)場景來對比:
公司一:總用戶量 1000 萬,5 臺 64G 內(nèi)存的的服務(wù)器。公司二:總用戶量 10 億,1000 臺 64G 內(nèi)存的服務(wù)器。兩個(gè)公司都部署了 Hadoop 集群。假設(shè)現(xiàn)在遇到了數(shù)據(jù)傾斜,發(fā)生什么?
公司一的數(shù)據(jù)分時(shí)童鞋在做 join 的時(shí)候發(fā)生了數(shù)據(jù)傾斜,會導(dǎo)致有幾百萬用戶的相關(guān)數(shù)據(jù)集中到了一臺服務(wù)器上,幾百萬的用戶數(shù)據(jù),說大也不大,正常字段量的數(shù)據(jù)的話 64G 還是能輕松處理掉的。
公司二的數(shù)據(jù)分時(shí)童鞋在做 ?join的時(shí)候也發(fā)生了數(shù)據(jù)傾斜,可能會有 1 億的用戶相關(guān)數(shù)據(jù)集中到了一臺機(jī)器上了(相信我,這很常見),這時(shí)候一臺機(jī)器就很難搞定了,最后會很難算出結(jié)果。
0x02 數(shù)據(jù)傾斜長什么樣
工作中遇到的大部分的數(shù)據(jù)傾斜問題都解決了,而且也不想重新運(yùn)行任務(wù)來截圖,下面會分幾個(gè)場景來描述一下數(shù)據(jù)傾斜的特征,方便讀者辨別。
由于 Hadoop 和 Spark 是最常見的兩個(gè)計(jì)算平臺,下面就以這兩個(gè)平臺說明:
一、Hadoop中的數(shù)據(jù)傾斜
Hadoop 中最常用的是的是 Mapreduce 和 Hive ,雖說 Hive 最后也是用 MR 來執(zhí)行(至少目前Hive內(nèi)存計(jì)算并不普及),但是畢竟寫的內(nèi)容邏輯區(qū)別很大,一個(gè)是程序,一個(gè)是 Sql,因此這里稍作區(qū)分。
Hadoop中的數(shù)據(jù)傾斜主要表現(xiàn)在、ruduce 階段卡在 99.99%,一直 99.99% 不能結(jié)束。
這里如果詳細(xì)的看日志或者和監(jiān)控界面的話會發(fā)現(xiàn):
有一個(gè)多幾個(gè) reduce 卡住各種 container 報(bào)錯(cuò) OOM讀寫的數(shù)據(jù)量極大,至少遠(yuǎn)遠(yuǎn)超過其它正常的 reduce伴隨著數(shù)據(jù)傾斜,會出現(xiàn)任務(wù)被 kill 等各種詭異的表現(xiàn)。
經(jīng)驗(yàn):Hive 的數(shù)據(jù)傾斜,一般都發(fā)生在 Sql 中 Group 和 On 上,而且和數(shù)據(jù)邏輯綁定比較深。
二、Spark 中的數(shù)據(jù)傾斜
Spark 中的數(shù)據(jù)傾斜也很常見,這里包括Spark Streaming 和 Spark Sql,表現(xiàn)主要有下面幾種:
Executor lost,OOM,Shuffle過程出錯(cuò)Driver OOM單個(gè) executor 執(zhí)行時(shí)間特別久,整體任務(wù)卡在某個(gè)階段不能結(jié)束正常運(yùn)行的任務(wù)突然失敗補(bǔ)充一下,在 Spark streaming 程序中,數(shù)據(jù)傾斜更容易出現(xiàn),特別是在程序中包含一些類似 Sql 的 join、group 這種操作的時(shí)候。 因?yàn)?Spark Streaming 程序在運(yùn)行的時(shí)候,我們一般不會分配特別多的內(nèi)存,因此一旦在這個(gè)過程中出現(xiàn)一些數(shù)據(jù)傾斜,就十分容易造成 OOM。
0x03 數(shù)據(jù)傾斜的原理
一、數(shù)據(jù)傾斜產(chǎn)生的原因
我們以 Spark 和 Hive 的使用場景為例。他們在做數(shù)據(jù)運(yùn)算的時(shí)候會涉及到,count distinct、group by、join 等操作,這些都會觸發(fā) Shuffle 動作,一旦觸發(fā),所有相同 key 的值就會拉到一個(gè)或幾個(gè)節(jié)點(diǎn)上,就容易發(fā)生單點(diǎn)問題。
二、萬惡的 Shuffle
Shuffle 是一個(gè)能產(chǎn)生奇跡的地方,不管是在 Spark 還是 Hadoop 中,它們的作用都是至關(guān)重要的。關(guān)于 Shuffle 的原理,這里不再講述,看看 Hadoop 相關(guān)的論文或者文章理解一下就 ok。這里主要針對在 Shuffle 如何產(chǎn)生了數(shù)據(jù)傾斜。
Hadoop 和 Spark 在 Shuffle 過程中產(chǎn)生數(shù)據(jù)傾斜的原理基本類似。如下圖。
大部分?jǐn)?shù)據(jù)傾斜的原理就類似于下圖,很明了,因?yàn)閿?shù)據(jù)分布不均勻,導(dǎo)致大量的數(shù)據(jù)分配到了一個(gè)節(jié)點(diǎn)。
AIIG14wibOvyE6FhE0ia6HW79NibwAY8r90L9RyqWIS2r2fQlTDF9kUw/0?wx_fmt=png" data-copyright="0" data-ratio="1.1333333333333333" data-w="345" />
三、從數(shù)據(jù)角度來理解數(shù)據(jù)傾斜
我們舉一個(gè)例子,就說數(shù)據(jù)默認(rèn)值的設(shè)計(jì)吧,假設(shè)我們有兩張表:
user(用戶信息表):userid,register_ipip(IP表):ip,register_user_cnt這可能是兩個(gè)不同的人開發(fā)的數(shù)據(jù)表,如果我們的數(shù)據(jù)規(guī)范不太完善的話,會出現(xiàn)一種情況,user 表中的 register_ip 字段,如果獲取不到這個(gè)信息,我們默認(rèn)為 null,但是在 ip 表中,我們在統(tǒng)計(jì)這個(gè)值的時(shí)候,為了方便,我們把獲取不到 ip 的用戶,統(tǒng)一認(rèn)為他們的 ip 為 0。
兩邊其實(shí)都沒有錯(cuò)的,但是一旦我們做關(guān)聯(lián)了會出現(xiàn)什么情況,這個(gè)任務(wù)會在做關(guān)聯(lián)的階段,也就是sql的on的階段卡死。
四、從業(yè)務(wù)計(jì)角度來理解數(shù)據(jù)傾斜
數(shù)據(jù)往往和業(yè)務(wù)是強(qiáng)相關(guān)的,業(yè)務(wù)的場景直接影響到了數(shù)據(jù)的分布。
再舉一個(gè)例子,比如就說訂單場景吧,我們在某一天在北京和上海兩個(gè)城市多了強(qiáng)力的推廣,結(jié)果可能是這兩個(gè)城市的訂單量增長了10000%,其余城市的數(shù)據(jù)量不變。
然后我們要統(tǒng)計(jì)不同城市的訂單情況,這樣,一做 group 操作,可能直接就數(shù)據(jù)傾斜了。
0x04 如何解決
數(shù)據(jù)傾斜的產(chǎn)生是有一些討論的,解決它們也是有一些討論的,本章會先給出幾個(gè)解決數(shù)據(jù)傾斜的思路,然后對 Hadoop 和 Spark 分別給出一些解決數(shù)據(jù)傾斜的方案。
注意:?很多數(shù)據(jù)傾斜的問題,都可以用和平臺無關(guān)的方式解決,比如更好的數(shù)據(jù)預(yù)處理, 異常值的過濾等,因此筆者認(rèn)為,解決數(shù)據(jù)傾斜的重點(diǎn)在于對數(shù)據(jù)設(shè)計(jì)和業(yè)務(wù)的理解,這兩個(gè)搞清楚了,數(shù)據(jù)傾斜就解決了大部分了。
一、幾個(gè)思路
解決數(shù)據(jù)傾斜有這幾個(gè)思路:
業(yè)務(wù)邏輯,我們從業(yè)務(wù)邏輯的層面上來優(yōu)化數(shù)據(jù)傾斜,比如上面的例子,我們單獨(dú)對這兩個(gè)城市來做 count,最后和其它城市做整合。程序?qū)用妫热缯f在 Hive 中,經(jīng)常遇到count(distinct)
操作,這樣會導(dǎo)致最終只有一個(gè) reduce,我們可以先 group 再在外面包一層 count,就可以了。調(diào)參方面,Hadoop 和 Spark 都自帶了很多的參數(shù)和機(jī)制來調(diào)節(jié)數(shù)據(jù)傾斜,合理利用它們就能解決大部分問題。二、從業(yè)務(wù)和數(shù)據(jù)上解決數(shù)據(jù)傾斜
很多數(shù)據(jù)傾斜都是在數(shù)據(jù)的使用上造成的。我們舉幾個(gè)場景,并分別給出它們的解決方案。
數(shù)據(jù)分布不均勻:
前面提到的“從數(shù)據(jù)角度來理解數(shù)據(jù)傾斜”和“從業(yè)務(wù)計(jì)角度來理解數(shù)據(jù)傾斜”中的例子,其實(shí)都是數(shù)據(jù)分布不均勻的類型,這種情況和計(jì)算平臺無關(guān),我們能通過設(shè)計(jì)的角度嘗試解決它。
有損的方法:找到異常數(shù)據(jù),比如 ip 為 0 的數(shù)據(jù),過濾掉無損的方法:對分布不均勻的數(shù)據(jù),單獨(dú)計(jì)算先對 key 做一層 hash,先將數(shù)據(jù)打散讓它的并行度變大,再匯集數(shù)據(jù)預(yù)處理三、Hadoop平臺的優(yōu)化方法
列出來一些方法和思路,具體的參數(shù)和用法在官網(wǎng)看就行了。
map join 方式count distinct 的操作,先轉(zhuǎn)成 group,再 count萬能膏藥:hive.groupby.skewindata=trueleft semi join的使用設(shè)置 map 端輸出、中間結(jié)果壓縮。(不完全是解決數(shù)據(jù)傾斜的問題,但是減少了 IO 讀寫和網(wǎng)絡(luò)傳輸,能提高很多效率)四、Spark平臺的優(yōu)化方法
列出來一些方法和思路,具體的參數(shù)和用法在官網(wǎng)看就行了。
mapjoin 方式設(shè)置 rdd 壓縮合理設(shè)置 driver 的內(nèi)存Spark Sql 中的優(yōu)化和 Hive 類似,可以參考Hive0xFF 總結(jié)
數(shù)據(jù)傾斜的坑還是很大的,如何處理數(shù)據(jù)傾斜是一個(gè)長期的過程,希望本文的一些思路能提供幫助。
文中一些內(nèi)容沒有細(xì)講,比如 Hive Sql 的優(yōu)化,數(shù)據(jù)清洗中的各種坑,這些留待后面單獨(dú)的分享,會有很多的內(nèi)容。
另外千億級別的數(shù)據(jù)還會有更多的難點(diǎn),不僅僅是數(shù)據(jù)傾斜的問題,這一點(diǎn)在后面也會有專門的分享。
- 蜜度索驥:以跨模態(tài)檢索技術(shù)助力“企宣”向上生長
- Fortinet李宏凱:2025年在中國大陸啟動SASE PoP節(jié)點(diǎn)部署 助力企業(yè)出海
- Fortinet李宏凱:2024年Fortinet全球客戶已超80萬
- 央國企采購管理升級,合合信息旗下啟信慧眼以科技破局難點(diǎn)
- Apache Struts重大漏洞被黑客利用,遠(yuǎn)程代碼執(zhí)行風(fēng)險(xiǎn)加劇
- Crunchbase:2024年AI網(wǎng)絡(luò)安全行業(yè)風(fēng)險(xiǎn)投資超過26億美元
- 調(diào)查報(bào)告:AI與云重塑IT格局,77%的IT領(lǐng)導(dǎo)者視網(wǎng)絡(luò)安全為首要挑戰(zhàn)
- 長江存儲發(fā)布聲明:從無“借殼上市”意愿
- 泛微·數(shù)智大腦Xiaoe.AI正式發(fā)布,千人現(xiàn)場體驗(yàn)數(shù)智化運(yùn)營場景
- IDC:2024年第三季度北美IT分銷商收入增長至202億美元
- AI成為雙刃劍!凱捷調(diào)查:97%組織遭遇過GenAI漏洞攻擊
免責(zé)聲明:本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿,凡在本網(wǎng)站出現(xiàn)的信息,均僅供參考。本網(wǎng)站將盡力確保所提供信息的準(zhǔn)確性及可靠性,但不保證有關(guān)資料的準(zhǔn)確性及可靠性,讀者在使用前請進(jìn)一步核實(shí),并對任何自主決定的行為負(fù)責(zé)。本網(wǎng)站對有關(guān)資料所引致的錯(cuò)誤、不確或遺漏,概不負(fù)任何法律責(zé)任。任何單位或個(gè)人認(rèn)為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識產(chǎn)權(quán)或存在不實(shí)內(nèi)容時(shí),應(yīng)及時(shí)向本網(wǎng)站提出書面權(quán)利通知或不實(shí)情況說明,并提供身份證明、權(quán)屬證明及詳細(xì)侵權(quán)或不實(shí)情況證明。本網(wǎng)站在收到上述法律文件后,將會依法盡快聯(lián)系相關(guān)文章源頭核實(shí),溝通刪除相關(guān)內(nèi)容或斷開相關(guān)鏈接。