在 S3 中存储时正确的 Parquet 文件大小？答案

【问题标题】：Correct Parquet file size when storing in S3?在 S3 中存储时正确的 Parquet 文件大小？
【发布时间】：2019-06-15 17:12:35
【问题描述】：

我一直在阅读有关此主题的几个问题以及几个论坛，在所有这些问题中，他们似乎都提到从 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 存储和检索数据，我是否应该考虑这么多的大小？

另外，如果我打算使用 HDFS 来存储生成的 .parquet 文件，那么对于每天大约 10GB最大的数据集，哪个应该是最佳大小？

非常感谢任何其他优化提示！

【问题讨论】：

标签： apache-spark hdfs parquet

【解决方案1】：

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

较小的分割尺寸

更多工作人员可以同时处理一个文件。如果您有闲置的工作人员，则可以加快速度。
更多启动开销调度工作，启动处理，提交任务
从输出中创建更多文件，除非您重新分区。

小文件与大文件

小文件：

不管你是否想要，你都会得到那个小分裂。
即使您使用不可分割的压缩。
列出文件需要更长的时间。在 s3 上列出目录树非常慢
不可能要求比文件长度更大的块大小
如果您的 s3 客户端不以块为单位进行增量写入，则更易于保存。（如果你设置spark.hadoop.fs.s3a.fast.upload true，Hadoop 2.8+ 会这样做。

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

写作

保存为更大的文件。
活泼好动。
较浅+较宽的目录树覆盖较深和较窄的目录树

阅读

玩不同的块大小；至少 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

【讨论】：

感谢您，Steve - 您在此处对 Spark 的回答帮助我纠正或澄清了我在使用 Spark 的一年中学到的许多不成熟的概念。我已经浪费了好几个小时，因为我从来没有读过“在 S3 上列出目录树非常慢”......
谢谢。我确实在云连接器上全职工作，因此及时了解人们遇到的问题实际上是件好事。 StackOverflow 文章的压力比支持电话小
save to larger files via .repartion(). - 完全不同意。我会在这里遇到很多性能问题是为了什么？ Jsut保存更大的文件？我认为不应该通过repartion 调用保存到更大的文件。
Cherry：为什么不用您自己的数据集进行实验，看看您的数据和查询的输入数据的合适大小。然后，一旦您知道它应该以 MB 还是 GB 来衡量，请选择一个与之匹配的分区大小。你知道控制输出大小的其他方法吗？特别是考虑到我的反应是两年前？