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的每日数据，这些数据将被拆分并每年保存到每日存储桶中。 4或48后面的原因只是出于测试目的，因为我知道测试集的大小，所以我会尽力获得接近64MB或1GB的数字。在获得需要事先保存的确切大小之前，我尚未实现用于缓冲所需数据的代码。

所以我的问题是...

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

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

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

Answer 1

您可以控制实木复合地板文件的拆分大小，前提是您使用可分割的压缩文件（如snappy）保存它们。对于s3a连接器，只需将fs.s3a.block.size设置为不同的字节数。

较小的分割尺寸

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

小文件vs大文件

小文件：

无论您是否想要，都会得到很小的一笔钱。
即使您使用不可分割的压缩。
花更长的时间列出文件。在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

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

1 个答案: