最佳文件大小和拼花块大小

Question

我每天有大约 100 GB 的数据使用 Spark 写入 S3。写入格式为镶木地板。编写此程序的应用程序运行 Spark 2.3

100 GB 数据进一步分区，其中最大分区为 30 GB。对于这种情况，我们只考虑 30 GB 的分区。

我们计划在 Spark 2.4 中迁移整个数据并重写到 S3。最初，我们在写入 S3 时没有决定文件大小和块大小。现在我们要重写所有内容，我们要考虑最佳文件大小和 parquet 块大小。

1. 在 parquet 中写入 S3 的最佳文件大小是多少？
2. 我们可以写入 1 个 30 GB 大小和 parquet 块大小为 512 MB 的文件吗？在这种情况下，阅读将如何发挥作用？
3. 与 #2 相同，但 parquet 块大小为 1 GB？

Answer 1

在谈论等式的 parquet 方面之前，需要考虑的一件事是在将数据保存到 parquet 后将如何使用它。 如果要经常读取/处理它，您可能需要考虑什么是访问模式并决定相应地对其进行分区。 一种常见的模式是按日期分区，因为我们的大多数查询都有时间范围。 对数据进行适当的分区将对写入后使用该数据的性能产生更大的影响。

现在，在 Parquet 上，经验法则是 parquet 块大小大致等于底层文件系统的大小。这在您使用 HDFS 时很重要，但在您使用 S3 时并不重要。

同样，Parquet 块大小的考虑因素是您读取数据的方式。 由于 Parquet 块基本上必须在内存中重构，因此它越大，下游需要的内存就越多。您还需要更少的工人，因此如果您的下游工人有足够的内存，您可以使用更大的拼花块，因为它会稍微更有效率。

但是，为了获得更好的可扩展性，拥有几个较小的对象（尤其是根据某些分区方案）通常比一个大对象更好，后者可能会成为性能瓶颈，具体取决于您的用例。

总结一下：

• 更大的 parquet 块大小意味着文件大小略小（因为压缩在大文件上效果更好），但在序列化/反序列化时内存占用更大
• 最佳文件大小取决于您的设置
• 如果您使用 512MB parquet 块大小存储 30GB，因为 Parquet 是一个可拆分的文件系统，并且 spark 依赖于 HDFS getSplits()，您的 spark 作业的第一步将有 60 个任务。他们将使用字节范围提取来并行获取同一 S3 对象的不同部分。但是，如果将其分解为几个较小的（最好是分区的）S3 对象，您将获得更好的性能，因为它们可以并行写入（必须按顺序写入一个大文件）并且在访问时也很可能具有更好的读取性能受到大量读者的欢迎。