0

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

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

4

2 回答 2

2

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 的粉丝。

于 2018-11-29T20:32:11.747 回答
2

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

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

  • 使用 .gz 压缩的文件无法拆分：您必须从头到尾阅读，因此一次最多分配一个文件（除了在查询结束时，推测可能会触发一秒钟）。使用像 snappy 这样的压缩，一切都很好
  • 非常小的文件效率低下，因为启动/提交开销占主导地位
  • 在 HDFS 上，小文件会将负载放在名称节点上，因此运维团队可能会不高兴
于 2018-11-30T11:21:33.607 回答