大数据之Hive（十一）：Hive大厂面试真题（建议收藏）
1. hive内部表和外部表的区别
未被external修饰的是内部表，被external修饰的为外部表。
区别：
-
内部表数据由Hive自身管理，外部表数据由HDFS管理；
-
内部表数据存储的位置是
hive.metastore.warehouse.dir（默认：/user/hive/warehouse），外部表数据的存储位置由自己制定（如果没有LOCATION，Hive将在HDFS上的/user/hive/warehouse文件夹下以外部表的表名创建一个文件夹，并将属于这个表的数据存放在这里）； -
删除内部表会直接删除元数据（metadata）及存储数据；删除外部表仅仅会删除元数据，HDFS上的文件并不会被删除。
2. Hive有索引吗
Hive支持索引（3.0版本之前），但是Hive的索引与关系型数据库中的索引并不相同，比如，Hive不支持主键或者外键。并且Hive索引提供的功能很有限，效率也并不高，因此Hive索引很少使用。
-
索引适用的场景：
适用于不更新的静态字段。以免总是重建索引数据。每次建立、更新数据后，都要重建索引以构建索引表。
-
Hive索引的机制如下：
hive在指定列上建立索引，会产生一张索引表（Hive的一张物理表），里面的字段包括：索引列的值、该值对应的HDFS文件路径、该值在文件中的偏移量。
Hive 0.8版本后引入bitmap索引处理器，这个处理器适用于去重后，值较少的列（例如，某字段的取值只可能是几个枚举值） 因为索引是用空间换时间，索引列的取值过多会导致建立bitmap索引表过大。
注意：Hive中每次有数据时需要及时更新索引，相当于重建一个新表，否则会影响数据查询的效率和准确性，Hive官方文档已经明确表示Hive的索引不推荐被使用，在新版本的Hive中已经被废弃了。
扩展：Hive是在0.7版本之后支持索引的，在0.8版本后引入bitmap索引处理器，在3.0版本开始移除索引的功能，取而代之的是2.3版本开始的物化视图，自动重写的物化视图替代了索引的功能。
3. 运维如何对hive进行调度
-
将hive的sql定义在脚本当中；
-
使用azkaban或者oozie进行任务的调度；
-
监控任务调度页面。
4. ORC、Parquet等列式存储的优点
ORC和Parquet都是高性能的存储方式，这两种存储格式总会带来存储和性能上的提升。
Parquet:
-
Parquet支持嵌套的数据模型，类似于Protocol Buffers，每一个数据模型的schema包含多个字段，每一个字段有三个属性：重复次数、数据类型和字段名。
重复次数可以是以下三种：required(只出现1次)，repeated(出现0次或多次)，optional(出现0次或1次)。每一个字段的数据类型可以分成两种：group(复杂类型)和primitive(基本类型)。 -
Parquet中没有Map、Array这样的复杂数据结构，但是可以通过repeated和group组合来实现的。
-
由于Parquet支持的数据模型比较松散，可能一条记录中存在比较深的嵌套关系，如果为每一条记录都维护一个类似的树状结可能会占用较大的存储空间，因此Dremel论文中提出了一种高效的对于嵌套数据格式的压缩算法：Striping/Assembly算法。通过Striping/Assembly算法，parquet可以使用较少的存储空间表示复杂的嵌套格式，并且通常Repetition level和Definition level都是较小的整数值，可以通过RLE算法对其进行压缩，进一步降低存储空间。
-
Parquet文件是以二进制方式存储的，是不可以直接读取和修改的，Parquet文件是自解析的，文件中包括该文件的数据和元数据。
ORC:
-
ORC文件是自描述的，它的元数据使用Protocol Buffers序列化，并且文件中的数据尽可能的压缩以降低存储空间的消耗。
-
和Parquet类似，ORC文件也是以二进制方式存储的，所以是不可以直接读取，ORC文件也是自解析的，它包含许多的元数据，这些元数据都是同构ProtoBuffer进行序列化的。
-
ORC会尽可能合并多个离散的区间尽可能的减少I/O次数。
-
ORC中使用了更加精确的索引信息，使得在读取数据时可以指定从任意一行开始读取，更细粒度的统计信息使得读取ORC文件跳过整个row group，ORC默认会对任何一块数据和索引信息使用ZLIB压缩，因此ORC文件占用的存储空间也更小。
-
在新版本的ORC中也加入了对Bloom Filter的支持，它可以进一 步提升谓词下推的效率，在Hive 1.2.0版本以后也加入了对此的支 持。
5. 数据建模用的哪些模型？
1. 星型模型
星形模式
星形模式(Star Schema)是最常用的维度建模方式。星型模式是以事实表为中心，所有的维度表直接连接在事实表上，像星星一样。星形模式的维度建模由一个事实表和一组维表成，且具有以下特点：
a. 维表只和事实表关联，维表之间没有关联；
b. 每个维表主键为单列，且该主键放置在事实表中，作为两边连接的外键；
c. 以事实表为核心，维表围绕核心呈星形分布。
2. 雪花模型
雪花模式
雪花模式(Snowflake Schema)是对星形模式的扩展。雪花模式的维度表可以拥有其他维度表的，虽然这种模型相比星型更规范一些，但是由于这种模型不太容易理解，维护成本比较高，而且性能方面需要关联多层维表，性能比星型模型要低。
3. 星座模型
星座模型
星座模式是星型模式延伸而来，星型模式是基于一张事实表的，而星座模式是基于多张事实表的，而且共享维度信息。前面介绍的两种维度建模方法都是多维表对应单事实表，但在很多时候维度空间内的事实表不止一个，而一个维表也可能被多个事实表用到。在业务发展后期，绝大部分维度建模都采用的是星座模式。
数仓建模详细介绍可查看：通俗易懂数仓建模
6. 为什么要对数据仓库分层？
-
用空间换时间，通过大量的预处理来提升应用系统的用户体验（效率），因此数据仓库会存在大量冗余的数据。
-
如果不分层的话，如果源业务系统的业务规则发生变化将会影响整个数据清洗过程，工作量巨大。
-
通过数据分层管理可以简化数据清洗的过程，因为把原来一步的工作分到了多个步骤去完成，相当于把一个复杂的工作拆成了多个简单的工作，把一个大的黑盒变成了一个白盒，每一层的处理逻辑都相对简单和容易理解，这样我们比较容易保证每一个步骤的正确性，当数据发生错误的时候，往往我们只需要局部调整某个步骤即可。
数据仓库详细介绍可查看：万字详解整个数据仓库建设体系
7. 使用过Hive解析JSON串吗
Hive处理json数据总体来说有两个方向的路走：
-
将json以字符串的方式整个入Hive表，然后通过使用UDF函数解析已经导入到hive中的数据，比如使用
LATERAL VIEW json_tuple的方法，获取所需要的列名。 -
在导入之前将json拆成各个字段，导入Hive表的数据是已经解析过的。这将需要使用第三方的 SerDe。
详细介绍可查看：Hive解析Json数组超全讲解
8. sort by 和 order by 的区别
order by 会对输入做全局排序，因此只有一个reducer（多个reducer无法保证全局有序）只有一个reducer，会导致当输入规模较大时，需要较长的计算时间。
sort by不是全局排序，其在数据进入reducer前完成排序. 因此，如果用sort by进行排序，并且设置mapred.reduce.tasks>1， 则sort by只保证每个reducer的输出有序，不保证全局有序。
9. 数据倾斜怎么解决
数据倾斜问题主要有以下几种：
-
空值引发的数据倾斜
-
不同数据类型引发的数据倾斜
-
不可拆分大文件引发的数据倾斜
-
数据膨胀引发的数据倾斜
-
表连接时引发的数据倾斜
-
确实无法减少数据量引发的数据倾斜
以上倾斜问题的具体解决方案可查看：Hive千亿级数据倾斜解决方案
注意：对于 left join 或者 right join 来说，不会对关联的字段自动去除null值，对于 inner join 来说，会对关联的字段自动去除null值。
小伙伴们在阅读时注意下，在上面的文章（Hive千亿级数据倾斜解决方案）中，有一处sql出现了上述问题（举例的时候原本是想使用left join的，结果手误写成了join）。此问题由公众号读者发现，感谢这位读者指正。
10. Hive 小文件过多怎么解决
1. 使用 hive 自带的 concatenate 命令，自动合并小文件
使用方法：
#对于非分区表
alter table A concatenate;
#对于分区表
alter table B partition(day=20201224) concatenate;
注意：
1、concatenate 命令只支持 RCFILE 和 ORC 文件类型。
2、使用concatenate命令合并小文件时不能指定合并后的文件数量，但可以多次执行该命令。
3、当多次使用concatenate后文件数量不在变化，这个跟参数 mapreduce.input.fileinputformat.split.minsize=256mb 的设置有关，可设定每个文件的最小size。
2. 调整参数减少Map数量
设置map输入合并小文件的相关参数（执行Map前进行小文件合并）：
在mapper中将多个文件合成一个split作为输入（CombineHiveInputFormat底层是Hadoop的CombineFileInputFormat方法）：
set hive.input.format=org.apache.hadoop.hive.ql.io.CombineHiveInputFormat; -- 默认
每个Map最大输入大小（这个值决定了合并后文件的数量）：
set mapred.max.split.size=256000000; -- 256M
一个节点上split的至少大小（这个值决定了多个DataNode上的文件是否需要合并）：
set mapred.min.split.size.per.node=100000000; -- 100M
一个交换机下split的至少大小(这个值决定了多个交换机上的文件是否需要合并)：
set mapred.min.split.size.per.rack=100000000; -- 100M
3. 减少Reduce的数量
reduce 的个数决定了输出的文件的个数，所以可以调整reduce的个数控制hive表的文件数量。
hive中的分区函数 distribute by 正好是控制MR中partition分区的，可以通过设置reduce的数量，结合分区函数让数据均衡的进入每个reduce即可：
#设置reduce的数量有两种方式，第一种是直接设置reduce个数
set mapreduce.job.reduces=10;
#第二种是设置每个reduce的大小，Hive会根据数据总大小猜测确定一个reduce个数
set hive.exec.reducers.bytes.per.reducer=5120000000; -- 默认是1G，设置为5G
#执行以下语句，将数据均衡的分配到reduce中
set mapreduce.job.reduces=10;
insert overwrite table A partition(dt)
select * from B
distribute by rand();
对于上述语句解释：如设置reduce数量为10，使用 rand()， 随机生成一个数 x % 10 ， 这样数据就会随机进入 reduce 中，防止出现有的文件过大或过小。
4. 使用hadoop的archive将小文件归档
Hadoop Archive简称HAR，是一个高效地将小文件放入HDFS块中的文件存档工具，它能够将多个小文件打包成一个HAR文件，这样在减少namenode内存使用的同时，仍然允许对文件进行透明的访问。
#用来控制归档是否可用
set hive.archive.enabled=true;
#通知Hive在创建归档时是否可以设置父目录
set hive.archive.har.parentdir.settable=true;
#控制需要归档文件的大小
set har.partfile.size=1099511627776;
使用以下命令进行归档：
ALTER TABLE A ARCHIVE PARTITION(dt='2021-05-07', hr='12');
对已归档的分区恢复为原文件：
ALTER TABLE A UNARCHIVE PARTITION(dt='2021-05-07', hr='12');
注意:
归档的分区可以查看不能 insert overwrite，必须先 unarchive
Hive 小文件问题具体可查看：解决hive小文件过多问题
11. Hive优化有哪些
1. 数据存储及压缩：
针对hive中表的存储格式通常有orc和parquet，压缩格式一般使用snappy。相比与textfile格式表，orc占有更少的存储。因为hive底层使用MR计算架构，数据流是hdfs到磁盘再到hdfs，而且会有很多次，所以使用orc数据格式和snappy压缩策略可以降低IO读写，还能降低网络传输量，这样在一定程度上可以节省存储，还能提升hql任务执行效率；
2. 通过调参优化：
并行执行，调节parallel参数；
调节jvm参数，重用jvm；
设置map、reduce的参数；开启strict mode模式；
关闭推测执行设置。
3. 有效地减小数据集将大表拆分成子表；结合使用外部表和分区表。
4. SQL优化
-
大表对大表：尽量减少数据集，可以通过分区表，避免扫描全表或者全字段；
-
大表对小表：设置自动识别小表，将小表放入内存中去执行。
Hive优化详细剖析可查看：Hive企业级性能优化
附：九个最易出错的SQL讲解
阅读本节小建议：本文适合细嚼慢咽，不要一目十行，不然会错过很多有价值的细节。
在进行数仓搭建和数据分析时最常用的就是 sql，其语法简洁明了，易于理解，目前大数据领域的几大主流框架全部都支持sql语法，包括 hive，spark，flink等，所以sql在大数据领域有着不可替代的作用，需要我们重点掌握。
在使用sql时如果不熟悉或不仔细，那么在进行查询分析时极容易出错，接下来我们就来看下几个容易出错的sql语句及使用注意事项。
1. decimal
hive 除了支持 int,double,string等常用类型，也支持 decimal 类型，用于在数据库中存储精确的数值，常用在表示金额的字段上
注意事项：
如：decimal(11,2) 代表最多有11位数字，其中后2位是小数，整数部分是9位；
如果整数部分超过9位，则这个字段就会变成null，如果整数部分不超过9位，则原字段显示；
如果小数部分不足2位，则后面用0补齐两位，如果小数部分超过两位，则超出部分四舍五入；
也可直接写 decimal，后面不指定位数，默认是 decimal(10,0) 整数10位，没有小数
2. location
表创建的时候可以用 location 指定一个文件或者文件夹
create table stu(id int ,name string) location '/user/stu2';
注意事项：
创建表时使用location， 当指定文件夹时，hive会加载文件夹下的所有文件，当表中无分区时，这个文件夹下不能再有文件夹，否则报错。
当表是分区表时，比如 partitioned by (day string)， 则这个文件夹下的每一个文件夹就是一个分区，且文件夹名为 day=20201123 这种格式，然后使用：msck repair table score; 修复表结构，成功之后即可看到数据已经全部加载到表当中去了
3. load data 和 load data local
从hdfs上加载文件
load data inpath '/hivedatas/techer.csv' into table techer;
从本地系统加载文件
load data local inpath '/user/test/techer.csv' into table techer;
注意事项：
-
使用 load data local 表示从本地文件系统加载，文件会拷贝到hdfs上
-
使用 load data 表示从hdfs文件系统加载，文件会直接移动到hive相关目录下，注意不是拷贝过去，因为hive认为hdfs文件已经有3副本了，没必要再次拷贝了
-
如果表是分区表，load 时不指定分区会报错
-
如果加载相同文件名的文件，会被自动重命名
4. drop 和 truncate
删除表操作
drop table score1;
清空表操作
truncate table score2;
注意事项：
如果 hdfs 开启了回收站，drop 删除的表数据是可以从回收站恢复的，表结构恢复不了，需要自己重新创建；truncate 清空的表是不进回收站的，所以无法恢复truncate清空的表。
所以 truncate 一定慎用，一旦清空除物理恢复外将无力回天
5. join 连接
INNER JOIN 内连接：只有进行连接的两个表中都存在与连接条件相匹配的数据才会被保留下来
select * from techer t [inner] join course c on t.t_id = c.t_id; -- inner 可省略
LEFT OUTER JOIN 左外连接：左边所有数据会被返回，右边符合条件的被返回
select * from techer t left join course c on t.t_id = c.t_id; -- outer可省略
RIGHT OUTER JOIN 右外连接：右边所有数据会被返回，左边符合条件的被返回、
select * from techer t right join course c on t.t_id = c.t_id;
FULL OUTER JOIN 满外(全外)连接: 将会返回所有表中符合条件的所有记录。如果任一表的指定字段没有符合条件的值的话，那么就使用NULL值替代。
SELECT * FROM techer t FULL JOIN course c ON t.t_id = c.t_id ;
注意事项：
-
hive2版本已经支持不等值连接，就是 join on条件后面可以使用大于小于符号;并且也支持 join on 条件后跟or (早前版本 on 后只支持 = 和 and，不支持 > < 和 or)
-
如hive执行引擎使用MapReduce，一个join就会启动一个job，一条sql语句中如有多个join，则会启动多个job
注意：表之间用逗号(,)连接和 inner join 是一样的，例：
select tableA.id, tableB.name from tableA , tableB where tableA.id=tableB.id;
和
select tableA.id, tableB.name from tableA join tableB on tableA.id=tableB.id;
它们的执行效率没有区别，只是书写方式不同，用逗号是sql 89标准，join 是sql 92标准。用逗号连接后面过滤条件用 where ，用 join 连接后面过滤条件是 on。
6. left semi join
为什么把这个单独拿出来说，因为它和其他的 join 语句不太一样，
这个语句的作用和 in/exists 作用是一样的，是 in/exists 更高效的实现
SELECT A.* FROM A where id in (select id from B)
SELECT A.* FROM A left semi join B ON A.id=B.id
上述两个 sql 语句执行结果完全一样，只不过第二个执行效率高
注意事项：
-
left semi join 的限制是：join 子句中右边的表只能在 on 子句中设置过滤条件，在 where 子句、select 子句或其他地方过滤都不行。
-
left semi join 中 on 后面的过滤条件只能是等于号，不能是其他的。
-
left semi join 是只传递表的 join key 给 map 阶段，因此left semi join 中最后 select 的结果只许出现左表。
-
因为 left semi join 是 in(keySet) 的关系，遇到右表重复记录，左表会跳过
7. 聚合函数中 null 值
hive支持 count(),max(),min(),sum(),avg() 等常用的聚合函数
注意事项：
聚合操作时要注意 null 值：
count(*) 包含 null 值，统计所有行数；
count(id) 不包含id为 null 的值；
min 求最小值是不包含 null，除非所有值都是 null；
avg 求平均值也是不包含 null。
以上需要特别注意，null 值最容易导致算出错误的结果
8. 运算符中 null 值
hive 中支持常用的算术运算符(+,-,*,/)
比较运算符(>, <, =)
逻辑运算符(in, not in)
以上运算符计算时要特别注意 null 值
注意事项：
-
每行中的列字段相加或相减，如果含有 null 值，则结果为 null
例：有一张商品表（product）
| id | price | dis_amount |
|---|---|---|
| 1 | 100 | 20 |
| 2 | 120 | null |
各字段含义： id (商品id)、price (价格)、dis_amount (优惠金额)
我想算每个商品优惠后实际的价格，sql如下：
select id, price - dis_amount as real_amount from product;
得到结果如下：
| id | real_amount |
|---|---|
| 1 | 80 |
| 2 | null |
id=2的商品价格为 null，结果是错误的。
我们可以对 null 值进行处理，sql如下：
select id, price - coalesce(dis_amount,0) as real_amount from product;
使用 coalesce 函数进行 null 值处理下，得到的结果就是准确的
coalesce 函数是返回第一个不为空的值
如上sql：如果dis_amount不为空，则返回dis_amount，如果为空，则返回0
-
小于是不包含 null 值，如 id < 10；是不包含 id 为 null 值的。
-
not in 是不包含 null 值的，如 city not in ('北京','上海')，这个条件得出的结果是 city 中不包含 北京，上海和 null 的城市。
9. and 和 or
在sql语句的过滤条件或运算中，如果有多个条件或多个运算，我们都会考虑优先级，如乘除优先级高于加减，乘除或者加减它们之间优先级平等，谁在前就先算谁。那 and 和 or 呢，看似 and 和 or 优先级平等，谁在前先算谁，但是，and 的优先级高于 or。
注意事项：
例：
还是一张商品表（product）
| id | classify | price |
|---|---|---|
| 1 | 电器 | 70 |
| 2 | 电器 | 130 |
| 3 | 电器 | 80 |
| 4 | 家具 | 150 |
| 5 | 家具 | 60 |
| 6 | 食品 | 120 |
我想要统计下电器或者家具这两类中价格大于100的商品，sql如下：
select * from product where classify = '电器' or classify = '家具' and price>100
得到结果
| id | classify | price |
|---|---|---|
| 1 | 电器 | 70 |
| 2 | 电器 | 130 |
| 3 | 电器 | 80 |
| 4 | 家具 | 150 |
结果是错误的，把所有的电器类型都查询出来了，原因就是 and 优先级高于 or，上面的sql语句实际执行的是，先找出 classify = '家具' and price>100 的，然后在找出 classify = '电器' 的
正确的 sql 就是加个括号，先计算括号里面的：
select * from product where (classify = '电器' or classify = '家具') and price>100