info基本資訊表
user_id
name
agegender
1henry16男
2jack17男
3anny18女
4candy19女
5kate20女
burke
21frank
22ellen
23ken
24mili
25...
......
...score成績表
user_id
subject_id
score11
891290
13914
29243
936194
73958
19682
978398
......
...是因為資料分布的不均勻，導致一大部分資料集中到某乙個節點上，其他資料少的節點早早的就完成了計算任務，資料量大的節點還在計算中，使得整個job進度長時間停留在map100%,reduce99%，這就是因為資料發生了傾斜導致的結果。
導致資料傾斜有以下原因：
1.資料本身某個key值較多，導致分布不均，比如說上述info表中性別一列只有兩個男生，兩個女生，其餘為空值。這樣大量的空值欄位會導致資料傾斜。
2.針對某個業務，導致某個key值較多，分布不均勻，比如說group by時某個字段值較多。比如說上述info表中男生數量只有幾個，其餘皆為女生。如果要按照性別分組，這樣極易導致傾斜。
3.建表時考慮不周全
4.某些hql語句本身就有資料傾斜。
1.若資料中某個欄位有大量空值，存在資訊缺失的情況。導致在表之間進行關聯時，發生資料傾斜。
比如，將info表和score表關聯，那麼info表中的user_id欄位存在大量空值，會導致資料傾斜。
解決辦法：要麼先將空值過濾掉，最後再將空值union all進去。
select *
from info a
join score b
on a.user_id is not null and a.user_id=b.user_id
union all
select * from info c where c.user_id is null;
select *
from info a
left join score b
oncase when a.user_id is null then concat(hive,rand()) else a.user_id end =b.user_id;
2.若兩張表中在做join時，相關聯的字段的資料型別不一致時會導致資料傾斜。
如果info表中user_id的屬性是int,score表中user_id的屬性是string，在做兩表關聯時，容易發生資料傾斜。
解決辦法：將資料型別轉成一致的型別，使用cast函式。
select *
from info a
left outer join score b
on b.user_id = cast(a.user_id as int)
解決辦法：在map端完成join。這裡是inner join。將小表載入到記憶體中，使得每個map task上都有此小表，小表分別和各個資料塊做join。在hive的0.11版本後，會自動開啟map join優化，具體引數設定如下：
set hive.auto.convert.join=true;(預設開啟)
set hive.mapjoin.smalltable.filesize=25000000;//設定小表的大小，不超過則開啟mapjoin
解決辦法：將大表1中關聯列去重後單獨抽出，形成一張小表。將此小表和大表2先關聯，關聯好後再和大表1進行關聯。
5.當對表中資料做一些型別統計的時候遇到過某種型別的資料量特別多，而其他型別資料的資料量特別少。當按照型別進行 group by 的時候，會將相同的 group by 欄位的 reduce 任務需要的資料拉取到同乙個節點進行聚合。比如說計算info表中男女生數量。（比如男生很少，女生很多）
解決辦法：開啟 map 端聚合引數設定
//是否在 map 端進行聚合，預設為 true
set hive.map.aggr = true;
//在 map 端進行聚合操作的條目數目
set hive.groupby.mapaggr.checkinterval = 100000;
//有資料傾斜的時候進行負載均衡（預設是 false）
set hive.groupby.skewindata = true;
6.當hql語句中包含 count（distinct）時，如果資料量非常大，查詢各個學生考了幾門課程的考試。執行如 select user_id,count(distinct subject_id) from score group by score;型別的 sql 時，會出現資料傾斜的問題。
解決辦法：使用sum...group by 代替
select
user_id,sum(1)
from
( select user_id,subject_id from score group by user_id,subject_id
)group by user_id;
聊一聊元資料
這個話題來自我的msn space。這是原文 元資料 metadata 這個詞現在到處氾濫。其實我對元資料充其量只能說有自己的理解而已，並不能確信這個理解是正確的。我認為，資料結構分為三個層次 uml可是四層哦 例項層 直接描述特異化的資料場景 元資料層 描述例項的結構的一組資料 元資料的元資料層 ...
聊一聊資料結構
資料結構 2.棧和佇列 二 樹三 圖 線性結構是一種基本的資料結構，主要用於對客觀世界中具有單一前驅和後繼的資料關係進行描述。線性結構的特點是資料元素之間呈現一種線性關係，即元素 乙個接乙個排列 線性表常採用順序儲存和鏈式儲存，主要的操作是 插入 刪除 查詢 線性表的順序儲存是指用一組位址連續的儲存...
聊一聊Flink 寫 Hive 的小檔案問題
flink 1.11 引入了寫hive的功能後，已經在上線了一段時間。下面就聊聊我自己對flink 寫hive 小檔案的一些問題和看法。1.flink 寫 hive 可能會產生小檔案嗎？簡單的說，答案是會。簡單總結下flink 讀kafka寫hive的流程 1.flink 將kafka資料根據設定的...