背景介绍

随着业务量不断扩大，平台逐步发展成HDFS多联邦的架构，这个过程中，作为平台维护人员也会对参数进行不定期的优化以应对逐渐繁重的存算压力。

最近一个重点保障业务的计算任务无法满足客户的数据时延要求，客户很生气，然后也是各种投诉，然后项目上的同事就拉着一起查了下问题，最终定位到是一个客户端参数在大体量集群下造成的，记录一下

排查过程

在对日志进行分析的时候，主要发现了2个导致执行时间延长的点，分开进行说明：

任务慢的具体原因

在定位的时候，主要有2个地方会导致任务执行时间延长；

Executor中数据内存往磁盘溢写

任务执行过程中，可能会看到下面的这种日志，这样的日志一般是业务问题导致的，内存不够用，临时溢写磁盘，但是对于一个执行时间达到几个小时的任务来说，这个并不是主要的原因

结果数据写入分区路径

先看一个日志的关键截图，首先是9:31分：

然后是12:25分的日志

上图中可以看到在创建分区路径到数据完全写入完成度过了接近3个小时。

分析

因为可以基本定位到结果数据写入分区路径是主要影响任务时长的原因，所以对任务日志进行进一步排查，找找可能得原因；对比慢日志和快日志，有一个明显区别：

// 执行速度比较快的任务日志
2025-03-19 11:35:16,253 INFO org.apache.hadoop.hive.common.FileUtils: Creating directory if it doesn't exist: viewfs://nsX/ns3/path/.hive-staging_hive_2025-03-19_11-35-16_251_7169943507895305206-1
// 执行速度比较慢的任务日志
2025-03-19 07:35:37,022 INFO org.apache.hadoop.hive.common.FileUtils: Creating directory if it doesn't exist: viewfs://ns0/spark-tmp/stagedir/.hive-staging_hive_2025-03-19_07-35-37_020_688260183047175897-1

这个是在执行计算任务的时候指定的数据临时写入的目录路径，如果任务提交节点的客户端配置文件/etc/spark/conf/hive-site.xml中没有指定hive.exec.stagingdir参数，最终hive-staging就会写入到表对应的目录下（这是默认行为）如果客户端配置了这个参数，就会写入到参数指定的目录。

通过日志分析的结果，我们发现任务提交节点的客户端配置配置了该参数的话，任务执行时间久的数量远大于那些没配置该参数的提交节点，对此我们进行了对比：

进一步分析下来，确定了问题逻辑，因为集群是联邦环境，业务表可能存在于任意一个联邦，如果配置了hive.exec.stagingdir参数，任务执行时临时数据就会写入到一个指定的联邦下，这个时候，如果结果表的路径在其他联邦，那么业务逻辑完成后，就会存在跨联邦复制数据的动作；

而在跨 NameNode 执行 mv 操作时，会涉及到多个 NameNode 之间的元数据交互。源 NameNode 需要告知目标 NameNode 新文件的元数据信息，并且要确保两个 NameNode 之间的数据一致性。这个过程涉及到网络通信和同步操作，会增加额外的延迟，从而导致性能下降。

这就和我们在Linux上移动数据一样，同一个磁盘移动（类比成同联邦下）数据，只是元数据信息更改，不同磁盘移动数据（跨联邦）数据，数据会存在块写入，就会产生大量IO，分布式集群还涉及到网络等交互

解决方案

最终，我们决定删除所有提交节点的hive.exec.stagingdir配置项，这样，任务提交的时候久采用结果表的同联邦进行临时数据的写入，避免了跨联邦的数据移动。

结语&思考

其实，对于普通HDFS集群，配置hive.exec.stagingdir参数是很好的选择，主要有这么几个优点：

• 临时文件写在一个固定目录，便于管理
• 任务失败时不会主动删除临时文件，配置指定目录能够更方便的治理废弃数据

然而，对于大型的联邦集群，带宽资源是珍贵的，我们应该尽量减少跨联邦的数据交换，这个时候，保持原本的配置显然就不太合理了，让任务在执行时临时数据写在本联邦下可能是更好的选择，当然这带来的问题就是更高的管理成本，以及定期的失败任务临时目录治理需求