背景

最近在做数仓宽表开发时，发现某些表的在hadoop（命令：hdfs dfs -ls）上小文件特别多，整体数据量不大，每个分区却有几百个小文件。而小文件太多带来的主要影响是：

1、占用过多的nameNode 资源，影响hadoop集群稳定性。一个小文件需要在nameNode中维护一份元数据（目录、大小、权限等信息） ，占用的资源是 150字节（Byte），100个小文件则占用 14.6KB。如果每天的数据都存在新的分区里，久而久之小文件会越来越多，所造成的内存压力也会越来越大。而NameNode很多情况下是单节点，且所有元数据加载在内存中，即使做了HA，所有的元数据也会存贮在一台机器上。

2、对计算性能产生影响。spark在进行计算时，每个分区都会启动一个task进行并行计算，而一个小文件算是一个分区。并行计算可以提高工作效率，但是却会占用更多的计算资源。每个小文件启动一个task，效率上肯定是不划算的。

因此必须找到问题原因，并加以解决。

产生原因

通过对这几个表进行观察，发现通用的现象是 在sql中大量使用了union all。由于union 需要去重，效率比较低，因此基于hadoop系大数据组件进行开发时，推荐使用union all。举个简单例子：

with 
tmp as (
    select * from aa
    union all
    select * from bb
    union all
    select * from cc
)

insert overwrite table result_table
partition(dt = '2023-01-01') 
select * from tmp;

aa、bb、cc 各有 100个分区，由于union all 是并行计算，并不会合并分区，那么 tmp就有300个分区了，result_table在 dt=‘2023-01-01’ 分区下面就会产生300个小文件。

而我们的实际期望是 在result_table的 dt=‘2023-01-01’ 分区下只有 1个文件。

解决办法

使用 COALESCE 或者 REPARTITION 来合并分区（减少小文件）。
sql 如下：

with 
tmp as (
    select * from aa
    union all
    select * from bb
    union all
    select * from cc
)

insert overwrite table result_table
partition(dt = '2023-01-01') 
select /*+ COALESCE(1) */ * from tmp;

或者

with 
tmp as (
    select * from aa
    union all
    select * from bb
    union all
    select * from cc
)

insert overwrite table result_table
partition(dt = '2023-01-01') 
select /*+ REPARTITION(1) */ * from tmp;

由于REPARTITION 是通过shuffle实现，因此在应对这种情况时 COALESCE 使用比较多。

sql 修改后，插入速度会有所下降，但是在接受范围内，而 dt = ‘2023-01-01’ 分区下 只有一个文件。