1)Hive資料傾斜問題：

傾斜原因： map輸出資料按Key Hash分配到reduce中,由於key分佈不均勻、或者業務資料本身的特點。等原因造成的reduce上的資料量差異過大。

1.1)key分佈不均勻

1.2)業務資料本身的特性

1.3)SQL語句造成資料傾斜

解決方案：

1>引數調節：

    hive.map.aggr=true

    hive.groupby.skewindata=true

有資料傾斜的時候進行負載均衡，當選項設定為true,生成的查詢計劃會有兩個MR Job。第一個MR Job中，Map的輸出結果集合會隨機分佈到Reduce中，每個Reduce做部分聚合操作，並輸出結果，這樣處理的結果是相同Group By Key有可能被分發到不同的Reduce中，從而達到負載均衡的目的；第二個MR Job在根據預處理的資料結果按照 Group By Key 分佈到Reduce中(這個過程可以保證相同的 Group By Key 被分佈到同一個Reduce中)，最後完成最終的聚合操作。

2>SQL語句調節：

   1)選用join key 分佈最均勻的表作為驅動表。做好列裁剪和filter操作，以達到兩表join的時候，資料量相對變小的效果。

   2)大小表Join： 使用map join讓小的維度表（1000條以下的記錄條數）先進記憶體。在Map端完成Reduce。

   3)大表Join大表：把空值的Key變成一個字串加上一個隨機數，把傾斜的資料分到不同的reduce上，由於null值關聯不上，處理後並不影響最終的結果。

   4)count distinct大量相同特殊值：count distinct時，將值為空的情況單獨處理，如果是計算count distinct，可以不用處理，直接過濾，在做後結果中加1。如果還有其他計算，需要進行group by，可以先將值為空的記錄單獨處理，再和其他計算結果進行union.

2)請說明hive中 sort by ，order by ，cluster by ，distribute by各代表什麼意思。

order by ：會對輸入做全域性排序，因此只有一個reducer(多個reducer無法保證全域性有序).只有一個reducer,會導致當輸入規模較大時，需要較長的計算時間。

sort by ：不是全域性排序，其在資料進入reducer前完成排序

distribute by ：按照指定的欄位對資料進行劃分輸出到不同的reduce中

cluster by ：除了具有distribute by 的功能外還兼具sort by 的功能

3)描述資料中的null,在hive底層如何儲存

null在hive底層預設是用"\N"來儲存的，所以在sqoop到mysql之前需要將為null的資料加工成其他字元，否則sqoop提示錯誤

4)Hive中 split、coalesce以及collect_list函式的用法

   split將字串轉化為陣列

    coalesce(T v1,T v2,...) 返回引數中的第一個非空值；如果所有值都為null,那麼返回null

    collect_list列出該欄位所有的值,不去重 select collect_list(id) from table;

5)將檔案匯入到hive表中

   load data local inpath '/a.txt' overwrite into table test partition(xx='xx')

6)Hive檔案壓縮格式有哪些，壓縮效率如何

開啟壓縮

set hive.exec.compress.output=true;

set mapred.output.compress=true;

set mapred.output.compression.codec=org.apache.hadoop.io.compress.GzipCodec;

set io.compression.codec=org.apache.hadoop.io.compress.GzipCodec;

set mapred.output.compression.type=BLOCK;

TextFile (壓縮方式Gzip,Bzip2壓縮後不支援split)

SequenceFile

RCFile(儲存方式：資料按行分塊，每塊按列儲存。結合了行儲存和列儲存的優點)

ORCFile

7)Hive的分組方式

row_number() 是沒有重複值的排序(即使兩天記錄相等也是不重複的),可以利用它來實現分頁
dense_rank() 是連續排序,兩個第二名仍然跟著第三名
rank()       是跳躍排序的,兩個第二名下來就是第四名