踩過資料倉儲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=
5and hit_date=
20200606
;

2）帶有orderby的查詢對於使用了orderby的查詢，要求必須有limit語句。因為orderby為了執行排序過程會講所有的結果分發到同乙個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 byis 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 isnot 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.設定為非嚴格模式的情況慎重使用，甚至不建議使用。

踩過資料倉儲hive的坑 hive設定嚴格模式

Hive 資料倉儲

資料倉儲Hive

資料倉儲Hive

踩過資料倉儲hive的坑 hive設定嚴格模式

Hive 資料倉儲

資料倉儲Hive

資料倉儲Hive

相關推薦