背景介绍
随着业务量不绝扩大，平台逐步发展成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
通过日志分析的结果，我们发现任务提交节点的客户端配置配置了该参数的话，任务执行时间久的数目远大于那些没配置该参数的提交节点，对此我们进行了对比：
进一步分析下来，确定了题目逻辑，因为集群是联邦环境，业务表可能存在于任意一个联邦，如果配置了hive.exec.stagingdir参数，任务执行时暂时数据就会写入到一个指定的联邦下，这个时间，如果结果表的路径在其他联邦，那么业务逻辑完成后，就会存在跨联邦复制数据的动作；
而在跨 NameNode 执行 mv 操作时，会涉及到多个 NameNode 之间的元数据交互。源 NameNode 需要告知目标 NameNode 新文件的元数据信息，而且要确保两个 NameNode 之间的数据一致性。这个过程涉及到网络通信和同步操作，会增加额外的耽误，从而导致性能下降。
这就和我们在Linux上移动数据一样，同一个磁盘移动（类比成同联邦下）数据，只是元数据信息更改，不同磁盘移动数据（跨联邦）数据，数据会存在块写入，就会产生大量IO，分布式集群还涉及到网络等交互
解决方案
最终，我们决定删除全部提交节点的hive.exec.stagingdir配置项，这样，任务提交的时间久采用结果表的同联邦进行暂时数据的写入，避免了跨联邦的数据移动。
结语&思索
其实，对于平凡HDFS集群，配置hive.exec.stagingdir参数是很好的选择，主要有这么几个优点：
- 暂时文件写在一个固定目录，便于管理
- 任务失败时不会主动删除暂时文件，配置指定目录能够更方便的治理废弃数据
然而，对于大型的联邦集群，带宽资源是贵重的，我们应该只管减少跨联邦的数据交换，这个时间，保持本来的配置显然就不太合理了，让任务在执行时暂时数据写在本联邦下可能是更好的选择，固然这带来的题目就是更高的管理成本，以及定期的失败任务暂时目录治理需求
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 |
