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