5

我一直在阅读有关该主题的几个问题以及几个论坛，在所有这些问题中，他们似乎都提到从 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 的每日数据集，哪个应该是最佳大小？

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

4

1 回答 1

12

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

更小的分割尺寸

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

小文件与大文件

小文件：

  • 无论你是否想要，你都会得到那个小分裂。
  • 即使您使用不可分割的压缩。
  • 列出文件需要更长的时间。在 s3 上列出目录树非常慢
  • 不可能要求比文件长度更大的块大小
  • 如果您的 s3 客户端不以块为单位进行增量写入，则更易于保存。（如果您设置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()。
  • 密切关注您收集了多少数据，因为存储大量旧数据很容易产生大笔费用。

另请参阅使用 S3/ADLS/WASB 提高 Spark 性能

于 2019-01-22T10:21:52.280 回答