Hive常用面试题

一、Hive内部表与外部表的区别

  未被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分区过多有何坏处以及分区时的注意事项

  1. 当分区过多且数据很大时,可以使用严格模式,避免触发一个大的mapreduce任务。当分区数量过多且数据量较大时,执行宽范围的数据扫描,会触发一个很大的mapreduce任务。在严格模式下,当where中没有分区过滤条件会禁止执行。

  2. hive如果有过多的分区,由于底层是存储在HDFS上,HDFS上只用于存储大文件而非小文件,因为过多的分区会增加namenode的负担。

  3. hive转换为mapreduce,mapreduce会转化为多个task。过多小文件的话,每个文件一个task,每个task一个JVM实例,JVM的开销和销毁会降低系统效率。

五、hive分桶管理

  1. 原理

    跟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?

  1. 在本地模式下,hive可以简单的读取目录路径下的数据,然后输出格式化后的数据到控制台。比如本地员工表employee,当执行select * from employee 时直接将文件中数据格式化输出。

  2. 查询语句中的过滤条件只是分区字段的情况下不会进行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 基础优化

  1. 小表前置

最常见的hash join方法中,一般总有一张相对小的表和一张相对大的表,小表叫build table,大表叫probe table.

  1. 多表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解决;

    • 3-原因:单个文件大小稍稍大于配置的block块的大小,此时需要适当增加map的个数。解决方法:set mapred.map.tasks的个数;

    • 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任务去做,肯定也比较耗时。

  • 针对上面的问题2和3,我们需要采取两种方式来解决:即减少map数和增加map数;

posted @ 2021-09-13 17:10  Arish  阅读(763)  评论(0编辑  收藏  举报