踩過數據倉庫hive的坑：hive設置嚴格模式
一個報錯引發的雷！！！
hive提供了一個嚴格模式，可以防止用戶執行那些可能產生意想不到的不好的效果的查詢，也可以很好的防止數據傾斜。即某些查詢在嚴格模式下無法執行。通過設置hive.mapred.mode的值爲strict，可禁止以下3種類型的查詢。
1）帶有分區的表的查詢
如果在一個分區表執行hive，除非where語句中包含分區字段過濾條件來顯示數據範圍，否則不允許執行。換句話說，
就是用戶不允許掃描所有的分區。進行這個限制的原因是，通常分區表都擁有非常大的數據集，而且數據增加迅速。
如果沒有進行分區限制的查詢可能會消耗令人不可接受的巨大資源來處理這個表：
hive> SELECT DISTINCT(planner_id) FROM fans WHERE planner_id=10;
FAILED: Error in semantic analysis: No Partition Predicate Found for Alias "fans" Table "fracture_ins
如下這個語句在where語句中增加了一個分區過濾條件（也就是限制了表分區）：
hive> SELECT DISTINCT(planner_id) FROM fans WHERE planner_id=5 AND hit_date=20200606;
2）帶有orderby的查詢
對於使用了orderby的查詢，要求必須有limit語句。因爲orderby爲了執行排序過程會講所有的結果分發到同一個reducer中
進行處理，強烈要求用戶增加這個limit語句可以防止reducer額外執行很長一段時間：
hive> SELECT * FROM fans WHERE hit_date>2020 ORDER BY planner_id;
FAILED: Error in semantic analysis: line 1:56 In strict mode,
limit must be specified if ORDER BY is present planner_id
只需要增加limit語句就可以解決這個問題：
hive> SELECT * FROM fans WHERE hit_date>2020 ORDER BY planner_id LIMIT 100000;
3）限制笛卡爾積的查詢
對關係型數據庫非常瞭解的用戶可能期望在執行join查詢的時候不使用on語句而是使用where語句，這樣關係數據庫的執行
優化器就可以高效的將where語句轉換成那個on語句。不幸的是，hive不會執行這種優化，因此，如果表足夠大，那麼這個查詢就會出現不可控的情況：
hive> SELECT * FROM fans_act JOIN fans_ads WHERE fans_act.planner_id = fans_ads.planner_id;
FAILED: Error in semantic analysis: In strict mode, cartesian product
is not allowed. If you really want to perform the operation,
+set hive.mapred.mode=nonstrict+
下面這個纔是正確的使用join和on語句的查詢：
hive> SELECT * FROM fans_act JOIN fans_ads ON (fans_act.planner_id = fans_ads.planner_id);
開啓後影響總結：
1、對分區表查詢必須帶分區條件，否則會查詢失敗
2、帶orderby的查詢，必須使用limit限制查詢數據條數，否則會查詢失敗，因爲執行order by的時候，已經將所有的數據放到了一個reduce中了。
3、不能進行笛卡爾積的查詢，在關係型數據庫中，可以使用where充當on，但是在hive數據倉庫中，必須使用on。
4、查詢條件裏面字段類型賦值時必須一致，比如日期分區dt字段類型爲字符串，那麼分區條件必須指定爲dt=‘20200606’，而不能用dt=20200606。
5、在生成動態分區時，會失敗，需要單獨設置爲非嚴格模式，hive.mapred.mode=nostrict;
6.設置爲非嚴格模式的情況慎重使用，甚至不建議使用。