Azure HDInsight集群创建与Spark提交调优：250GB gzip文件处理咨询

现有配置核心问题 #

250GB gzip压缩JSON文件解压后体积通常为原体积的4_{8倍，即总数据量可达1}2TB，当前配置存在明显资源浪费和参数错配：

• 6节点总可用vCPU为48核、总内存384GB，但仅配置7个Executor，单Executor仅分配7核10GB内存，超过60%的集群资源处于闲置状态
• 单Executor核内存比过低，JSON解析场景内存消耗高，极易出现OOM报错
• Driver内存分配不足，无法支撑海量分区的元数据管理和shuffle聚合操作

集群选型方案 #

优先选择内存优化型节点，两种适配方案可按需选择：

• 方案1：保留现有6节点E8a v4集群，无需额外更换硬件，仅调整Spark参数即可完成处理
• 方案2：更换为4节点E16a v4集群，单节点16vCPU、128GB RAM，总资源更高、成本与现有6节点E8a v4差异不大，处理效率可提升1倍以上

对应Spark提交配置 #

提示：gzip为不可拆分压缩格式，若可提前将250GB大文件拆分为多个128MB以内的小gzip文件，整体处理效率可提升300%以上

6节点E8a v4集群适配参数 #

spark-submit 提交命令参考：

spark-submit \
--class <你的业务主类全限定名> \
--master yarn \
--deploy-mode cluster \
--driver-memory 20G \
--driver-cores 5 \
--executor-memory 18G \
--executor-cores 5 \
--num-executors 8 \
--conf spark.yarn.executor.memoryOverhead=4G \
--conf spark.driver.memoryOverhead=5G \
--conf spark.sql.shuffle.partitions=80 \
--conf spark.files.maxPartitionBytes=134217728 \
<你的业务jar包路径>

配置逻辑：每个节点跑1~2个Executor，预留足够系统和YARN资源 overhead，单Executor核内存比合理，避免JSON解析时的内存争抢，shuffle分区数为总Executor核数的2倍，降低数据倾斜风险。

4节点E16a v4集群最优参数 #

spark-submit 提交命令参考：

spark-submit \
--class <你的业务主类全限定名> \
--master yarn \
--deploy-mode cluster \
--driver-memory 32G \
--driver-cores 8 \
--executor-memory 30G \
--executor-cores 7 \
--num-executors 8 \
--conf spark.yarn.executor.memoryOverhead=6G \
--conf spark.driver.memoryOverhead=8G \
--conf spark.sql.shuffle.partitions=112 \
--conf spark.files.maxPartitionBytes=134217728 \
<你的业务jar包路径>

配置逻辑：总可用计算核心达64，可用内存达288GB，250GB gzip文件处理时长可控制在40分钟以内，单Executor内存足够支撑解压后的大分区数据处理，无内存溢出风险。

内容的提问来源于stack exchange，提问作者Geek Logbook