hive中严格模式和非严格模式的区别

hive中严格模式和非严格模式的区别

 hive严格模式

hive提供了一个严格模式,可以防止用户执行那些可能产生意想不到的不好的效果的查询。即某些查询在严格
模式下无法执行。通过设置hive.mapred.mode的值为strict,可以禁止3中类型的查询。


1)带有分区的表的查询
如果在一个分区表执行hive,除非where语句中包含分区字段过滤条件来显示数据范围,否则不允许执行。换句话说,
就是用户不允许扫描所有的分区。进行这个限制的原因是,通常分区表都拥有非常大的数据集,而且数据增加迅速。
如果没有进行分区限制的查询可能会消耗令人不可接受的巨大资源来处理这个表:
hive> SELECT DISTINCT(planner_id) FROM fracture_ins WHERE planner_id=5;
FAILED: Error in semantic analysis: No Partition Predicate Found for Alias "fracture_ins" Table "fracture_ins


如下这个语句在where语句中增加了一个分区过滤条件(也就是限制了表分区):
hive> SELECT DISTINCT(planner_id) FROM fracture_ins
> WHERE planner_id=5 AND hit_date=20120101;
... normal results ...


2)带有orderby的查询
对于使用了orderby的查询,要求必须有limit语句。因为orderby为了执行排序过程会讲所有的结果分发到同一个reducer中
进行处理,强烈要求用户增加这个limit语句可以防止reducer额外执行很长一段时间:
hive> SELECT * FROM fracture_ins WHERE hit_date>2012 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 fracture_ins WHERE hit_date>2012 ORDER BY planner_id
> LIMIT 100000;
... normal results ...


3)限制笛卡尔积的查询
对关系型数据库非常了解的用户可能期望在执行join查询的时候不使用on语句而是使用where语句,这样关系数据库的执行
优化器就可以高效的将where语句转换成那个on语句。不幸的是,hive不会执行这种优化,因此,如果表足够大,那么这个查询就会
出现不可控的情况:
hive> SELECT * FROM fracture_act JOIN fracture_ads
> WHERE fracture_act.planner_id = fracture_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 fracture_act JOIN fracture_ads
> ON (fracture_act.planner_id = fracture_ads.planner_id);
... normal results ...

归纳:

1.对分区表进行查询,必须使用where+分区字段来限制范围。

2.使用orderby查询的时候,必须加上limit限制,因为执行order by的时候,已经将所有的数据放到了一个reduce中了。

3.限制笛卡尔积的查询,因为在关系型数据库中,可以使用where充当on,但是在hive数据仓库中,必须使用on。

Hive 非严格模式

hive配置中对hive.exec.dynamic.partition.mode的说法如下:
在严格模式下,用户必须指定至少一个静态分区
以防用户意外覆盖所有分区。
在非严格模式下,所有分区都允许是动态的。

事实上,我们很多时候都需要设置为非严格模式

设置成非严格模式的两种方式:
1.每次hive会话的时候设置如下参数:
set hive.exec.dynamic.partition.mode=nonstrict;
不加会报错:Error: org.apache.spark.SparkException: Dynamic partition strict mode requires at least one static partition column. To turn this off set hive.exec.dynamic.partition.mode=nonstrict (state=,code=0)
提示够明显吧?

2.在配置中修改参数,使之成为永久的,就不需要每次使用都去设置了,累人
修改conf中的hive-default.xml.template:
cp hive-default.xml.template hive-default.xml
vi hive-default.xml
找到hive.exec.dynamic.partition.mode 将值:strict改为nonstrict,重启hive使之生效即可 


————————————————

 Hive JOIN

写join查询时,需要注意几个关键点:

1)只支持等值join,因为非等值连接非常难转化为MapReduce任务

示例:select a.* from a join b on a.id = b.id是正确的,然而:select a.* from a join b on a.id>b.id是错误的。

2)可以join多个表,如果join中多个表的join的列是同一个,则join会被转化为单个MapReduce任务

示例:select a.*, b.*, c.* from a join b on a.col= b.col1 join c on c.col= b.col1被转化为单个MapReduce任务,因为join中只使用了b.col1作为join列。

但是如下写法会被转化为2个MapReduce任务。因为 b.col1用于第一次join条件,而 b.col2用于第二次 join

select a.*, b.*, c.* from a join b on a.col= b.col1 join c on c.col= b.col2;

3)join时,转换为MapReduce任务的逻辑

reduce会缓存join序列中除了最后一个表的所有表的记录(具体看启动了几个map/reduce任务),再通过最后一个表将结果序列化到文件系统。这一实现有助于在reduce端减少内存的使用量。实践中,应该把最大的那个表写在最后(否则会因为缓存浪费大量内存)。示例:a.单个map/reduce任务select a.*, b.*, c.* from a join b on a.col= b.col1 join c on c.col= b.col1中所有表都使用同一个join列。reduce端会缓存a表和b表的记录,然后每次取得一个c表的记录就计算一次join结果;b.多个map/reduce任务

select a.*, b.*, c.* from a join b on (a.col= b.col1) join c on (c.col= b.col2)。第一次缓存a表,用b表序列化;第二次缓存第一次MapReduce任务的结果,然后用c表序列化。

4)left semi join

经常用来替换 in和exists。

如,select * from a left semi join b on a.id = b.id; 相当于select * from a where a.id in (select b.id from b);但这种方式在hive中效率极低。

posted @   《彼岸花开》  阅读(881)  评论(0编辑  收藏  举报
相关博文:
阅读排行:
· 无需6万激活码!GitHub神秘组织3小时极速复刻Manus,手把手教你使用OpenManus搭建本
· C#/.NET/.NET Core优秀项目和框架2025年2月简报
· 一文读懂知识蒸馏
· Manus爆火,是硬核还是营销?
· 终于写完轮子一部分:tcp代理 了,记录一下
点击右上角即可分享
微信分享提示