零件文件的大小对 Spark SQL 性能有影响吗答案

【问题标题】：Does size of part files play a role for Spark SQL performance零件文件的大小对 Spark SQL 性能有影响吗
【发布时间】：2018-11-29 19:59:36
【问题描述】：

我正在尝试查询具有大量零件文件 (avro) 的 hdfs。最近我们进行了更改以降低并行度，因此零件文件的大小增加了，每个零件文件的大小在 750MB 到 2 GB 的范围内（我们使用 spark 流以 10 分钟的间隔将日期写入 hdfs，所以这些文件的大小取决于我们从上游处理的数据量）。部分文件的数量大约为 500。我想知道这些部分文件的大小/部分文件的数量是否会对 spark SQL 性能产生任何影响？

如果需要，我可以提供更多信息。

【问题讨论】：

文件越大越好 - 一般来说。什么小于 2GB？
每个部分文件的大小在 750 MB 到 2 GB 之间，所以我提到部分文件的大小不会超过 2 GB。
但那是一个模糊的陈述。
为问题添加了更多信息。
可能是接受或赞成答案的想法。

标签： apache-spark apache-spark-sql query-performance spark-avro

【解决方案1】：

HDFS、Map Reduce 和 SPARK 更喜欢大小较大的文件，而不是许多小文件。 S3 也有问题。我不确定您是指 HDFS 还是 S3。

将较小的文件重新分区为较少数量的较大文件 - 无需深入了解所有细节 - 允许 SPARK 或 MR 处理较少但较大的数据块，从而通过减少映射任务的数量来提高作业速度需要读取它们，并且由于更少的浪费和名称节点争用问题而降低了存储成本。

总而言之，小文件问题值得阅读。例如。 https://www.infoworld.com/article/3004460/application-development/5-things-we-hate-about-spark.html。需要明确的是，我是 Spark 的粉丝。

【讨论】：

【解决方案2】：

一般来说，文件越少越好，

一个问题是文件是否可以拆分，以及如何拆分。

使用 .gz 压缩的文件无法拆分：您必须从头到尾阅读，因此一次最多分配一个工作人员（除非在查询和推测接近尾声时会触发第二个）。使用像 snappy 这样的压缩，一切都很好
非常小的文件效率低下，因为启动/提交开销占主导地位
在 HDFS 上，小文件会将负载放在 namenode 上，因此运维团队可能不高兴

【讨论】：