大數據數據傾斜

1. 大數據數倉建設性能優化方案

大數據數倉的性能優化主要圍繞以下四個方面：

在數據倉庫建設的過程中，我們不可避免的要執行數據任務，那麼這些任務如何進行配置才會是最優的？如果任務調度配置存在問題，將會導致出現瓶頸任務，或者無法及時提供業務所需的數據，這時我們就需要首先從調度則中段方面來考慮，是不是有些任務的調度時間設置不合理？或者是不是有的任務的優先順序設置不合理？

對於數倉的建模而言，其實可以分為3NF建模和維度建模，推薦使用維度建模方式，可以按照星型模型或者雪花模型架構的方式去建模。3NF建模方式或者實體建模方式的應用性會差一點，在很多時候其性能也會差一點，但3NF會避免數據的冗餘，其擴展性會好一些。而維度建模會有一定的數據冗餘，並且冗餘程度會很高，但是對於上層使用者而言，其易用性要好很多，並且其查詢的性能也會好很多，雖然犧牲了一定的可擴展性，但是仍然在可接受的范圍之內。之所以在大數據的框架下推薦使用維度建模，是因為建模產生的數據冗餘對於大數據離線數倉來說，存儲的成本並不高，因為其都屬於SATA盤的存儲，這樣的存儲成本是很低的。
總之，在大數據框架下推薦大家使用維度建模，使用星型模型或者雪花模型建模的方式，這樣無論對於後續的運維還是後續的數據使用而言，都是比較便利的，並且性能會好一些。星型模型其實就是中間一個事實表，周邊圍繞著一堆維度表，其結構會簡單一些，使用比較方便，性能也比較好；對於雪花模型而言，維度表可能還會繼續關聯其他的維度表，這種方式就是雪花模型，它會略微比星型模型復雜一些。其實星型模型也可以理解為較為簡單的雪花模型。這里推薦大家使用星型模型，當然如果業務非常復雜，必須要使用雪花型也可以使用。這是因為星型模型雖然有數據冗餘，但是其結構比較簡單，容易理解，而且使用起來只需要A傳給B就可以了，不需要再關聯一個C。
除了上述兩個較大的關鍵點之外，還有一些需要注意的小點，比如中間表的使用。我們一般將數倉分為三層，第一層做緩沖，第二層做整合，第三層做應用。但是並不是嚴格的只能分為三層，中間可能會有一些中間表，用於存儲中間計算的結果，如果能夠利用好中間表則會增強數倉的易用性和整體的性能。中間表的使用主要在數倉的第二層裡面，因為需要整合數據，但整合後的數據仍是明細數據，對於這些表而言，數據量往往會比較大，而且會有見多的下游任務依賴這個表，因此可以做一些輕度的匯總，也就是做一些公共的匯總的中間表，這樣應用層可以節省很多的計算量和成本。此外，雖然建議使用中間表，但也要注意中間表的數量，因為中間表數量過多，就會有太多的依賴層級。
在某些業務場景下，我們還需要對寬表進行拆表，拆表的情況一般發生在該表的欄位較多，而其中幾個欄位的產出時間較晚，導致整個表的交付時間也會延遲，在這種情況下我們可以將這幾個欄位單獨拆出來處理，這樣就不會因為幾個欄位影響其餘業務的使用。
與拆表相對的情況是合表，隨著業務的增多，可能會有多個表中存放類似的數據指標，此時，我們可以將多個表整合到一個表中，減少數據任務的冗餘。

表分區的功能一定要合理利用，這對於性能會產生很大的影響，一級分區一般都是按照天劃分的，建議大家一天一個增量或者一天一個全量來做。二級分區的選擇反而會多一些，首先大家要烤爐是否建立二級分區，其次大家再選擇二級分區的建立方式。培數二級分區比較適合於在where語句中經常使用到的欄位，而且這個欄位應該是可枚舉的，比如部門名稱這樣的。這里還有一個前提，就是如果這個欄位的值的分布是非常不均勻的，那麼就不太建議做二級分區。

離線數倉的計算任務基本都是通過SQL實現，這里也只講在SQL部分如何進行優化。我們平時在進行數據處理，數據清洗，數據轉換，數據加工的過程中都會使用到SQL。對於大數據體系下孫譽的SQL的優化而言，主要集中在兩個大的方面進行：減少數據輸入和避免數據傾斜。減少數據輸入是最核心的一點，如果數據輸入量太大，就會佔用很多的計算資源。而數據傾斜是在離線數倉中經常會遇到的，數據傾斜分為幾種，需要針對性的進行優化。

對有分區的表，合理使用分區可以過濾數據，避免全表掃描，有效的降低計算的數據輸入。

SQL支持只讀取一次源數據，然後將其寫入到多個目標表，這樣就保證了只做一次查詢。語法如下

當我們在使用join，Rece或者UDF時，先對數據進行過濾也能有效的提高任務的效率

當發生數據再Map階段傾斜的情況，第一種處理方式反饋至業務層面，看能否通過業務層面的修改讓kv值均衡分布，如果業務層面無法處理，那麼可以調整Map的個數，也就是加大Map的計算節點，默認情況是每256M的數據為一個計算節點，我們可以將其調小，也就是加大Map處理的節點的個數，使得數據分割的更加均勻一些。

Join階段的傾斜也是比較常見的，其解決方案需要分鍾如下幾種情況處理：

Rece傾斜可能的情況有以下幾種：

總結一下，性能調優歸根結底還是資源不夠了或者資源使用的不合理，或者是因為任務分配的不好，使得某些資源分配和利用不合理。

2. 2021年大數據工程師面試內容包括哪些

【導語】近年來，大數據發展如火如荼，很多人都選擇學習大數據專業或者轉行大數據，大數據里又包含很多就業崗位，所以在進行崗位選擇的時候，還是需要大家合理選擇，為了幫助大家更好的進入大數據行業執業，下面就把2021年大數據工程師面試內容給大家進行一下具體介紹。

1、自我介紹

一般上來就是自我介紹，談下工作經歷和項目經驗，面試官會根據你的項目經驗對你進行技術面試。在自我介紹時，一定要抓住核心說，不要太啰嗦，盡量放大自己的價值，讓面試官感受到你對工作的熱情，以及以後對公司貢獻的能力。

2、數倉開發知識技能

(1)java是必問的，不過問的不深，把Javase部分吃透，足以應付Java部分的面試。

(2)Hadoop生態，Yarn、Zookeeper、HDFS這些底層原理要懂，面試經常被問。

(3)Maprece的shuffle過程這個也是面試被常問的。

(4)Hbase和HIve，搞大數據這些不懂真的說不過去。

(5)Mysql、Oracle和Postgres資料庫操作要回，Sql要會寫。

(6)linux操作系統，這個簡單得命令必須要懂，會寫shell腳本更好了。

(7)Kettle或Sqoop這種數據處理工具至少要會一個。8，數據倉庫建模、數據模型的問題。

3、技術方面知識技能

(1)SparkSql和SparkStreaming，底層原理、內核、提交任務的過程等等，盡量深入內幕，這個經常會跟MapRece作比較的。當然也要了解Storm和Flink，Flink這個建議要學會，以後用處會越來越廣。

(2)Redis、Kafka、ElasticSearch這些都得懂原理，深入了解，會使用，會操作，會調優。

(3)impala和kylin這些盡量也要了解會用

(4)Python這個要是有能力，有精力，建議也要往深處學習，我目前正在自學中。

(5)集群的問題，包括一些簡單的運維知識。

(6)大數據數據傾斜的問題，包括Spark JVM內存調優問題等等。

關於2021年大數據工程師面試內容，就給大家介紹到這里了，希望對大家能有所幫助，當然進入大數據行業，還需要大家在平時不斷進行技能提升，這樣才能更好的擁有一席之地。

3. 常見大數據公司面試問題有哪些

1、您對“大數據”一詞有什麼了解?

答： 大數據是與復雜和大型數據集相關的術語。關系資料庫無法處理大數據，這就是為什麼使用特殊的工具和方法對大量數據執行操作的原因。大數據使公司能夠更好地了解其業務，並幫助他們從定期收集的非結構化和原始數據中獲取有意義的信息。大數據還使公司能夠根據數據做出更好的業務決策。

2、告訴我們大數據和Hadoop之間的關系。

答： 大數據和Hadoop幾乎是同義詞。隨著大數據的興起，專門用於大數據操作的Hadoop框架也開始流行。專業人士可以使用該框架來分析大數據並幫助企業做出決策。

注意： 在大數據采訪中通常會問這個問題。 可以進一步去回答這個問題，並試圖解釋的Hadoop的主要組成部分。

3、大數據分析如何有助於增加業務收入?

答：大數據分析對於企業來說已經變得非常重要。它可以幫助企業與眾不同，並增加收入。通過預測分析，大數據分析為企業提供了定製的建議。此外，大數據分析使企業能夠根據客戶的需求和偏好推出新產品。這些因素使企業獲得更多收入，因此公司正在使用大數據分析。通過實施大數據分析，公司的收入可能會大幅增長5-20%。一些使用大數據分析來增加收入的受歡迎的公司是-沃爾瑪，LinkedIn，Facebook，Twitter，美國銀行等。

4. 「每日一道大數據面試題系列」spark如何調優

如果面試時被問到spark任務如何調優，我們該如何回答呢？

下面我們從四大方面回答這個問題，保證吊打面試官。

一、spark性能調優

1、分配更多的資源

比如增加執行器個數（num_executor）、增加執行器個數（executor_cores）、增加執行器內存（executor_memory）

2、調節並行度

spark.default.parallelism

3、重構RDD架構以及RDD持久化

盡量去復用RDD，差不多的RDD可以抽取成一個共同的RDD，公共RDD一定要實現持久化

4、廣播變數

SparkContext.broadcast方法創建一個對象，通過value方法訪問

5、使用kryo序列化

SparkConf中設置屬性：spark.serializer: org.apache.spark.serializer.kryoSerializer

6、使用fastutil優化數據格式（代替java中的Array、List、Set、Map）

7、調節數據本地化等待時長

調節參數: spark.locality.wait

二、JVM調優

降低cache操作的內存佔比 1.6版本之前使用的是靜態內存管理

spark中堆內存被劃分為兩塊：

一塊是專門來給RDD作cachepersist持久化的 StorageMemory，另一塊是給spark運算元函數運行使用的，存放函數中自己創建的對象。

1.6版本之後採用統一內存管理機制

storage和execution各佔50%，若己方不足對方空餘可佔用對方空間

可嘗試調節executor堆外內存

spark.yarn.executor.memoryOverhead = 2048m

調節連接等待時長

spark.core.connection.ack.wait.timeout = 300

三、shuffle數據傾斜調優

1、預聚合源數據，對hive源表提前進行聚合操作，在hive聚合之後，spark任務再去讀取

2、檢查傾斜的key是否是臟數據，可以提前過濾

3、提高shuffle操作rece的並行度

4、使用隨機key實現雙重聚合

5、將rece端 join轉換成map端 join

6、sample采樣傾斜key，單獨進行join後在union

7、使用隨機數以及擴容表進行join

四、運算元調優

1、使用mapPartition提升map類操作的性能

2、filter過後使用coalesce減少分區數量

3、使用foreachPartition優化寫數據性能

4、使用repartition解決sparkSql低並行度的性能問題

5、receByKey替換groupByKey實現map讀預聚合

5. 數據傾斜時 hadoop和spark哪個性能更好

觸發shuffle的常見運算元：distinct、groupByKey、receByKey、aggregateByKey、join、cogroup、repartition等。
要解決數據傾斜的問題，首先要定位數據傾斜發生在什麼地方，首先是哪個stage，直接在Web UI上看就可以，然後查看運行耗時的task，查看數據是否傾斜了！
根據這個task，根據stage劃分原理，推算出數據傾斜發生在哪個shuffle類運算元上。
查看導致數據傾斜的key的數據分布情況
根據執行操作的不同，可以有很多種查看key分布的方式：
1，如果是Spark SQL中的group by、join語句導致的數據傾斜，那麼就查詢一下SQL中使用的表的key分布情況。
2，如果是Spark RDD執行shuffle運算元導致的數據傾斜，那麼可以在Spark作業中加入查看key分布的代碼，比如RDD.countByKey()。然後對統計出來各個key出現的次數，collect、take到客戶端列印一下，就可以看到key的分布情況。
比如針對wordCount案例，最後的receByKey運算元導致了數據傾斜：
val sampledPairs = pairs.sample(false,0.1) //對pairs采樣10%
val sampledWordCounts = sampledPairs.countByKey()
sampledWordCounts.foreach(println(_))
數據傾斜的解決辦法
方案一：使用Hive ETL預處理數據
適用場景：導致數據傾斜的是Hive表，Hive表中的數據本身很不均勻，業務場景需要頻繁使用Spark對Hive表執行某個分析操作。
實現思路：提前將join等操作執行，進行Hive階段的ETL。將導致數據傾斜的shuffle前置。
優缺點：實現簡單，Spark作業性能提升，但是Hive ETL還是會發生數據傾斜，導致Hive ETL的速度很慢。
實踐經驗：將數據傾斜提前到上游的Hive ETL，每天就執行一次，慢就慢點吧。

方案二：過濾少數導致傾斜的key
適用場景：少數幾個key導致數據傾斜，而且對計算本身影響並不大的話。
實現思路：比如Spark SQL中直接用where條件過濾掉這些key，如果是RDD的話，用filter運算元過濾掉這些key。如果是動態判斷哪些key的數據量最多然後再進行過濾，那麼可以使用sample運算元對RDD進行采樣，然後計算出每個key的數量，取數據量最多的key過濾掉即可。
優缺點：實現簡單，效果也好。缺點是一般情況下導致傾斜的key還是很多的，不會是少數。

解決方案三：提高shuffle操作的並行度
適用場景：直接面對數據傾斜的簡單解決方案。
實現思路：對RDD執行shuffle運算元時，給shuffle運算元傳入一個參數，比如receByKey(1000)，該參數就設置了這個shuffle運算元執行的shuffle read task的數量。對於Spark SQL中的shuffle類語句，比如group by，join等，需要設置一個參數，即spark.sql.shuffle.partitions，該參數默認值是200，對於很多場景來說有點過小。
優缺點：簡單能緩解，缺點是沒有根除問題，效果有限。

解決方案四：兩階段聚合（局部聚合+全局聚合）
適用場景：對RDD執行receByKey等聚合類shuffle運算元或者在Spark SQL中使用group by語句進行分組聚合時，比較適合這種方案。
實現思路：先局部聚合，給每個key打一個小范圍的隨機數，比如10以內的隨機數，相當於分成10份，一個task分成10個task。聚合聚合後，去掉key上的隨機數前綴，再次進行全局聚合操作。

優缺點：大幅度緩解數據傾斜，缺點是僅適用於聚合類的shuffle操作。

解決方案五：將rece join轉為map join

6. 大數據技術常用的數據處理方式有哪些

大數據技術常用的數據處理方式，有傳統的ETL工具利用多線程處理文件的方式；有寫MapRece，有利用Hive結合其自定義函數，也可以利用Spark進行數據清洗等，每種方式都有各自的使用場景。

在實際的工作中，需要根據不同的特定場景來選擇數據處理方式。

1、傳統的ETL方式

傳統的ETL工具比如Kettle、Talend、Informatica等，可視化操作，上手比較快，但是隨著數據量上升容易導致性能出問題，可優化的空間不大。

2、Maprece

寫Maprece進行數據處理，需要利用java、python等語言進行開發調試，沒有可視化操作界面那麼方便，在性能優化方面，常見的有在做小表跟大表關聯的時候，可以先把小表放到緩存中(通過調用Maprece的api)，另外可以通過重寫Combine跟Partition的介面實現，壓縮從Map到rece中間數據處理量達到提高數據處理性能。

3、Hive

在沒有出現Spark之前，Hive可謂獨占鰲頭，涉及離線數據的處理基本都是基於Hive來做的，Hive採用sql的方式底層基於Hadoop的Maprece計算框架進行數據處理，在性能優化上也不錯。

4、Spark

Spark基於內存計算的准Maprece，在離線數據處理中，一般使用Spark sql進行數據清洗，目標文件一般是放在hdf或者nfs上，在書寫sql的時候，盡量少用distinct，group by recebykey 等之類的運算元，要防止數據傾斜。