Hive 是基于 Hadoop 的数据仓库工具，可以将结构化的数据文件映射为一张表，并提供类似 SQL 查询功能。
Hive 本质就是将 HQL 转化成 MapReduce 程序(MR引擎)。
Hive 的优点：
Hive 的 缺点：
Hive 的 HQL 表达能力有限
Hive 的效率比较低
用户接口：Client
CLI（command-line interface）、JDBC/ODBC(jdbc 访问 hive)、WEBUI（浏览器访问 hive）
元数据：Metastore
元数据包括：表名、表所属的数据库（默认是 default）、表的拥有者、列/分区字段、表的类型（是否是外部表）、表的数据所在目录等；默认存储在自带的 derby(单用户访问) 数据库中，推荐使用 MySQL 存储 Metastore。
Hadoop
使用 HDFS 进行存储，使用 MapReduce 进行计算。
详见 [内部架构](# 2. HQL 转化为 MR 过程)
HQL -> AST(抽象语法树) -> QB(查询块) -> OperatorTree(操作树) -> 优化OperatorTree -> MR Job -> 优化MR Job
SQL Parser(SQL 解析器)：Antlr定义SQL的语法规则，完成SQL词法，语法解析，将SQL转化为抽象语法树(AST Tree)。
Semantic Analyzer(语义分析器)：遍历AST Tree，抽象出查询的基本组成单元 查询块( QueryBlock)。
Logical plan Generator(逻辑计划生成器)：遍历QueryBlock，翻译为执行操作树( OperatorTree)。
Logical plan optimizer(逻辑计划优化器): 逻辑层优化器进行OperatorTree变换，减少 shuffle数据量。
Physical plan Generator(物理计划生成器)：遍历OperatorTree，翻译为MapReduce任务(MR Job)。
Physical plan optimizer(物理计划优化器)：物理层优化器进行MapReduce任务的优化，生成最终的执行计划。
Hive是基于Hadoop的数据仓库工具，可以将结构化的数据文件映射为一张数据库表，并提供完整的sql 查询功能，可以将sql语句转换为MapReduce任务进行运行。其优点是学习成本低，可以通过类SQL语句快速实现简单的MapReduce统计，不必开发专门的MapReduce应用，十分适合数据仓库的统计分析，但是Hive不支持实时查询。
Hive与关系型数据库的区别：
Single User Mode：默认安装hive，hive是使用derby内存数据库保存hive的元数据，这样是不可以并调用hive的。
User Mode：通过网络连接到一个数据库中，是最经常使用到的模式。假设使用本机mysql服务器存储元 数据。这种存储方式需要在本地运行一个mysql服务器，可并发调用。
Remote Server Mode：在服务器端启动一个 MetaStoreServer，客户端利用 Thrift 协议通MetaStoreServer 访问元数据库。
内部表：默认创建的表都是所谓的管理表，也叫内部表，Hive可以控制内部表数据的生命周期，内部表数据会保存在 hive.metastore.warehouse.dir这个参数目录的子目录下。当我们删除一个管理表时，Hive 也会删除内部表中数据。管理表不适合和其他工具共享数据。
外部表：EXTERNAL 关键字可以让用户创建一个外部表， Hive 认为自己并不完全拥有这份数据，所以删除该表只删除表的元数据信息，并不会删除掉这份数据。
使用场景：原始数据比如用户行为日志，业务数据等使用外部表，基于原始数据的临时表或者结果数据等，使用内部表，数据由外部表 Select + Insert 进入内部表。
目前hive支持简单的权限管理，Hive可以是基于元数据的权限管理，也可以基于文件存储级别的权限管理，默认情况下是不开启：
Hive授权的核心就是用户（user）、组（group）、角色（role）。
Hive中的角色和平常我们认知的RBAC角色是有区别的，Hive角色除了可以是权限的集合，还可以是角色的集合，类似于递归的概念。
行式存储：将表数据以行数据格式连续的存储在文件中，查询满足条件的整行数据时，行存储只需要找到其中一个值，其余的值都在相邻地方，列存储则需要去每个聚集的字段找到对应的每个列的值，所以此时行存储查询的速度更快，TEXTFILE 和 SEQUENCEFILE 都是基于行存储的；
列式存储：将表数据以列数据格式存储在文件中，在查询只需要少数几个字段的时候，能大大减少读取的数据量；每个字段的数据类型一定是相同的，列式存储可以针对性的设计更好的设计压缩算法。ORC 和 PARQUET 是基于列式存储的。
hive 表数据存储格式一般选择：orc 或 parquet，压缩方式一般选择 snappy 或 lzo(支持切片)。
TextFile：
默认格式，行存储，数据不做压缩，磁盘开销大，数据解析开销大。可结合 Gzip、Bzip2 使用，但使用 Gzip 这种方式，hive 不会对数据进行切分，从而无法对数据进行并行操作。
SequenceFile：
Hadoop API提供的一种二进制文件支持，，存储方式为行存储，其具有使用方便、可分割、 可压缩的特点。 SequenceFile支持三种压缩选择：NONE，RECORD，BLOCK。数据压缩率低，一般建议使用BLOCK 压缩。 优势是和Hadoop API 相互兼容，常被MapReduce优化使用，提高IO性能。
ORCFile：
Hive 0.11 版里引入的新的存储格式，由于Hive的数据来源是HDFS，HDFS存储的数据是海量的，这时候单纯使用列式存储，那么一列的数据量会相当大，检索起来自然比较慢。ORCFile的解决方案是，默认每一万行数据分块，每块使用列式存储，我称为 横切纵存， 并为他们创建一系列索引。
具体如下：
Stripe：ORCFile存储格式的基本单位。
Row Data: 默认一万行数据，采用列式存储，存储原始数据。
Index Data：Row Data 列式存储的 各个列偏移量。
Stripe Footer：存储 所在Stripe 元信息，比如长度大小等等。
FIile Footer：存储所有 Stripe 元信息，还有每列的元信息。
PostScript： 整个文件的压缩类型及FileFooter 长度信息等。
总结：通过分块列式存储以及块级别，表级别的索引，优化查询性能。
Parquet：
Parquet 文件是以二进制方式存储的，所以是不可以直接读取的，文件中包括该文件的数据和元数据，因此 Parquet 格式文件是自解析的。有如下概念：
行组(Row Group)：和ORC一样，Parquet 也是先将文件横切形成一个个的行组。
列块(Column Chunk)：在一个行组中每一列保存在一个列块中，所有列块连续的存储在行组中。一个列块中的值都是相同类型的，不同的列块可能使用不同的算法进行压缩。
页(Page)：每一个列块划分为多个页，一个页是最小的编码的单位，在同一个列块的不同页可能使用不同的编码方式。
通常情况下，在存储 Parquet 数据的时候会按照 Block 大小设置行组的大小，由于一般情况下每一个 Mapper 任务处理数据的最小单位是一个 Block，理想情况下可以，每一个行组由一个 Mapper 任务处理，这时的切片数据就是单独建好索引的文件数据，查询效率相当高。
add jar jar路径
create temporary function 函数名 as '类全名';
内连接：只有进行连接的两个表中都存在与连接条件相匹配的数据才会被保留下来。左外连接：JOIN 操作符左边表中符合 WHERE 子句的所有记录将会被返回。右外连接：JOIN 操作符右边表中符合 WHERE 子句的所有记录将会被返回。满外连接：full join 如果任一表的指定字段没有符合条件的值的话，那么就使用 NULL 值替代。多表连接：大多数情况下，Hive 会对每对 JOIN 连接对象启动一个 MapReduce 任务，但是如果果每个 on 子句都使用相同的连接键的话，那么只会产生一个 MapReduce job。SMB(Sort Merge Bucket join)：SMB 是 大表和大表Join的解决方案，它的核心在于，将Join的两个表都根据Join的key分桶(桶数量不要超过CPU数量，多种外键就创建多种分桶表)。这样做的好处，首先大表分区被划分为多个桶，即大表变小表，可以使用DistributeCache将数据缓存，而且由于Join 的两张表根据 join key 分桶，所以只需要将相同的 key 在Map阶段合并就能实现桶内数据全部 Join 完成，最后到 reducer 的数据其实已经是根据 key join 好数据，使得大表 Join 大表效率提升很大。将条目少的表/子查询放在 Join 操作符的左边，这是因为位于 Join 操作符左边的表的会被DistributeCache加载进内存，最右边的表以Stream的形式加入到任务中。内存加载的数据越小，网络IO开销越小，并且载入条目较少的表可以有效减少 OOM(out of memory) ，降低因为OOM失败而转移任务的风险。
Hive 已经帮我们优化了 Join 操作，底层会自动帮我们识别大小表，并优先将小表做缓存处理。另外 Hive 还提供 /*+ StreamTable(tableName)*/来指定 作为 Stream 的表。
查看 HQL 执行计划的语法是： EXPLAIN [EXTENDED | DEPENDENCY | AUTHORIZATION] query
Explain 会讲 查询的 包括Fetch，Map，Reduce 及 Output 等过程日志详细打印，查看哪个点不合理，优化。
Fetch 抓取是指，Hive 中对某些情况的查询可以不必使用 MapReduce 计算。例如：SELECT * FROM table，在这种情况下，Hive 可以简单地读取 table 对应的存储目录下的文件，然后输出查询结果到控制台。
在参数 hive.fetch.task.conversion 默认是 more，老版本 hive默认是 minimal，该属性修改为 more 以后，在全局查找、字段查找、limit 查找等都不走mapreduce。
大多数的 Hadoop Job 是需要 Hadoop 提供的完整的可扩展性来处理大数据集的。当 Hive 的输入数据量是非常小时，为查询触发执行任务消耗的时间可能会比实际 job 的执行时间要多的多。对于大多数这种情况，Hive 可以通过本地模式在单台机器上处理所有的任务。对于小数据集，执行时间可以明显被缩短。
用户可以通过设置 自动开启本地模式，并设置最大的本地模式 输入数据量和文件个数，来自动调节。
列处理：在 SELECT 中，只拿需要的列，如果有分区，尽量使用分区过滤，少用 SELECT *。
行处理：在分区剪裁中，当使用外关联时，如果将副表的过滤条件写在 Where 后面，那么就会先全表关联，之后再过滤。建议先将表数据过滤之后(子查询)，再进行关联，这样关联的数据少了，效率会更高。
尽量避免笛卡尔积，join 的时候不加或者无效的 on 条件，Hive 只能使用 1 个reducer 来完成笛卡尔积。
数据量大的情况下，由于 COUNT DISTINCT 操作需要用一个Reduce Task 来完成，这一个 Reduce 需要处理的数据量太大，就会导致整个 Job 很难完成，一般 COUNT DISTINCT 使用先 GROUP BY 再 COUNT 的方式替换（注意 group by 造成的数据倾斜问题）。举例如下：
-- 直接count(distinct) 1个MRJob,1个Reducer，数据量大很容易挤爆一个 Reducer
select count(distinct id) from table;
-- 先 Group by 再 count(distinct) 2个MRJob，hash均匀分布在设置的reducer中计
-- 去重分配的id。第二个MRJob，就是将上一步的所有id再去重一次。
select count(distinct id) from (select id from table group by id) tmp;
将 key 相对分散，并且数据量小的表放在 join 的左边，可以使用 Map Join 的 DistributeCache 让小的维度表先进内存。在 map 端完成 join，也可以手动指定 大表 /*+ StreamTable(tableName)*/。Map Join 适合小表Join大表，不适合 大表Join大表，因为小表需要再每一个 MapTask 中都存在，网络IO成本大。
实际测试发现：新版的 hive 已经对小表 JOIN 大表和大表 JOIN 小表进行了优化。小表放在左边和右边已经没有区别。
有时 join 超时是因为某些 key 对应的数据太多，而相同 key 对应的数据都会发送到相同的 reducer 上，从而导致数据倾斜或者内存不够。此时我们应该仔细分析这些异常的 key，很多情况下，这些 key 对应的数据是异常数据，我们需要在 SQL 语句中进行过滤。例如 key 对应的字段为空，如果对于我们无用，可以通过 where 子句来过滤。
上面说的情况中，如果 空key 对于查询有用，此时我们可以表的 key 为空的字段赋一个随机的值 (NVL(key，rand()))，使得数据随机均匀地分不到不同的 reducer 上。
SMB 是 大表和大表Join的解决方案，它的核心在于，将Join的两个表都根据Join的key分桶(桶数量不要超过CPU数量，多种外键就创建多种分桶表)。这样做的好处，首先大表分区被划分为多个桶，即大表变小表，可以使用DistributeCache将数据缓存，而且由于Join 的两张表根据 join key 分桶，所以只需要将相同的 key 在Map阶段合并就能完成桶内数据全部 Join，最后到 reducer 的数据其实已经是根据 key join 好的数据，简单合并一下就得到大表Join大表的数据，使得大表 Join 大表效率提升很大。
缺点是有一个以Join的Key作为分桶字段，如果某张大表具有多个与其它大表Join的key，那么就需要为每个Key进行创建分桶表，存储和数据装载成本大。
默认情况下，Map 阶段同一 Key 数据分发给一个 reduce，当一个 key 数据过大时就倾斜了。
并不是所有的聚合操作都需要在 Reduce 端完成，很多聚合操作都可以先在 Map 端进行部分聚合，最后在 Reduce 端得出最终结果。
开启 Map 端聚合参数设置：
set hive.map.aggr = true
set hive.groupby.mapaggr.checkinterval = 100000
set hive.groupby.skewindata = true
开启Map端聚合参数，生成的查询计划会有两个 MR Job。第一个 MR Job 中，Map 的输出结果会随机分布到 Reduce 中，每个 Reduce 做部分聚合操作，并输出结果，这样处理的结果是相同的 Group By Key 有可能被分发到不同的 Reduce 中，从而达到负载均衡的目的；第二个 MR Job 再根据预处理的数据结果按照 Group By Key 分布到 Reduce 中（这个过程可以保证相同的 Group By Key 被分布到同一个 Reduce 中），最后完成最终聚合操作。
MapTask 的数量由 切片数量决定，如果由于小文件过多使得切片数量过多，从而开启过多的 MapTask，分配及启动MapTask的时间都要远远大于 MapTask 执行时间，造成资源浪费。
解决方案：在 map 执行前合并小文件，减少 map 数：CombineHiveInputFormat 具有对小文件进行合并的功能（系统默认的格式）。HiveInputFormat(默认切片机制) 没有对小文件合并功能。
修改配置：
如果来源数据字段很少，数据量也在 blocksize 范围内，这样就导致数据量其实相当大，如果碰上 MapTask 的逻辑也相当复杂，就可能导致 MapTask 处理超时。
解决方案：增加 Map 数量 Math.max(minSize,Math.min(maxSize,blocksize))，调整 maxSize 最大值。让 maxSize 最大值低于 blocksize 就可以增加 map 的个数。
很多查询任务的性能短板在于 Reduce 数量太少，甚至一个 Reduce 计算所有的数据。不过，Reduce 数量也不是越多越好，首先，过多的启动和初始化 reduce 也会消耗时间和资源。另外，有多少个 reduce，就会有多少个输出文件，如果生成了很多个小文件，如果这些小文件作为下一个任务的输入，则也会出现小文件过多的问题。
在设置 reduce 个数的时候也需要考虑这
两个原则：
处理大数据量利用合适的 reduce 数。计算公式：
N=min(参数2，总输入数据量/参数1)单个 reduce 任务处理数据量大小要合适。
Hive 会将一个查询转化成一个或者多个阶段。这样的阶段可以是 MapReduce 阶段、抽样阶段、合并阶段、limit 阶段。默认情况下，Hive 一次只会执行一个阶段。但是，一个 Job 可能包含多个阶段，可能默写阶段并不依赖其他阶段，完全可以并行执行。可以设置打开任务并行执行(由Hive帮我们判断是否可以并行)，再设置最大并行度，并行操作开销较大，需要注意集群资源使用情况。
开启严格模式：
Hadoop的默认配置通常是使用派生JVM来执行map和Reduce任务的。这时JVM的启动过程可能会造成相当大 的开销，尤其是执行的job包含有成百上千task任务的情况。JVM重用可以使得JVM实例在同一个job中重新使用N次。 N的值可以在Hadoop的mapred-site.xml文件中进行配置，通常在10-20之间。
JVM重用的缺点是：开启JVM重用将一直占用使用到的task插槽，以便进行重用，直到任务完成后才能释放。 如果出现数据倾斜，保留的插槽就会一直空闲着却无法被其他的job使用，直到所有的task都结束了才会释放。
CombineHiveInputFormat 具有对小文件进行合并的功能。HiveInputFormat (Hive默认)没有对小文件合并功能。set hive.input.format = org.apache.hadoop.hive.ql.io.CombineHiveInputFormat;
在 Map-Reduce 的任务结束时合并小文件的设置：
# 在 map-only 任务结束时合并小文件，默认 true
SET hive.merge.mapfiles = true;
# 在 map-reduce 任务结束时合并小文件，默认 false
SET hive.merge.mapredfiles = true;
# 合并文件的大小，默认 256M
SET hive.merge.size.per.task = 268435456;
# 当输出文件的平均大小小于该值时，启动一个独立的 map-reduce 任务进行文件 merge
SET hive.merge.smallfiles.avgsize = 16777216;
skewjoin 运行时优化
开启参数 hive.optimize.skewjoin=true;(默认为false)，
并设置数据倾斜同key数据最小个数 hive.skewjoin.key。
skewjoin的原理是：
多个map并行处理，对非倾斜值采取普通join操作合并Union操作skewjoin 编译时优化
开启参数 hive.optimize.skewjoin.compiletime=true;(默认false)，
在编译sql时就已经将执行计划优化完毕，但要只有在表的元数据中存储的有数据倾斜信息时，才能生效。因此建议runtime 和compiletime都设置为true。
Union 优化
应用了表连接倾斜优化以后，会在执行计划中插入一个新的union操作，此时建议开启对union 的优化配置： hive.optimize.union.remove=true(默认false)。此项配置减少对Union all子查询中间结果的二次读写，可以避免union输出额外扫描过程， 当我们开启了skewjoin时尤其有用，建议同时开启。
Map阶段聚合
开启map端combiner(hive.map.aggr=true;默认为true)。此配置可以在group by语句中提高HiveQL聚合的执行性能。这个设置可以将顶层的聚合操作放在Map阶段执行，从而减轻数据传输和Reduce阶段的执行时间，提升总体性能。
负载均衡处理
倾斜数据的负载均衡处理(hive.groupby.skewindata=true默认false)，当数据出现倾斜时， 自动进行负载均衡。
第一个MR Job：Map 的输出结果集合会随机分布到Reduce中，每个Reduce做部分聚合操作，并输出结果，这样处理的结果是相同的Group By Key有可能被分发到不同的Reduce中，从而 达到负载均衡的目的；
第二个MR Job：再根据预处理的数据结果按照Group By Key分布到Reduce中（这个过程可以保证相同的Group By Key被分布到同一个Reduce中），最后完成最终的聚合操作，和小文件的处理方案一致详见[Hive小文件合并](#11. Hive小文件合并)
Hive 查询数据时，如果没有索引会加载整张表或分区，使用索引就能快速定位数据范围，查询速度提高。
但是 Hive 索引使用过程复杂，不支持自动更新，只能手动重建索引，重建索引还会触发一个 MR Job，并且性能一般，在Hive3.0中已被删除，不推荐使用。在分区数量过多或查询字段不是分区字段时，索引可以作为补充方案同时使用。推荐使用ORC 文件格式的索引类型进行查询。
一个ORC文件包含一个或多个stripes(groups of row data)，每个stripe中包含了每个 column的min/max值的索引数据，当查询中有<,>,=的操作时，会根据min/max值，跳过 扫描不包含的stripes。
而其中为每个stripe建立的包含min/max值的索引，就称为Row Group Index行组索引， 也叫min-max Index大小对比索引，或者Storage Index。
在建立ORC格式表时，指定表参数’orc.create.index’=’true’之后，便会建立Row Group Index，需要注意的是，为了使Row Group Index有效利用，向表中加载数据时，必须对需 要使用索引的字段进行排序，否则，min/max会失去意义。另外，这种索引主要用于数值型字段的查询过滤优化上。
设置 hive.optimize.index.filter为true，并重启hive
在建表时候，通过表参数”orc.bloom.filter.columns ” =”pcid”来指定为那些字段建立 BloomFilter索引，这样，在生成数据的时候，会在每个stripe中，为该字段建立BloomFilter 的数据结构，当查询条件中包含对该字段的=号过滤时候，先从BloomFilter中获取以下是 否包含该值，如果不包含，则跳过该stripe。
只有在数据量较大时，使用索引才能带来性能优势。
order by：会对输入做全局排序，因此只有一个reducer（多个reducer无法保证全局有序）。只有一reducer会导致当输入规模较大时，需要较长的计算时间。
sort by：不是全局排序，其在数据进入reducer前，为每一个reducer排序。
distribute by：按照指定的字段对数据进行划分输出到不同的reduce中，类似 MR 中 partition 自定义分区。
cluster by：除了具有 distribute by 的功能外还兼具 sort by 的功能，但是只能升序排序。
LOAD DATA LOCAL INPATH '/table/path/data.txt' OVERWRITE INTO TABLE test PARTITION(data='2022-01-01');
不是，从Hive0.10.0版本开始，对于简单的不需要聚合的类似 SELECT from
Fetch task获取数据。