Flink持续输入数据到hive会产生很多小文件以及处理方案总结

无论是使用 Flink 还是 Spark Streaming，如果配置不当，直接将流数据写入 Hive，几乎必然会产生大量小文件。

小文件问题是 Hadoop 生态系统的“天敌”，会带来许多负面影响：

1. NameNode 压力过大： HDFS 中每个文件都会在 NameNode 的内存中占用约 150 字节的元数据。大量小文件会快速消耗 NameNode 的内存，影响集群稳定性。
2. 查询性能下降： Hive/Spark 等查询引擎在读取数据时，每个小文件通常都会启动一个 Map Task。大量小文件意味着需要启动海量的 Map Task，导致任务调度时间远大于数据处理时间，查询变得极慢。
3. 存储效率低： 小文件可能无法有效利用 HDFS 的数据块（如 128MB 或 256MB），导致磁盘空间浪费。

---

Flink 为什么会产生小文件？

Flink 的 Hive Streaming Sink 为了提供精确一次（Exactly-Once） 的语义保证，必须依赖 checkpoint 机制。

1. Checkpoint 与文件提交： Flink 以固定的 checkpoint 间隔（例如 5 分钟）来对齐所有算子的状态。对于 Hive Sink，这意味着只有在成功完成一次 checkpoint 后，该 checkpoint 周期内写入的临时文件才会被提交（commit） 为可见的正式文件。
2. 文件生成频率： 因此，最终产生的文件数量与 checkpoint 的次数直接相关。如果你的 checkpoint 间隔是 5 分钟，那么理论上每小时就会产生 12 个文件。如果数据量不大，每个文件都可能远小于 HDFS 的块大小，从而成为小文件。