远程连接Hive metastore时Spark SQL查询执行缓慢问题咨询

我之前也碰到过一模一样的问题，当时折腾了好一阵才找到根源——明明是个简单的MAX聚合查询，本地连远程metastore跑起来居然要先拉全表，前两分钟完全没动静，和Edge Node上的执行速度差了十万八千里。下面是我总结的几个排查方向和解决办法，你可以挨个试试：

1. 检查本地客户端的执行模式 #

本地Spark/Hive客户端默认可能用了本地执行模式，这种模式下不会调用集群的计算资源，所有数据处理都在本地机器完成，自然会先把整张表拉下来。

• 对于Spark客户端：查看spark-defaults.conf里的spark.master参数，如果是local[*]或者local，赶紧改成集群对应的master地址（比如yarn或者spark://xxx:7077），让计算任务提交到集群执行。
• 对于Hive客户端：检查hive-site.xml中的hive.execution.engine，如果是mr且没配置集群提交，建议改成tez或者spark，同时确保集群资源能被本地客户端调用。

2. 确认本地对HDFS数据的直接访问权限 #

如果本地机器无法直接访问HDFS的数据节点，Spark/Hive只能通过metastore拿到表的元数据，但读取数据时只能中转甚至下载到本地，这也会导致拉全表的情况。

• 把集群的core-site.xml、hdfs-site.xml复制到本地客户端的配置目录，确保本地能直接解析HDFS的地址和数据节点信息。
• 检查本地机器的防火墙和网络策略，确认能访问HDFS数据节点的端口（默认是50010、50070等），如果有限制，需要开放对应端口。

3. 启用聚合下推的优化规则 #

有时候本地客户端的优化开关没开，导致优化器没有把MAX计算下推到数据源端，反而选择拉全表到本地再计算。

• Spark环境：先执行SET spark.sql.optimizer.excludedRules=;清空可能禁用的优化规则，然后用EXPLAIN select max(column) from table;查看执行计划，如果能看到PushDownAggregate步骤，说明下推生效了。
• Hive环境：在CLI里执行SET hive.optimize.aggregation=true; SET hive.optimize.pushdown=true;开启聚合优化和下推，再重新执行查询。

4. 核对本地与集群的版本兼容性 #

如果本地Spark/Hive的版本和集群版本差异过大，可能会出现执行计划生成异常、通信失败等问题，最终退化为本地处理。

• 尽量保证本地客户端版本和集群的Hive、Spark版本完全一致，比如集群用Spark 3.3.0，本地就不要用Spark 2.4.x，避免兼容性坑。

最后给个小技巧：先跑EXPLAIN select max(column) from table;看执行计划，要是计划里显示要扫描全表并拉到本地，那大概率是模式或者权限的问题；要是没有聚合下推的步骤，就去检查优化规则的配置。

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