合并spark structured streaming处理流式数据产生的小文件

备注：

By 远方时光原创，可转载，open

合作微信公众号 ：大数据左右手

背景：做流批一体，湖仓一体的大数据架构，常见的做法就是

数据源->spark Streaming->ODS（数据湖）->spark streaming->DWD（数据湖）->...

那么数据源->spark Streaming->ODS，以这段为例，在数据源通过spark structured streaming写入ODS在数据湖（Delta Lake)落盘时候必然会产生很多小文件

目的：

为了在批处理spark-sql运行更快，也避免因为小文件而导致报错

影响：

WARNING: Failed to connect to /172.16.xx.xx:9866 for block, add to deadNodes and continue. java.net.SocketException: Too many open files
 

1.小文件在批处理数据IO消耗巨大，程序可能卡死

2.小文件块都有对应的元数据，元数据放在NameNode，导致需要的内存大大增大，增加NameNode压力，这样会限制了集群的扩展。

3.在HDFS或者对象储存中，小文件的读写处理速度要远远小于大文件，（寻址耗时）

解决思路：

事前：

1.避免写入时候产生过多小文件

• 做好分区partitionBy(年，月，日), 避免小文件过于分散
• Trigger触发时间可以设置为1分钟，这样会攒一批一写入，避免秒级别写入而产生大量小文件（但是使用spark structured 想要做real-time不能这样，只适合做准实时）

2.打开自适应框架的开关

spark.sql.adaptive.enabled true

3.通过spark的coalesce()方法和repartition()方法

val rdd2 = rdd1.coalesce(8, true) //（true表示是否shuffle）
val rdd3 = rdd1.repartition(8)

coalesce：coalesce()方法的作用是返回指定一个新的指定分区的Rdd，如果是生成一个窄依赖的结果，那么可以不发生shuffle，分区的数量发生激烈的变化，计算节点不足，不设置true可能会出错。
repartition：coalesce()方法shuffle为true的情况。

事后（已经产生很多小文件）：

1：优化 Delta 表的写入，避免小文件产生

在开源版 Spark 中，每个 executor 向 partition 中写入数据时，都会创建一个表文件进行写入，最终会导致一个 partition 中产生很多的小文件。

Databricks 对 Delta 表的写入过程进行了优化，对每个 partition，使用一个专门的 executor 合并其他 executor 对该 partition 的写入，从而避免了小文件的产生。

该特性由表属性 delta.autoOptimize.optimizeWrite 来控制：

可以在创建表时指定

CREATE TABLE student (id INT, name STRING)
TBLPROPERTIES (delta.autoOptimize.optimizeWrite = true);

也可以修改表属性

ALTER TABLE table_name
SET TBLPROPERTIES (delta.autoOptimize.optimizeWrite = true);

该特性有两个优点：通过减少被写入的表文件数量，提高写数据的吞吐量；避免小文件的产生，提升查询性能。

其缺点也是显而易见的，由于使用了一个 executor 来合并表文件的写入，从而降低了表文件写入的并行度，此外，多引入的一层 executor 需要对写入的数据进行 shuffle，带来额外的开销。因此，在使用该特性时，需要对场景进行评估：

该特性适用的场景：频繁使用 MERGE，UPDATE，DELETE，INSERT INTO，CREATE TABLE AS SELECT 等 SQL 语句的场景；

该特性不适用的场景：写入 TB 级以上数据。

2.自动合并小文件

在流处理场景中，比如流式数据入湖场景下，需要持续的将到达的数据插入到 Delta 表中，每次插入都会创建一个新的表文件用于存储新到达的数据，假设每10s触发一次，那么这样的流处理作业一天产生的表文件数量将达到8640个，且由于流处理作业通常是 long-running 的，运行该流处理作业100天将产生上百万个表文件。这样的 Delta 表，仅元数据的维护就是一个很大的挑战，查询性能更是急剧恶化。

为了解决上述问题，Databricks 提供了小文件自动合并功能，在每次向 Delta 表中写入数据之后，会检查 Delta 表中的表文件数量，如果 Delta 表中的小文件（size < 128MB 的视为小文件）数量达到阈值，则会执行一次小文件合并，将 Delta 表中的小文件合并为一个新的大文件。

该特性由表属性 delta.autoOptimize.autoCompact 控制，和特性 delta.autoOptimize.optimizeWrite 相同，可以在创建表时指定，也可以对已创建的表进行修改。自动合并的阈值由 spark.databricks.delta.autoCompact.minNumFiles 控制，默认为50，即小文件数量达到50会执行表文件合并；合并后产生的文件最大为128MB，如果需要调整合并后的目标文件大小，可以通过调整配置 spark.databricks.delta.autoCompact.maxFileSize 实现。

3：手动合并小文件（我常用，每天定时运行合并分区内小文件，再去处理批任务）

自动小文件合并会在对 Delta 表进行写入，且写入后表中小文件达到阈值时被触发。除了自动合并之外，Databricks 还提供了 Optimize 命令使用户可以手动合并小文件，优化表结构，使得表文件的结构更加紧凑。在实现上 Optimize 使用 bin-packing 算法，该算法不但会合并表中的小文件，且合并后生成的表文件也更均衡（表文件大小相近）。例如，我们要对 Delta 表 student 的表文件进行优化，仅需执行如下命令即可实现：（Optimize 命令不但支持全表小文件的合并，还支持特定的分区的表文件的合并）

OPTIMIZE student WHERE date >= '2024-01-01'

一般批处理是day+1（每天凌晨运行前一天的数据），我在运行批处理前，运行一下optimize，合并昨天产生的小文件

附加：

面试官可能会问，我运行optimize合并小文件，但是小文件太多了，直接卡死运行不了程序（某互联网面试题，背景是：一次合并一个月，甚至一年产生的小文件）

回答：

1.首先停掉程序，这里注意deltalake因为有历史版本这个概念，所以不存在运行一半覆盖原来版本情况，可以基于上一个版本重新运行（考点）

2.第二点，大数据思想分而治之，“分”，即把复杂的任务分解为若干个“简单的任务”来处理。

​OPTIMIZE student WHERE date > '2024-01-01' and date < '2024-01-02'

因为前面做了partitionby(年月日)，那么缩小optimize范围，在遍历这个月的每一天日期，分治处理

3.第三点，大数据思想，自己不行找兄弟，加节点，加计算资源