查询需要很长时间“不选择”任何内容

Question

我有一个查询，我用了很长时间才找到。我在一个有500k行的表的单个分区上运行它。

查询如下所示：

select col0 from <table> where partition=<partition> and <col1>=<val>

我将其设置为col1！=val，因此查询返回0行。

此查询大约需要30秒（如果我使用选择*，则需要一分钟）。

当我运行完全相同的查询但使用select count（col0）时，需要2秒。

是什么原因导致查询在使用选择列时花费很长时间，而在使用选择计数（列）时不花费时间？

这是解释的问题

explain select col0 from table where `partition` = partition and col=val;

*项目[col0#607]
-*过滤器（isnotnull（col1#607）

explain select count(col0) from table where `partition` = partition and col=val;

*HashAggregate（键=[]，函数=[计数（col0#625）]）
-交换单分区
-*HashAggregate（键=[]，函数=[部分计数（col0#625）]）
-*项目[col0#625]
-*筛选器（isnotnull（col1#625）

据我所知，过程完全相同，只有count查询有更多步骤。那为什么要快15倍呢？

编辑：

我在日志中发现了一块有趣的金块：

带计数：

2008年6月18日11:42:55信息任务集管理器：在阶段2509.0中启动任务0.0（TID 8092，ip-123456，executor 36，partition 0，RACK\u LOCAL，5521字节）
2006年6月18日11:42:55信息任务集管理器：在阶段2509.0中启动任务1.0（TID 8093，ip-123456，executor 35，partition 1，RACK\u LOCAL，5521字节）
2006年6月18日11:42:55信息任务集管理器：在阶段2509.0中启动任务2.0（TID 8094，ip-123456，executor 36，partition 2，RACK\u LOCAL，5521字节）
18/06/28 11:42:55信息任务集管理器：启动阶段2509.0中的任务3.0（TID 8095，ip-123456，executor 35，partition 3，RACK\u LOCAL，5521字节）
18/06/28 11:42:55信息任务集管理器：启动阶段2509.0中的任务4.0（TID 8096，ip-123456，executor 36，partition 4，RACK\u LOCAL，5521字节）
18/06/28 28 11:42:55信息TaskSetManager：启动阶段2509.0中的任务5.0（TID 8097，ip-123456，executor 35，partition 5，RACK\u LOCAL，5521字节）
18/06/28 11:42:55信息TaskSetManager：启动阶段2509.0中的任务6.0（TID 8098，ip-123456，executor 36，partition 6，RACK\u LOCAL，5521字节）
18/06/28 11:42:55信息TaskSetManager：启动阶段2509.0中的任务7.0（TID 8099，ip-123456，executor 35，partition 7，RACK\u LOCAL，5521字节）
18/06/28 11:42:55信息任务集管理器：启动阶段2509.0中的任务8.0（TID 8100，ip-123456，executor 36，partition 8，RACK\u LOCAL，5521字节）
18/06/28 11:42:55信息任务集管理器：启动阶段2509.0中的任务9.0（TID 8101，ip-123456，executor 35，partition 9，RACK\u LOCAL，5521字节）

• 无：*

18/06/28 11:45:32INFO TaskSetManager：在阶段2512.0中启动任务0.0（TID 8136，ip-10-117-49-97.eu-west-1.compute.internal，执行器37，分区1，RACK_LOCAL，5532字节）
18/06/28 11:45:32INFO BlockManagerInfo：在ip-10-117-49-97.eu-west-1.compute.internal:40489的内存中添加了broadcast_2352_piece0（大小：12.6 KB，空闲：11.6 GB）
18/06/28 11:45:32INFO TaskSetManager：在阶段2512.0（TID 8136）中完成任务0.0，在ip-10-117-49-97.eu-west-1.compute.internal（执行器37）（1/1）667毫秒内完成
18/06/28 11:45:32INFO YarnScheduler：已删除任务集2512.0，其任务已全部完成，从池
18/06/28 11:45:32INFO DAGScheduler：ResultStage 2512（getNextRowSet at Action ationManager.java:220）在0.668秒内完成
18/06/28 11:45:32INFO DAGScheduler：作业2293完成：getNextRowSet at Action ationManager.java:220，花费0.671740秒
18/06/28 11:45:32INF
18/06/28 11:45:32INFO DAGScheduler：具有1个输出分区的作业2294（getNextRowSet at操作Manager.java:220）
18/06/28 11:45:32INFO DAGScheduler：最终阶段：ResultStage 2513（getNextRowSet at操作Manager.java:220）
18/06/28 11:45:32 INFO DAGScheduler：最终阶段的父级：List（）
18/06/28 11:45:32 INFO DAGScheduler：缺少父级：List（）
18/06/28 11:45:32 INFO DAGScheduler：提交ResultStage 2513（在AccessController.java： 0运行时的MapPartionsRDD[312]），没有缺少父级
18/06/28 11:45:32 INFO MemoryStore：块broadcast_2353存储在内存中的值（估计大小66.6 KB，可用12.1 GB）
18/06/28 11:45:32块broadcast_2353_piece0以字节形式存储在内存中（估计大小12.6 KB，空闲12.1 GB）
18/06/28 11:45:32 INFO BlockManagerInfo：在10.117.48.68:41493（大小：12.6 KB，空闲12.1 GB）上添加broadcast_2353_piece0内存中（大小：12.6 KB，空闲12.1 GB）
18/06/28 11:45:32 INFO SparkContext：从DAGS广播创建广播2353
18/06/28 11:45:32 INFO DAGScheduler：从ResultStage 2513提交1个丢失的任务（在AccessController.java： 0运行时MapPartionsRDD[312]）（前15个任务用于分区
Vector（2））18/06/28 11:45:32 INFO YarnScheduler：添加任务集2513.0和1个任务
18/06/28 11:45:32 INFO TaskSetManager：在阶段2513.0中启动（TID 8137，ip-10-117-49-97.eu-west-1.compute.internal，执行器37，分区2，RACK_LOCAL，5532字节）
18/06/28 11:45:33 INFO BlockManagerInfo：在ip-10-117-49-97.eu-west-1.compute.internal:40489（大小：12.6 KB，免费：11.6 GB）上添加broadcast_2353_piece0
18/06/28 11:45:38 INFO TaskSetManager：在阶段2513.0（TID 8137）中完成任务0.0在5238毫秒内ip-10-117-49-97.eu-west-1.compute.internal（执行器37）（1/1）
18/06/28 11:45:38 INFO YarnScheduler：已删除任务集2513.0，其任务已全部完成，从池
18/06/28 11:45:38 INFO DAGScheduler：ResultStage 2513（getNextRowSet at操作Manager.java:220）在5.238秒内完成
18/06/28 11:45:38 INFO DAGScheduler：作业2294完成：getNextRowSet at操作Manager.java:220，采取5.242084 s
18/06/28 11:45:38 INFO SparkContext：起始作业：getNextRowSet at操作Manager.java:220
18/06/28 11:45:38 INFO DAGScheduler：获得作业2295（getNextRowSet at操作Manager.java:220），具有1个输出分区
18/06/28 11:45:38 INFO DAGScheduler：最终阶段：ResultStage 2514（getNextRowSet at操作Manager.java:220）
18/06/28 11:45:38 INFO DAGScheduler：最终阶段的父级：List（）
18/06/28 11:45:38 INFO DAGScheduler：缺少父级：List（）
18/06/28 11:45:38 INFO DAGScheduler：在AccessController.java： 0运行时提交结果阶段2514（MapPartionsRDD[312]11:45:38 INFO MemoryStore：块broadcast_2354存储为内存中的值（估计大小66.6 KB，空闲12.1 GB）
18/06/28 11:45:38 INFO MemoryStore：块broadcast_2354_piece0存储为内存中的字节（估计大小12.6 KB，空闲12.1 GB）
18/06/28 11:45:38 INFO BlockManagerInfo：在10.117.48.68:41493的内存中添加了broadcast_2354_piece0（大小：12.6 KB，空闲：12.1 GB）
18/06/28 11:45:38 INFO SparkContext：从DAGS的广播中创建广播2354cheduler.scala:1047
18/06/28 11:45:38 INFO DAGScheduler：从ResultStage 2514提交1个丢失的任务（在AccessController.java： 0运行时Map分区RDD[312]）（前15个任务用于分区向量（3））

（即它重复这个块，看起来像是它按顺序运行任务，而不是像计数情况下那样并行运行）

我还尝试了“order by”，它实际上使查询运行速度提高了2倍

使用spark而不是thrift对相同的数据运行相同的查询要快得多。

我在aws emr-5.11.1上运行节俭

蜂巢2.3.2

Spark 2.2.1

节俭0.11.0

Answer 1

找到问题了我有一面旗子

spark.sql.thriftServer.incrementalCollect=true

在thriftserver中。它按顺序收集每个工人的输出，这就是造成这种巨大开销的原因。删除标志修复了该问题。我想在执行“count”时，它被优化为不按顺序执行，因为它必然不会有很多数据。