我（第一次）试图重新划分团队正在使用的数据，以提高我们的查询性能。我们的数据当前存储在使用gzip压缩的分区.parquet文件中。我一直在读，使用snappy会大大提高吞吐量（我们每天都会查询此数据以进行分析）。我仍然想对这两个编解码器进行基准测试，以亲眼看到性能差距。我编写了一个简单的（Py）Spark 2.1.1应用程序来进行一些测试。我将5000万条记录持久保存在单个分区的内存中（反序列化），使用不同的编解码器将它们写入单个拼花文件（至HDFS），然后再次导入文件以评估差异。我的问题是我在读取和写入方面都看不到任何显着差异。
这是我将记录写入HDFS的方式（与gzip文件相同，只需将“ snappy”替换为“ gzip”）：
persisted_records.write\
.option('compression', 'snappy')\
.mode("overwrite")\
.partitionBy(*partition_cols)\
.parquet('path_to_dir/test_file_snappy')
这是我读取单个.parquet文件的方式（与gzip文件相同，只需将'snappy'替换为'gzip'）：
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中的持续时间。作为参考，持久化（反序列化）的5000万行的行数为317.4M。一旦写入单个实木复合地板文件，使用gzip和snappy的文件重量分别为60.5M和105.1M（这是可以预期的，因为gzip应该具有更好的压缩率）。 Spark花费1.7分钟（gzip）和1.5分钟（snappy）来写入文件（单个分区，因此单个内核必须完成所有工作）。在单个内核上的读取时间总计为2.7min（gzip）和2.9min（snappy）（因为我们只有一个文件/ HDFS块）。这是我不明白的：snappy的更高性能在哪里？
我做错了什么吗？我的“基准测试协议”有缺陷吗？是性能提升在这里，但是我没有查看正确的指标吗？
我必须补充一点，我正在使用Spark默认配置。除了指定执行程序的数量等外，我没有做任何其他更改。
非常感谢您的帮助！
注意：Spark镶木地板版本为1.8.1