未被external修饰的是内部表,被external修饰的是外部表;
区别:
内部表数据由hive自身管理,外部表数据由HDFS管理;
内部表数据存储位置是hive.metastore.warehouse.dir(默认:/user/hive/warehouse),外部表数据的存储位置由自己指定(如果没有location,hive将hdfs上的 /user/hive/warehouse 文件夹下以外部表的名字创建一个文件夹,并将属于这个表的数据存放在这里);
删除内部表会直接删除元数据及存储数据;删除外部表仅仅会删除元数据,HDFS上文件并不会被删除;
对内部表的修改会将修改直接同步给元数据,而对外部表的表结构和分区进行修改,则需要修改(MSCK REPAIR TABLE table_name);
二、hive与传统数据库的区别
由于HIVE采用了SQL查询语言HQL,因此很容易将hive理解为数据库。其实从结构上来看,hive和数据库除了拥有类似的查询语言,再无类似之处。
数据存储位置:HQL 存储在HDFS上,而SQL存在在 raw 磁盘或者本地文件系统
数据格式:HQL 用户定义,而SQL由系统决定
数据更新:HQL 不支持 ;SQL支持
索引:HQL 无 ;SQL 有
执行:HQL 使用MapReduce ;Sql 执行器
执行延迟:HQL 延迟高;sql低
可扩展性:HQL 扩展性高;SQL扩展性低
数据规模:HQL 数据规模大;SQL 数据规模小
三、 hive分区介绍
在hive select查询中一般会扫描整个表内容,会消耗很多时间做没必要的工作。有时候只需要扫描表中关心的一部分数据,一次建表时引入了partition的概念。
分区表指的是在创建表的时候指定的partition的分区空间。
在hive中,表的一个partition对应于表下的一个目录,所有的partition的数据都存储在最子集的目录里。
总的来说,partition就是辅助查询,缩小查询范围,加快数据的检索速度和对数据按照一定的规格和条件进行管理。
四、Hive分区过多有何坏处以及分区时的注意事项
-
当分区过多且数据很大时,可以使用严格模式,避免触发一个大的mapreduce任务。当分区数量过多且数据量较大时,执行宽范围的数据扫描,会触发一个很大的mapreduce任务。在严格模式下,当where中没有分区过滤条件会禁止执行。
-
hive如果有过多的分区,由于底层是存储在HDFS上,HDFS上只用于存储大文件而非小文件,因为过多的分区会增加namenode的负担。
-
hive转换为mapreduce,mapreduce会转化为多个task。过多小文件的话,每个文件一个task,每个task一个JVM实例,JVM的开销和销毁会降低系统效率。
五、hive分桶管理
-
原理
跟MR中的HashPartition的原理一模一样
MR中:按照key的hash值去模除以reducetask的个数
HIVE中:按照分桶字段的hash值去模除以分桶的个数
2 . hive分桶的作用
方便抽样、提高join查询效率
3.hive分桶和分区的区别
分桶表和分区表的桶数和分区数的决定机制:
分桶表的个数:由用户HQL语句所设置的reduce Task的个数决定
表的分区个数:也能由用户定义,也能由程序自动生成,分区是可以动态增长的。
个数区别:
• 分桶表一经决定,就不能更改,所以如果有要改变桶数,要重新插入分桶数据;
• 分区数是可以动态增长的。如log日志,一天存一个分区
4.hive分桶操作
首先创建一个分桶的空表,然后创建一个临时表,往临时表中导入数据,然后从临时表中分桶查询出来的数据insert到分桶的空表里。
4.1创建分桶表
```
create table bck_student(
id int,
name string,
sex string,
age int,
department string
) clustered by(sex) into 2 buckets row format delimited fields
terminated by ",";
```
4.2 创建临时表并导入数据
```
create table student(
id int,
name string,
sex string,
age int,
department string
) row format delimited fields terminated by ",";
load data local inpath "/home/hadoop/student.dat" into table student;
select * from student
```
4.3 从临时表中分桶查询出来的数据insert到分桶的空表里
```
# 开启分桶
set hive.enforce.bucketing=true;
set mapreduce.job.reduces=2;
# 注意上面的set mapreduce.job.reduces的数量要和分桶数量一样
insert into table bck_student select id,name,sex,age,department from student distribute by sex;
```
4.4 对分桶数据进行抽样查询
```
select * from bck_student tablesample(bucket 1 out of2on sex)
# select * from bck_student tablesample(0.1 percent);
```
六.Hive中复杂数据类型的使用好处与坏处
好处:由于复杂数据类型的存储数据比基本数据类型要多,在存盘上可以连续存储,在查询等操作时可以减少磁盘IO
坏处:复杂数据类型可能会存在着数据的重复,而且有更大的导致数据不一致的风险。
七.Hive元数据库是用来做什么的,存储哪些信息?
本质上只是用来存储hive中有哪些数据库,哪些表,表的模式,目录,分区,索引以及命名空间。为数据库创建的目录一般在hive数据仓库目录下。
八.Hive什么情况下可以避免进行mapreduce?
-
在本地模式下,hive可以简单的读取目录路径下的数据,然后输出格式化后的数据到控制台。比如本地员工表employee,当执行select * from employee 时直接将文件中数据格式化输出。
-
查询语句中的过滤条件只是分区字段的情况下不会进行mapreduce。
九.hive、HQL常用优化
1、列裁剪和分区裁剪
最基本的操作,查询时只读取需要的列和只读取需要的分区。
2.谓词下推
就是将SQL中where谓词逻辑尽可能的提前执行,减少下游处理的数据量。
3.sort by 代替 order by
hql中的order by与其他SQL方言中的功能一样,就是将结果按某字段全局排序,这会导致所有map端数据都进入一个reducer中,在数据量大的时候可能会长时间计算不完。
如果使用sort by,那么会视情况启动多个reducer进行排序,并且保证每个人reducer内局部有序。为了控制map端数据分配到reducer的key,往往还要配合distribute by 一同使用。如果不加distribute by 的话,map端数据就会随机分配到reducer。
4.group by 代替distinct
当统计某一列去重时候,如果数据量很大,count(distinct)就会非常慢,原因与order by类似。
5.join 基础优化
-
小表前置
最常见的hash join方法中,一般总有一张相对小的表和一张相对大的表,小表叫build table,大表叫probe table.
-
多表join时,key相同
https://www.jianshu.com/p/8e2f2f0d4b6c
十、hive数据倾斜原因以及主要解决办法
1、 hive倾斜之group by 聚合倾斜
-
原因:
分组的纬度过少,每个维度的值过多,导致处理某值得reduce耗时很久;
对一些类型统计的时候某种类型的数据量特别多,其他的数据类型特别少,当按照类型进行group by的时候,会将相同的group by 字段的reduce任务需要的数据拉取到同一个节点进行聚合,而当其中每一组的数据量过大时,会出现其他组的计算已经完成这个reduce还没有计算完成,其他的节点一直等待这个节点的任务执行完成,所以会看到map 100% 而reduce 99%的情况
解决办法
set hive.map.aggr=true;
set hive.groupby.skewindata=true;原理:
hive.map.aggr 这个配置代表开启map端聚合
hive.groupby.skewindata=true,当选项设定为true,生成的查询计划会有连个MR job。当第一个MR Job中,Map的输出结果结合会随机分布到Reduce中,每个Reduce做部分聚合操作,并输出结果。这样处理的结果是相同的Group By Key有可能被分发到不同的Reduce中,从而达到负载均衡的目的。第二个MR Job再根据预处理的数据结果按照Group By Key分布到reduce中,这个过程可以保证相同的key被分到同一个reduce中,最后完成最终的聚合操作。
Hive倾斜之Map和Reduce优化
-
1-原因:当出现小文件过多,需要合并小文件。可以通过set hive.merge.mapredfiles=true来解决;
-
2-原因:输入数据存在大块和小块的严重问题,比如 说:一个大文件128M,还有1000个小文件,每 个1KB。 解决方法:任务输入前做文件合并,将众多小文件合并成一个大文件。通过set hive.merge.mapredfiles=true解决;
-
-
4-原因:文件大小适中,但是map端计算量非常大,如:select id,count(*),sum(case when...),sum(case when ...)...需要增加map个数。解决方法:set mapred.map.tasks个数,set mapred.reduce.tasks个数;
Hive倾斜之HQL中包含count(distinct)时
-
如果数据量非常大,执行如select a,count(distinct b) from t group by a;类型的sql时,会出现数据倾斜的问题。
-
解决方法:使用sum...group by代替。如:select a,sum(1) from(select a,b from t group by a,b) group by a;
Hive倾斜之HQL中join优化
-
当遇到一个大表和一个小表进行join操作时。使用mapjoin将小表加载到内存中。如:select /*+ MAPJOIN(a) */ a.c1, b.c1 ,b.c2 from a join b where a.c1 = b.c1;
-
遇到需要进行join,但是关联字段有数据为null,如表一的id需要和表二的id进行关联;
-
-
解决方法1:id为null的不参与关联 比如:
select * from log a
join users b
on a.id is not null and a.id = b.id
union all
select * from log a
where a.id is null;
-
解决方法2: 给null值分配随机的key值 比如:
select * from log a
left outer join users b
on
case when a.user_id is null
then concat(‘hive’,rand() )
else a.user_id end = b.user_id;
合理设置Map数
对上文描述的总结
-
1)通常情况下,作业会通过input的目录产生一个或者多个map任务。 主要的决定因素有:input的文件总个数,input的文件大小,集群设置的文件块大小。
-
2)是不是map数越多越好? 答案是否定的。如果一个任务有很多小文件(远远小于块大小128m),则每个小文件也会被当做一个块,用一个map任务来完成,而一个map任务启动和初始化的时间远远大于逻辑处理的时间,就会造成很大的资源浪费。而且,同时可执行的map数是受限的。
-
3)是不是保证每个map处理接近128m的文件块,就高枕无忧了? 答案也是不一定。比如有一个127m的文件,正常会用一个map去完成,但这个文件只有一个或者两个小字段,却有几千万的记录,如果map处理的逻辑比较复杂,用一个map任务去做,肯定也比较耗时。
-