单个记录查找的火花性能

Question

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

在互联网上研究了这个话题之后，我找不到一个令人满意的答案，我想给SO社区举个例子，看看这是一个与我们的环境或数据相关的一次性案例，还是一个更大的与火花相关的模式。

火花1.6.1火花控制:执行器2，可执行内存32G，执行器核心4。

数据位于内部Hive表中，该表存储为用zlib压缩的ORC文件类型。压缩文件的总大小为2.2GB。

这是查询代码。

#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诉Dataframes等，但我真的想了解Spark是如何与ORC文件交互的，这导致了这一差距。

请让我知道，如果我可以提供更多的澄清，围绕上述任何谈话要点。

Answer 1

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

一般来说，Hive占用整个Hadoop集群的内存，这个内存比可执行内存大得多(在这里，2* 32 = 64 GB)。节点的内存大小是多少？

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

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

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

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

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

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