请求修复Impala大分区表的小文件问题（不影响目录结构）

嘿，针对你这个10TB大Impala表的小文件难题，我有几个实战过的靠谱方案，既能搞定小文件，又绝对不会动你的分区目录结构——毕竟这么大的表，改目录风险太高了：

方案1：优先用Impala原生的ALTER TABLE ... CONCATENATE（适合ORC/Parquet表） #

这个命令是Impala专门为列式存储表（ORC/Parquet）设计的小文件合并工具，只在单个分区内合并小文件，完全不碰分区目录结构，资源消耗也相对可控，非常适合你的大表场景。

操作步骤：

1. 先确保表的统计信息是最新的，让Impala能高效识别小文件：

COMPUTE STATS your_database.your_table;

2. 对整个表执行合并（如果分区太多怕超时，可以批量处理）：

ALTER TABLE your_database.your_table CONCATENATE;

3. 批量处理分区的脚本示例（避免一次性处理2k+分区导致集群压力过大）：

# 导出所有分区列表
impala-shell -q "SHOW PARTITIONS your_database.your_table;" | grep -v "partition" | split -l 50 - partitions_batch_

# 逐个批次处理分区
for batch_file in partitions_batch_*; do
  # 把分区列表转成逗号分隔的格式
  partitions=$(cat $batch_file | tr '\n' ',')
  # 去掉最后一个多余的逗号
  partitions_clean=${partitions%?}
  # 执行合并
  impala-shell -q "ALTER TABLE your_database.your_table PARTITION(${partitions_clean}) CONCATENATE;"
done

方案2：按分区INSERT OVERWRITE重写（兼容所有文件格式） #

如果你的表不是列式存储，或者CONCATENATE效果达不到预期，可以用按分区重写的方式——不开启shuffle，每个分区会生成少量大文件，同时完全保留原有目录结构。

操作要点：

1. 先设置Impala参数控制输出文件大小（比如每个文件128MB，可根据需求调整）：

SET impala.max_file_size=134217728; -- 128MB
SET hive.exec.dynamic.partition.mode=nonstrict;

2. 遍历每个分区执行重写，示例脚本逻辑：

-- 单个分区的执行语句示例
INSERT OVERWRITE TABLE your_database.your_table PARTITION(partition_col='your_partition_value')
SELECT * FROM your_database.your_table PARTITION(partition_col='your_partition_value');

你可以写个Shell或Python脚本，自动遍历所有分区列表，逐个执行上述SQL，避免手动操作2k+分区。

方案3：HDFS合并+Impala元数据刷新（适合文本格式表） #

如果你的表是文本格式（比如CSV/TXT），可以直接用HDFS的合并工具先在分区目录内合并小文件，再刷新Impala元数据。

操作步骤：

1. 遍历每个分区目录合并文件：

# 替换成你的表HDFS路径
table_path="/user/hive/warehouse/your_database.db/your_table/"

for part_dir in $(hdfs dfs -ls $table_path | grep -v "_SUCCESS" | awk '{print $8}'); do
  # 合并分区内所有小文件到一个文件
  hdfs dfs -getmerge $part_dir $part_dir/merged_data.txt
  # 删除原有小文件（注意不要删错合并后的文件）
  hdfs dfs -rm $part_dir/*.txt ! -name "merged_data.txt"
  # 重命名合并后的文件为原有格式的文件名（比如data.txt，根据你的表实际情况调整）
  hdfs dfs -mv $part_dir/merged_data.txt $part_dir/data.txt
done

2. 刷新Impala元数据，让表识别合并后的文件：

REFRESH your_database.your_table;

重要注意事项 #

• 所有操作一定要在业务低峰期执行，10TB的表操作会占用大量IO和计算资源，避免影响线上查询。
• 执行前先在测试环境拿小分区验证，确认目录结构没变化、查询正常后再推广到生产。
• 批量处理时控制并发数，别一次性给集群塞太多任务，导致资源耗尽。
• 优先推荐方案1，因为它对集群的资源消耗最小，执行速度也最快。

内容的提问来源于stack exchange，提问作者Ayu Shukla