Hive教程（09）- 彻底解决小文件的问题

文章目录

• • 
    
• ​​01 引言​​
• ​​02 小文件概述​​

• • 
    
• ​​2.1 小文件的缘由​​
• ​​2.1 小文件的危害​​
  • 
    

• • 
    
• ​​3.1 方式一：处理已有的小文件​​

• • 
    
• ​​3.1.1 distribute by 命令​​
• ​​3.1.2 concatenate 命令​​
• ​​3.1.3 定时方案​​

• • 
    
• ​​3.1.3.1 Linux crontab 控制​​
• ​​3.1.3.2 Java代码控制（推荐）​​
  • 
    

• 
  

• ​​3.2 方式二：预防小文件​​
• ​​3.3 方式三：使用HAR归档文件​​
  • 
    

• ​​04 文末​​
  • 
    

01 引言

在前面的教程，已经初步入门​​hive​​了，有兴趣的同学可以参阅：

• • 
    
• ​​《Hive教程（01）- 初识Hive》​​
• ​​《Hive教程（02）- Hive安装》​​
• ​​《Hive教程（03）- Hive数据模型》​​
• ​​《Hive教程（04）- Hive数据类型》​​
• ​​《Hive教程（05）- Hive命令汇总》​​
• ​​《Hive教程（06）- Hive SerDe序列化与反序列化》​​
• ​​《Hive教程（07）- Hive自定义用户名密码验证(已开源）》​​
• ​​《Hive教程（08）- JDBC操作Hive》​​
  • 
    

本文主要讲解在​​Hive​​下如何解决小文件的问题。

02 小文件概述

2.1 小文件的缘由

我们都知道​​HDFS​​的场景适合一次写入，多次读出的场景，也就是为了“​读​”，“​写​”的时候慢点也是可以的。

就偏偏在再“​读​”的时候，我们发现随着时间的推移，​​hdfs​​的文件会越来越多，特别是​​hdfs​​做​增量插入​的时候，每次增量可能就几条数据，但是这几条数据占用一个文件，如下图：

2.1 小文件的危害

这个缺点会引发很大的问题，先贴上一张​​hdfs​​的架构图：

因为​​Namenode​​负责​​hdfs​​文件系统索引目录和文件结构进行管理的，假如存在大量的小文件，会造成如下问题:

• • 
    
• ​增加​​Namenode​​的存储和计算压力​：因为​​Namenode​​​不像​​Datanode​​那样多个节点共同工作（datanode有多个副本）;
• ​占用​​Namenode​​内存资源​：当​​Client​​​读取或者写入大量小文件则有可能给​​Namenode​​​造成很大压力，如果​​Namenode​​内存使用完了，这个集群将不能再存储文件了，最终影响整个集群稳定性。
  • 
    

可以知道，随着小文件的增加，客户需要从​​Namenode​​​获取元信息，再从​​Datanode​​读取对应数据的时间也会变长。

03 小文件解决方案

解决小文件的问题，首选方案就是 “​hive合并小文件​”。

可以根据如下思路去解决：

• • 
    
• ​方式一​：对​已有的数据​进行定时或实时的小文件合并
• ​方式二​：在生成小文件前，进行相关的配置合并来预防
• ​方式三​：使用​​HAR​​归档文件
  • 
    

3.1 方式一：处理已有的小文件

3.1.1 distribute by 命令

处理已有的小文件可以实时或定时操作，定时操作可在访问低峰期操作，如凌晨2点。

使用​​hive​​操作命令：

insert overwrite table 目标表 [partition(hour=...)] select * from 目标表 
distribute by cast( rand() * 具体最后落地生成多少个文件数 as int);

这里描述一下以上的几个关键字：

• • 
    
• ​​​insert overwrite​​​：会重写数据，先进行删除后插入（不用担心如果​​overwrite​​失败，数据没了，这里面是有事务保障的）;
• ​​​distribute by​​​：它的作用是控制在​​map​​​端如何拆分数据给​​reduce​​​端的，​​distribute by​​后面列是控制落地文件数，默认是采用hash算法;
• ​​​ran()​​函数​：控制最终生成多少个文件。
  • 
    

举例：控制​​dt​​​分区目录下生成100个文件，且文件大小基本一致，那么​​hsql​​如下：

insert overwrite table test partition(dt)
select * 
from test
distribute by cast(rand()*100 as int);

3.1.2 concatenate 命令

如果是​​orc​​格式存储的表，还可以使用如下命令进行小文件的合并：

alter table test [partition(...)] concatenate

​注意​：这种方法仅仅适用于orc格式存储的表。

3.1.3 定时方案

定时方案执行​​distribute by​​ 命令的方案有两种：

• • 
    
• ​​Linux crontab​​ 控制
• ​​Java​​代码控制
  • 
    

3.1.3.1 Linux crontab 控制

​​cron​​命令如下（每晚凌晨0点执行）：

0 0 * * * $home/bin/command.sh

主要的疑难点在于执行脚本（​​command.sh​​）的编写。

因为连接​​hive​​​需要用到了​​hive​​​安装包里面自带的​​beeline​​​，需要输入账号密码，等待连接成功后才能进行相关的​​HSQL​​​操作，而且如果要合并所有分区的小文件，需要遍历所有的表的所有分区，然后依次执行合并小文件的​​hsql​​，过程不易控制且账号密码等信息暴露了。

3.1.3.2 Java代码控制（推荐）

如果使用​​java​​​代码控制，可控粒度比较细，可以通过​​jdbc​​的方式去控制。

它的缺点是需要在主工程里引入​​hive-jdbc​​​的依赖，增加包的体积，如果是分布式的环境，配置的​​hive​​​连接地址可能不同，用户的访问权限可能需要设置（如​​hadoop​​​里面的​​core-site.xml​​文件）。

3.2 方式二：预防小文件

有些公司用的版本不同，低版本可能有些配置不一样，最好检查一下上面这些配置是否设置，然后根据自己的实际集群情况进行设置

通过调节​​hive​​​参数的方式预防，配置与注释如下（在​​hive-site.xml​​配置也可以）：

## 每个Map最大输入大小(这个值决定了合并后文件的数量)
set mapred.max.split.size=256000000;  

## 一个节点上split的至少的大小(这个值决定了多个DataNode上的文件是否需要合并)
set mapred.min.split.size.per.node=100000000;

## 一个交换机下split的至少的大小(这个值决定了多个交换机上的文件是否需要合并)  
set mapred.min.split.size.per.rack=100000000;

## 执行Map前进行小文件合并
set hive.input.format=org.apache.hadoop.hive.ql.io.CombineHiveInputFormat; 

## 设置map端输出进行合并，默认为true
set hive.merge.mapfiles = true

## 设置reduce端输出进行合并，默认为false
set hive.merge.mapredfiles = true

## 设置合并文件的大小
set hive.merge.size.per.task = 256*1000*1000

## 当输出文件的平均大小小于该值时，启动一个独立的MapReduce任务进行文件merge。
set hive.merge.smallfiles.avgsize=16000000

3.3 方式三：使用HAR归档文件

运用于每日定时脚本，对于已经产生小文件的​​hive​​​表可以使用​​har​​​归档，而且​​hive​​提供了原生支持：

set  hive.archive.enabled=  true ;
set  hive.archive.har.parentdir.settable=  true ;
set  har.partfile.size=256000000;

ALTER TABLE  ad_dev.wlb_tmp_smallfile_20210118 ARCHIVE PARTITION(pt='2022-03-01');

04 文末

本文主要讲解在​​Hive​​下解决小文件的方案，谢谢大家的阅读，本文完！