Spark3写入Hive动态分区慢及任务总时长异常问题求助

原因分析 #

确实和Spark3新增的Hive事务及动态分区写入机制直接相关。Spark3默认启用了spark.sql.hive.useDynamicPartitionWriter=true，该机制会结合Hive的事务管理器对每个动态分区进行元数据锁控制、分区存在性校验及元数据同步。当每日动态分区数量极多时，这些串行的元数据操作会产生大量额外开销，直接导致写入耗时飙升。

你尝试的参数无效，可能是因为参数未全局生效，或是被作业代码中的局部配置覆盖，也可能遗漏了其他关联的事务相关配置。

解决措施 #

1. 彻底禁用新动态分区写入器与Hive事务
   在作业提交时通过--conf传入或在Spark全局配置文件中设置以下参数，确保全局生效：

   spark.sql.hive.useDynamicPartitionWriter=false
   spark.hadoop.hive.txn.manager=org.apache.hadoop.hive.sql.lockmgr.NoTxnManager
   spark.hadoop.hive.support.concurrency=false
   

2. 批量提交元数据减少阻塞
   设置批量提交元数据的条目数，降低单次元数据操作的压力：

   spark.sql.hive.metadataBatchSize=1000
   

   可根据实际分区数量调整该值，平衡元数据提交的效率与稳定性。

3. 绕过Spark的Hive写入逻辑
   若上述调整无效，可直接将数据写入HDFS对应分区路径，之后通过MSCK REPAIR TABLE语句同步Hive元数据。这种方式完全避开Spark3的事务与分区锁机制，适合分区数量极大的场景。

原因分析 #

单个Job执行更快符合Spark3在执行引擎、Shuffle优化等方面的性能提升，但总耗时增加通常来自Job之间的额外开销，而非Job内部执行环节。结合你的场景，核心耗时点可能包括：

• Spark3默认开启的Hive元数据自动刷新机制，每次Job前后都会触发元数据校验与同步，当表分区数量多或元数据量大时，会产生显著延迟。
• Spark3的作业调度与Catalog初始化逻辑更复杂，Driver端在加载表元数据、分区信息时的开销远高于Spark2。
• 日志代码调整本身影响极小，核心差异仍在元数据或调度层面。

排查与解决方法 #

1. 对比Spark UI的时间线
   查看Spark2和Spark3的UI中Job之间的间隔时间：如果Spark3的Job启动前存在较长的Metadata Retrieval或Partition Discovery阶段，即可确认元数据同步是主要耗时点。

2. 关闭元数据自动刷新
   添加以下参数禁用Spark3的自动元数据刷新逻辑：

   spark.sql.hive.metastorePartitionPruning=false
   spark.sql.refreshInterval=-1
   

3. 优化Driver端资源与调度
   提升Driver核心数以加快元数据处理速度，同时调整调度模式避免队列阻塞：

   spark.driver.cores=4
   spark.scheduler.mode=FIFO
   

   具体资源值可根据集群实际情况调整。

4. 直接统计元数据操作耗时
   在作业代码中添加日志，记录获取表元数据、分区信息的耗时，直接定位Spark2与Spark3在元数据操作上的差异。

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