漫談千億級數據優化實踐：數據傾斜（純乾貨）

時間 2019-11-07

標籤漫談千億數據優化實踐傾斜乾貨简体版

原文原文鏈接

0x00 前言

數據傾斜是大數據領域繞不開的攔路虎，當你所需處理的數據量到達了上億甚至是千億條的時候，數據傾斜將是橫在你面前一道巨大的坎。git

邁的過去，將會海闊天空！邁不過去，就要作好準備：極可能有幾周甚至幾月都要頭疼於數據傾斜致使的各種詭異的問題。github

鄭重聲明：算法

話題比較大，技術要求也比較高，筆者盡最大的能力來寫出本身的理解，寫的不對和很差的地方你們一塊兒交流。sql
有些例子不是特別嚴謹，一些小細節對文章理解沒有影響，不要太在乎。（好比我在算機器內存的時候，就不把Hadoop自身的進程算到使用內存中）apache
總的來說我的感受寫的仍是比較乾貨的。服務器

文章結構

先大體解釋一下什麼是數據傾斜網絡
再根據幾個場景來描述一下數據傾斜產生的狀況oop
詳細分析一下在Hadoop和Spark中產生數據傾斜的緣由大數據
如何解決（優化）數據傾斜問題？優化

0x01 什麼是數據傾斜

簡單的講，數據傾斜就是咱們在計算數據的時候，數據的分散度不夠，致使大量的數據集中到了一臺或者幾臺機器上計算，這些數據的計算速度遠遠低於平均計算速度，致使整個計算過程過慢。

1、關鍵字：數據傾斜

相信大部分作數據的童鞋們都會遇到數據傾斜，數據傾斜會發生在數據開發的各個環節中，好比：

用Hive算數據的時候reduce階段卡在99.99%
用SparkStreaming作實時算法時候，一直會有executor出現OOM的錯誤，可是其他的executor內存使用率卻很低。

這些問題常常會困擾咱們，辛辛苦苦等了幾個小時的數據就是跑不出來，內心多難過啊。

例子不少，這裏先隨便舉兩個，後文會詳細的說明。

2、關鍵字：千億級

爲何要突出這麼大數據量？先說一下筆者本身最初對數據量的理解：

數據量大就了不得了？數據量少，機器也少，計算能力也是有限的，所以難度也是同樣的。憑什麼數據量大就會有數據傾斜，數據量小就沒有？

這樣理解也有道理，可是比較片面，舉兩個場景來對比：

公司一：總用戶量1000萬，5臺64G內存的的服務器。
公司二：總用戶量10億，1000臺64G內存的服務器。

兩個公司都部署了Hadoop集羣。假設如今遇到了數據傾斜，發生什麼？

公司一的數據分時童鞋在作join的時候發生了數據傾斜，會致使有幾百萬用戶的相關數據集中到了一臺服務器上，幾百萬的用戶數據，說大也不大，正常字段量的數據的話64G仍是能輕鬆處理掉的。

公司二的數據分時童鞋在作join的時候也發生了數據傾斜，可能會有1個億的用戶相關數據集中到了一臺機器上了（相信我，這很常見），這時候一臺機器就很難搞定了，最後會很難算出結果。

0x02 數據傾斜長什麼樣

筆者大部分的數據傾斜問題都解決了，並且也不想從新運行任務來截圖，下面會分幾個場景來描述一下數據傾斜的特徵，方便讀者辨別。

因爲Hadoop和Spark是最多見的兩個計算平臺，下面就以這兩個平臺說明：

1、Hadoop中的數據傾斜

Hadoop中直接貼近用戶使用使用的時Mapreduce程序和Hive程序，雖然說Hive最後也是用MR來執行（至少目前Hive內存計算並不普及），可是畢竟寫的內容邏輯區別很大，一個是程序，一個是Sql，所以這裏稍做區分。

Hadoop中的數據傾斜主要表如今、ruduce階段卡在99.99%，一直99.99%不能結束。

這裏若是詳細的看日誌或者和監控界面的話會發現：

有一個多幾個reduce卡住
各類container報錯OOM
讀寫的數據量極大，至少遠遠超過其它正常的reduce

伴隨着數據傾斜，會出現任務被kill等各類詭異的表現。

經驗：Hive的數據傾斜，通常都發生在Sql中Group和On上，並且和數據邏輯綁定比較深。

2、Spark中的數據傾斜

Spark中的數據傾斜也很常見，這裏包括Spark Streaming和Spark Sql，表現主要有下面幾種：

Executor lost，OOM，Shuffle過程出錯
Driver OOM
單個Executor執行時間特別久，總體任務卡在某個階段不能結束
正常運行的任務忽然失敗

補充一下，在Spark streaming程序中，數據傾斜更容易出現，特別是在程序中包含一些相似sql的join、group這種操做的時候。由於Spark Streaming程序在運行的時候，咱們通常不會分配特別多的內存，所以一旦在這個過程當中出現一些數據傾斜，就十分容易形成OOM。

0x03 數據傾斜的原理

1、數據傾斜產生的緣由

咱們以Spark和Hive的使用場景爲例。他們在作數據運算的時候會設計到，countdistinct、group by、join等操做，這些都會觸發Shuffle動做，一旦觸發，全部相同key的值就會拉到一個或幾個節點上，就容易發生單點問題。

2、萬惡的shuffle

Shuffle是一個能產生奇蹟的地方，不論是在Spark仍是Hadoop中，它們的做用都是相當重要的。關於Shuffle的原理，這裏再也不講述，看看Hadoop相關的論文或者文章理解一下就ok。這裏主要針對，在Shuffle如何產生了數據傾斜。

Hadoop和Spark在Shuffle過程當中產生數據傾斜的原理基本相似。以下圖。

大部分數據傾斜的原理就相似於下圖，很明瞭，由於數據分佈不均勻，致使大量的數據分配到了一個節點。

3、從數據角度來理解數據傾斜

咱們舉一個例子，就說數據默認值的設計吧，假設咱們有兩張表：

user（用戶信息表）：userid，register_ip
ip（IP表）：ip，register_user_cnt

這多是兩個不一樣的人開發的數據表，若是咱們的數據規範不太完善的話，會出現一種狀況，user表中的register_ip字段，若是獲取不到這個信息，咱們默認爲null，可是在ip表中，咱們在統計這個值的時候，爲了方便，咱們把獲取不到ip的用戶，統一認爲他們的ip爲0。

兩邊其實都沒有錯的，可是一旦咱們作關聯了會出現什麼狀況，這個任務會在作關聯的階段，也就是sql的on的階段卡死。

4、從業務計角度來理解數據傾斜

數據每每和業務是強相關的，業務的場景直接影響到了數據的分佈。

再舉一個例子，好比就說訂單場景吧，咱們在某一天在北京和上海兩個城市多了強力的推廣，結果多是這兩個城市的訂單量增加了10000%，其他城市的數據量不變。

而後咱們要統計不一樣城市的訂單狀況，這樣，一作group操做，可能直接就數據傾斜了。

0x04 如何解決

數據傾斜的產生是有一些討論的，解決它們也是有一些討論的，本章會先給出幾個解決數據傾斜的思路，而後對Hadoop和Spark分別給出一些解決數據傾斜的方案。

注意： 不少數據傾斜的問題，均可以用和平臺無關的方式解決，好比更好的數據預處理，異常值的過濾等，所以筆者認爲，解決數據傾斜的重點在於對數據設計和業務的理解，這兩個搞清楚了，數據傾斜就解決了大部分了。

1、幾個思路

解決數據傾斜有這幾個思路：

業務邏輯，咱們從業務邏輯的層面上來優化數據傾斜，好比上面的例子，咱們單獨對這兩個城市來作count，最後和其它城市作整合。
程序層面，好比說在Hive中，常常遇到count（distinct）操做，這樣會致使最終只有一個reduce，咱們能夠先group 再在外面包一層count，就能夠了。
調參方面，Hadoop和Spark都自帶了不少的參數和機制來調節數據傾斜，合理利用它們就能解決大部分問題。