在 Flume 向 HDFS 写入数据的过程中，小文件问题通常如何产生？从批处理大小、文件滚动条件以及数据压缩等角度，可以采取哪些具体的优化手段来减少小文件的数量？请结合 Flume 的相关配置参数说明。
考察说明
考查对 Flume Sink 写入 HDFS 时小文件问题成因的理解，以及通过配置参数进行优化的实际操作能力。
回答思路
- 【回答框架 1】小文件问题主要源于 Flume 频繁滚动文件，若 sink 批次较小或滚动条件过窄，会生成大量小文件，给 HDFS 带来元数据压力并影响后续计算效率。优化核心是增大单个文件的数据量并减少文件数目。
- 【回答框架 2】首先调节批处理大小，例如 hdfs.batchSize 参数控制每次批量写入事件数，增大该值可以让每次 flush 写入更多数据，从而减少文件创建频率。
- 【回答框架 3】其次调整文件滚动策略，相关参数包括 hdfs.rollInterval（按时间滚动，默认30秒）、hdfs.rollSize（按文件大小滚动，默认128MB）和 hdfs.rollCount（按事件数滚动，默认10）。生产环境建议适当增大 rollInterval 或依赖 rollSize 来控制文件大小，避免因过小的 rollCount 或过短的间隔产生大量小文件。
- 【回答框架 4】同时可以启用 HDFS Sink 的本地写入优化，如设置 hdfs.useLocalTimeStamp 等参数来调整路径；开启压缩（如设置 hdfs.codeC 为 SnappyCodec 或 GzipCodec）能减少存储占用，但需注意压缩对下游计算的影响。
- 【关键点 1】小文件产生的主要原因是 Flume 的滚动条件过于频繁或批量写入大小过小。
- 【关键点 2】增大 hdfs.batchSize 可增加单次写入的数据量，减少文件生成频率。
- 【关键点 3】合理配置 hdfs.rollInterval、hdfs.rollSize 和 hdfs.rollCount，优先依赖文件大小滚动。
- 【关键点 4】开启数据压缩（如 Snappy）可降低存储和IO开销，但需权衡压缩解压的CPU代价。
- 【易错点 1】单纯增大 hdfs.batchSize 可能增加内存压力，需结合 JVM 堆大小合理设置，避免 OOM。
- 【易错点 2】设置过大的 rollSize 可能导致单个文件过大，影响下游读取的并行度，需根据实际数据处理需求权衡。