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