apache-spark - 在 S3 中存储时正确的 Parquet 文件大小？

Question

我一直在阅读关于这个主题的几个问题，还有几个论坛，在所有这些问题中，他们似乎都提到每个从 Spark 产生的 .parquet 文件应该是 64MB 或 1GB 大小，但仍然不能我的想法是哪些情况属于每个文件大小以及背后的原因，除了 HDFS 将它们拆分为 64MB 块之外。

我目前的测试场景如下。

dataset
  .coalesce(n) # being 'n' 4 or 48 - reasons explained below.
  .write
  .mode(SaveMode.Append)
  .partitionBy(CONSTANTS)
  .option("basepath", outputPath)
  .parquet(outputPath)

我目前正在处理总共 2.5GB 到 3GB 的每日数据，这些数据将被拆分并每年保存到每日存储桶中。 'n' 为 4 或 48 的原因仅用于测试目的 ，因为我事先知道我的测试集的大小，所以我尝试尽可能接近 64MB 或 1GB。我还没有实现代码来缓冲所需的数据，直到我获得保存之前所需的确切大小。

所以我的问题是......

如果我不打算使用 HDFS 而只是从 S3 存储和检索数据，我是否应该考虑这么多大小？

而且，这应该是 10GB 左右的日常数据集的最佳大小 最大 如果我打算使用 HDFS 来存储生成的 .parquet 文件？

任何其他优化技巧将不胜感激!

Answer 1

您可以控制 Parquet 文件的拆分大小，前提是您使用 snappy 等可拆分压缩文件保存它们。对于 s3a 连接器，只需设置 fs.s3a.block.size到不同的字节数。

较小的分割尺寸

更多的 worker 可以同时处理一个文件。如果您有空闲的 worker ，则加速。

更多启动开销调度工作、启动处理、提交任务

从输出创建更多文件，除非您重新分区。

小文件与大文件

小文件:

不管你是否愿意，你都会得到那个小的 split 。

即使您使用不可分割的压缩。

列出文件需要更长的时间。在 s3 上列出目录树非常慢

不可能要求比文件长度更大的块大小

如果您的 s3 客户端不以块为单位进行增量写入，则更容易保存。 (Hadoop 2.8+ 如果你设置 spark.hadoop.fs.s3a.fast.upload true 。

就个人而言，这是意见，以及一些基准驱动 - 但不是您的查询

写作

保存到更大的文件。

与活泼。

在深而窄的目录树上更浅+更宽

读

玩不同的块大小；将 32-64 MB 视为最小值

Hadoop 3.1，使用零重命名提交者。否则，切换到 v2

如果您的 FS 连接器支持此功能，请确保打开随机 IO (hadoop-2.8 + spark.hadoop.fs.s3a.experimental.fadvise random

通过 .repartion() 保存到更大的文件.

密切关注您收集了多少数据，因为存储大量旧数据很容易产生大额账单。

另见 Improving Spark Performance with S3/ADLS/WASB