我（第一次）试图重新分配我的团队正在使用的数据，以增强我们的查询性能 . 我们的数据目前存储在使用gzip压缩的分区.parquet文件中 . 我一直在阅读使用snappy而不是显着提高吞吐量（我们每天查询这些数据以供分析） . 我仍然希望对两个编解码器进行基准测试，以便亲眼看到性能差距 . 我写了一个简单的（Py）Spark 2.1.1应用程序来进行一些测试 . 我在一个分区中将50万条记录保存在内存中（反序列化），使用不同的编解码器将它们写入单个镶木地板文件（到HDFS），然后再次导入文件以评估差异 . 我的问题是我看不到读写的任何显着差异 .
以下是我将记录写入HDFS的方法（gzip文件同样如此，只需用'gzip'替换'snappy'）：
persisted_records.write\
.option('compression', 'snappy')\
.mode("overwrite")\
.partitionBy(*partition_cols)\
.parquet('path_to_dir/test_file_snappy')
这是我如何阅读我的单个.parquet文件（对于gzip文件来说同样的事情，只需用'gzip'替换'snappy'）：
df_read_snappy = spark.read\
.option('basePath', 'path_to_dir/test_file_snappy')\
.option('compression', 'snappy')\
.parquet('path_to_dir/test_file_snappy')\
.cache()
df_read_snappy.count()
我查看了Spark UI中的持续时间 . 有关信息，持久化（反序列化）50百万行的数量为317.4M . 一旦写入单个镶木地板文件，文件分别使用gzip和snappy加权60.5M和105.1M（这应该是gzip应该具有更好的压缩率） . Spark花费1.7分钟（gzip）和1.5分钟（snappy）来编写文件（单个分区，因此单个核心必须执行所有工作） . 读取时间在单个核心上达到2.7分钟（gzip）和2.9分钟（snappy）（因为我们有一个文件/ HDFS块） . 这就是我不明白的地方：snappy的性能更高？
我做错了什么吗？我的“基准协议”有缺陷吗？这是性能提升，但我没有看到正确的指标？
我必须补充说我正在使用Spark默认conf . 除了指定执行者的数量等之外，我没有改变任何东西 .
非常感谢您的帮助！
注意：Spark镶木地板 jar 的版本是1.8.1