我正在进行性能测试，比较Spark SQL和Hive on Tez上现有内部Hive表的查询。在整个测试过程中，Spark显示的查询执行时间与Tez上的Hive相当或更快。这些结果与许多例子一致。但是，在一个查询中存在一个明显的例外，该查询涉及单个记录级别的基于密钥的选择。在这种情况下，Spark比Tez上的Hive慢得多。
在互联网上研究这个主题之后，我找不到一个满意的答案，并希望向SO社区提出这个例子，看看这是一个与我们的环境或数据相关的个别一次性案例，还是一个更大的模式与Spark有关。
Spark 1.6.1 Spark Conf：Executors 2，Executory Memory 32G，Executor Cores 4.
数据位于内部Hive表中，该表存储为使用zlib压缩的ORC文件类型。压缩文件的总大小约为2.2 GB。
这是查询代码。
#Python API
#orc with zlib key based select
dforczslt = sqlContext.sql("SELECT * FROM dev.perf_test_orc_zlib WHERE test_id= 12345678987654321")
dforczslt.show()
完成此查询的总时间超过400秒，而在Tez上使用Hive则为6秒。我也尝试通过SQL上下文配置使用谓词下推，但这导致没有明显的性能提升。此外，当使用Parquet进行相同的测试时，查询时间也与Hive相同。我确定还有其他解决方案来提高查询的性能，例如使用RDDS v。数据帧等。但我真的很想了解Spark如何与ORC文件交互，这导致了这一点。间隙。
如果我能就上面列出的任何谈话要点提供进一步说明，请告诉我。
答案 0 :(得分：2)
以下步骤可能有助于提高Spark SQL查询的性能。
通常，Hive占用整个Hadoop集群的内存，该集群比执行程序内存大得多（这里2 * 32 = 64 GB）。节点的内存大小是多少？。
此外，与hive查询生成的map / reduce作业的数量相比，执行者的数量似乎更少（2）。以2的倍数增加执行器的数量可能有助于提高性能。
在SparkSQL和Dataframe中，默认情况下启用使用手动管理内存（Tungsten）的优化执行以及代码生成 用于表达评估。如果尚未启用spark.sql.tungsten.enabled，则可以启用此功能。
sqlContext.setConf("spark.sql.orc.filterPushdown", "true")
ORC格式的柱状特性有助于避免读取不必要的列。但是，我们仍在读取不必要的行，即使查询具有WHERE子句filter.ORC谓词下推也会提高其内置索引的性能。这里，默认情况下在Spark SQL中禁用ORC谓词下推，需要明确启用。
@ngModule我建议你做更多的研究，找到潜在的性能阻滞剂，如果有的话。