Hive和Spark SQL优化_hive on spark reduce时间长-CSDN博客

本文链接：https://blog.csdn.net/strongyoung88/article/details/105940603

本文介绍了Hive和Spark SQL的优化方法，包括优化步骤、策略与具体实践。通过对任务耗时的分析，确定优化方向，如剪枝、提高并行度和Join优化。在Hive中，优化包括合理利用分区、分桶和谓词下推；在Spark中，可通过调整executor数量和利用broadcast hash join提高性能。此外，解决小文件问题和数据倾斜也是关键，可以通过配置参数和特定操作来改善。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

优化步骤

问题定位，通过日志和代码分析，定位任务耗时长的原因
- hive任务，对于hive任务，可以通过日志查看哪个application、以及是哪个阶段耗时较长，另外，可以通过stage编号，结合explain查看执行计划，可以得知耗时较长的application对应的是sql中的哪个操作，便于具体分析原因。如果是map阶段较长，很可能是并发不够，如果是reduce较长，且长时间留停在99%，则很可能发生了数据倾斜，如果是map和reduce的耗时都不长，但整个application的耗时却很长，则很有可能是大量小文件的读写造成的I/O耗时较长，当然，也不排除集群本身的一些因素，比如网络等问题。
- spark任务，对于spark任务，可以在spark UI页面上查看作业的dag图，每个stage耗费的时长，每个stage启有的executor数量，每个任务耗费的时长，最长任务耗时，最短任务耗时，以及任务的中位数耗时等等，通过这些信息，我们可以判断出当前作业耗时较长的原因。
对症下药
大多数情况，运行慢的原因很可能是并行度不够，或者数据处理发生了倾斜，找到任务耗时长的根源之后，根据不同的原因，作出相应的调优策略，例如，如果是并发不够，则适当提高并发，如果是数据发生倾斜，则考虑如何解决倾斜。