Spark性能上的个人记录查找

Question

我正在进行性能测试，比较Spark SQL和Hive on Tez对现有内部Hive表的查询。在整个测试过程中，Spark显示的查询执行时间与Tez上的Hive相当或更快。这些结果与许多例子是一致的。然而，有一个值得注意的例外是，在单个记录级别上涉及基于键的选择的查询。在这种情况下，Spark在Tez上明显比Hive慢。

在网上研究了这个话题后，我找不到一个满意的答案，我想把这个例子提交给SO社区，看看这是与我们的环境或数据相关的单个一次性案例，还是与Spark相关的更大的模式。

引发1.6.1Spark Conf: Executor 2, Executor Memory 32G, Executor Cores 4.

数据在一个内部Hive Table中，以ORC文件类型存储，使用zlib压缩。压缩文件的总大小为~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秒，而Hive在Tez上只需要6秒。我还尝试通过SQL上下文配置使用谓词下推，但这导致没有明显的性能提高。同样，当使用Parquet进行相同的测试时，查询时间也与Hive相同。我相信还有其他的解决方案可以提高查询的性能，比如使用RDDS和Dataframes等。但我真的很想了解Spark是如何与ORC文件交互的，这导致了这种差距。

请告诉我，如果我可以就上面列出的任何谈话要点提供额外的澄清。

Answer 1

以下步骤可能有助于提高Spark SQL查询的性能。

一般情况下，Hive占用整个Hadoop集群的内存，明显大于executer内存(这里2* 32 = 64gb)。节点的内存大小是多少?

此外，与hive查询生成的map/reduce作业的数量相比，executor的数量似乎更少(2)。以2的倍数增加执行程序的数量可能有助于提高性能。

在SparkSQL和Dataframe中，使用手动管理内存(Tungsten)的优化执行现在默认启用，以及代码生成用于表达式求值。如果spark.sql.tungsten.enabled尚未启用，则可以通过将其设置为true来启用此功能。

sqlContext.setConf("spark.sql.tungsten.enabled", "true")

ORC格式的列性质有助于避免读取不必要的列。但是，即使查询具有WHERE子句过滤器，我们仍然读取不必要的行。ORC谓词下推将通过其内置索引提高性能。这里，ORC谓词下推在Spark SQL中默认是禁用的，需要显式启用。

sqlContext.setConf("spark.sql.orc.filterPushdown", "true")

我建议你做更多的研究，找到潜在的性能障碍，如果有的话。