Hive小文件问题

Hive小文件问题

问题零，先搞明白Hive的架构设计和工作流程

hive是基于Hadoop的一个数据仓库工具，用来进行数据提取、转化、加载，这是一种可以存储、查询和分析存储在Hadoop中的大规模数据的机制。hive数据仓库工具能将结构化的数据文件映射为一张数据库表，并提供SQL查询功能，能将SQL语句转变成MapReduce任务来执行

架构设计

Hive的架构包括三个部分：Hive客户端，Hive服务端，Hive元数据存储数据库和hadoop集群

1，Hive客户端：

它为不同类型的应用程序提供不同的驱动，使得Hive可以通过类似Java、Python等语言连接，同时也提供了JDBC和ODBC驱动。

2，Hive服务端

• 用户接口组件（CLI，HiveServer，HWI），它们分别以命令行、与web的形式连接Hive。
• Driver组件，该组件包含编译器、优化器和执行引擎，它的作用是将hiveSQL语句进行解析、编译优化、生成执行计划，然后调用底层MR计算框架。
• Metastore组件，元数据服务组件。Hive数据分为两个部分，一部分真实数据保存在HDFS中，另一部分是真实数据的元数据，一般保存在MySQL中，元数据保存了真实数据的很多信息，是对真实数据的描述。

3， Hive Storage and Computing ，

包括元数据存储数据库和Hadoop集群。Hive元数据存储在RDBMS（ Relational Database Management System 关系数据库管理系统 ）中，Hive数据存储在HDFS中，查询由MR完成。

工作流程

1，执行查询。例如命令行或者Web UI等发送查询驱动程序来执行。

2，获取计划。在驱动程序帮助下查询编译器，分析查询检查语法和查询计划或查询的具体要求。

3，获取元数据。编译器发送元数据请求到数据库。

4，数据库发送回元数据。

5，编译器检查要求，并重新发送计划给驱动程序。到此为止，查询解析和编译完成。

6，驱动程序发送执行计划到执行引擎。

7，在内部，执行作业是一个MR。执行引擎也可以通过metastore执行元数据操作。

8，执行引擎接受来自数据节点的结果。

9，执行引擎发送这些结果值给驱动程序。

10，驱动程序将结果发给Hive接口。

问题一，Hive的动态分区是什么，怎么设置？

关系型数据库中，对分区表Insert数据时候，数据库自动会根据分区字段的值，将数据插入到相应的分区中，Hive中也提供了类似的机制，即动态分区(Dynamic Partition)。

1），开启动态分区（默认为true）

set hive.exec.dynamic.partition=true;

2），设置为非严格模式（默认为strict，表示必须指定至少一个分区为静态分区；nonstrict表示允许所有的分区字段都可以使用动态分区）

set hive.exec.dynamic.partition.mode=nonstrict;

3），在所有执行MR的节点上，最多一共可以创建多少个动态分区（默认1000）

set hive.exec.max.dynamic.partitions=1000;

4），在每个执行MR的节点上，最多可以创建多少个动态分区（该参数需要根据实际的数据来设定。比如：源数据中包含了一年的数据，day字段有365个值，那么该参数就需要设置成大于365；若使用默认的100，则会报错）

set hive.exec.max.dynamic.partitions.pernode=100;

5），整个MR Job中，最多可以创建多少个HDFS文件（默认100000）

set hive.exec.max.created.files=100000;

6），当有空分区生成时，是否抛出异常（默认false）

set hive.error.on.empty.partition=false;

问题二，Hive小文件产生的原因？

一，读取的数据源有大量的小文件。

二，使用动态分区插入数据，会产生大量小文件，从而导致map数量剧增；

比如：在一段sql语句中我需要指定两个字段当做动态分区，一个字段的有8个值，另一个有4个值，这就是32个分区。我们的sql语句的最后一个job是一个仅有map阶段的任务，数据量大，假如有4000个map，这种情况下map任务在往hive分区中写的时候，每个map几乎都要产生32个文件，这样就会产生4000*32个文件，带来大量的小文件。

三，Reduce/Task数量较多，最终落地的文件数量和reduce/Task数量一样

一般情况下reduce的数目不会太大，并且reduce数目比较好控制。

问题三，Hive小文件带来的影响？

带来的问题是显而易见的。

首先，小文件越多，需要开启的Mapper/Task就越多；每个Mapper/Task都会启动一个对应的 JVM/线程来运行；这会导致大量资源被占用；由于数据量小，这些任务的初始化时间甚至会超过执行时间严重影响性能。

其次，会导致HDFS上存储了大量数据的元数据信息（位置，大小，分块信息等）；这其中还包括磁盘中的fsimage（冷备安全性保障）和内存中的editslog（热备用于快速响应请求）。会占用存储资源。

问题四，如何解决Hive小文件问题？

1，对于map过多的问题，可以采用CombineFileInput和开启JVM重用来解决。

CombineFileInputFormat作用：将多个小文件打包成一个InputSplit提供给一个Map处理，避免因为大量小文件问题，启动大量任务

CombineFileInputFormat是一种新的inputformat，用于将多个文件合并成一个单独的split，另外，它会考虑数据的存储位置。

JVM重用可以使得JVM实例在同一个job中重新使用N次。N的值可以在Hadoop的mapred-site.xml文件中进行配置。通常在10-20之间，具体多少需要根据具体业务场景测试得出。

这个功能的缺点是，开启JVM重用将一直占用使用到的task插槽，以便进行重用，直到任务完成后才能释放。如果某个“不平衡的”job中有某几个reduce task执行的时间要比其他Reduce task消耗的时间多的多的话，那么保留的插槽就会一直空闲着却无法被其他的job使用，直到所有的task都结束了才会释放。

2，对于动态分区造成的问题，可以使用 Distribute by 将分区键相同的数据放进同一个reduce中；

但这也会引发一个问题，那就是每个分区下只有一个文件，文件数量太少会导致读取时Map/Task的数量也少，并发度上不去；

而且，数据分布不均匀，分区下的文件大小差异很大，这会造成部分reduce执行速度过慢，影响了整体的性能。

于是， 可以使用DISTRIBUTE BY rand()控制在map端如何拆分数据给reduce端的；hive会根据distribute by后面的列，对应reduce的个数进行分发，默认采用hash算法。

rand()方法会生成一个0~1之间的随机数，通过随机数进行数据的划分，即保证了每条数据分配到所有reduce的可能性是相等的，这样reduce处理的数据量就是均匀的；又可以在在数据量比较大的情况下使每个reduce产生的文件数为动态分区的个数，产生的文件总个数=m*分区个数。

-- 在 map only 的任务结束时合并小文件
set hive.merge.mapfiles = true;
-- 在 MapReduce 的任务结束时合并小文件
set hive.merge.mapredfiles = true;
-- 作业结束时合并文件的大小 
set hive.merge.size.per.task = 256000000;
-- 每个Map最大输入大小(这个值决定了合并后文件的数量) 
set mapred.max.split.size=256000000;   
-- 每个reducer的大小， 默认是1G，输入文件如果是10G，那么就会起10个reducer；
set hive.exec.reducers.bytes.per.reducer=1073741824;

set hive.input.format=org.apache.hadoop.hive.ql.io.CombineHiveInputFormat;

3，使用Har归档文件

此方法可以修改后用于每日定时脚本，对于已经产生小文件的hive表可以使用har归档。

set  hive.archive.enabled=  true ;

set  hive.archive.har.parentdir.settable=  true ;

set  har.partfile.size=256000000;