相同任务数下Spark多字段分区写入失败的原因与解决方法

按(day,city)分区写入时触发Driver序列化结果超限的核心原因是分区数量激增带来的Driver元数据处理压力暴增，具体细节如下：

• 分区目录数量爆炸：city作为分区字段，若城市基数大（比如几百上千个），会生成大量独立的分区目录。Spark写入分区表时，Driver需要收集每个任务的输出文件路径、分区信息、文件大小等元数据，这些元数据会被序列化后传递给Driver，分区越多，总元数据量呈指数级增长，远超只按day分区的情况。
• 元数据序列化开销放大：Delta Lake写入时还要生成事务日志，Driver需要协调所有任务的提交逻辑，额外的分区元数据会让序列化后的结果大小突破spark.driver.maxResultSize限制，即使调至10GB也无法覆盖极端场景（比如部分城市数据量极大，对应任务的元数据占比过高）。
• 任务输出分布不均：如果存在少数城市数据量远大于其他城市的情况，大量任务会集中输出到这些城市的分区目录，Driver需要处理的元数据会更集中，进一步加剧内存压力。

针对上述问题，可从分区策略、Spark配置、写入优化三个维度入手：

1. 调整分区/分桶策略 #

• 降低分区基数：将city合并为更大的地理单元（如省份、大区），减少分区目录数量；或者采用分区+分桶组合，比如按day分区，按city分桶（设置合理的分桶数，如100-200），既保留按city过滤的查询性能，又避免分区数量爆炸。
• 避免过度分区：确认业务是否真的需要按city分区，若多数查询不需要按city过滤，可放弃该分区字段，或改为在数据中保留city字段供查询过滤。

2. 优化Spark与Delta配置 #

• 调大Driver内存相关参数：将spark.driver.maxResultSize调至20GB以上（同时确保Driver节点内存足够，当前64GB内存支持该调整），并设置spark.driver.memory为合理值（比如40GB），给Driver预留足够的元数据处理空间。
• 启用自适应执行：开启spark.sql.adaptive.enabled=true，让Spark自动调整任务数量、分区大小，减少Driver需要处理的任务元数据总量。
• 启用Delta优化写入：设置delta.optimizeWrite=true，Delta会自动合并小文件、调整任务输出分布，降低Driver的元数据协调压力。
• 限制单文件记录数：设置spark.sql.files.maxRecordsPerFile=1000000（根据实际数据大小调整），避免单个任务生成过大的文件，减少单任务的元数据大小。

3. 优化数据处理流程 #

• 减少写入前的任务数：通过coalesce或repartition合理减少写入阶段的任务数量（比如从23K降至10K以内），但需注意避免数据倾斜，可结合repartitionByRange或自定义分区函数均匀分布数据。
• 处理数据倾斜：若存在个别city数据量极大的情况，单独拆分这些city的处理逻辑，比如将大city的数据拆分为多个子任务，避免单个任务输出过多元数据。

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