4

我们在独立模式下运行 Spark，在 240GB“大”EC2 盒子上使用 3 个节点，以使用 s3a 将读取到 DataFrames 到 JavaRDD 的三个 CSV 文件合并到 S3 上的输出 CSV 部分文件中。

我们可以从 Spark UI 中看到，读取和合并以生成最终 JavaRDD 的第一阶段按预期在 100% CPU 上运行，但使用 CSV 文件写入的最后阶段saveAsTextFile at package.scala:179在 3 个节点中的 2 个节点上“卡住”了好几个小时32 个任务中有 2 个需要几个小时（整个时间段内，CPU 占用率为 6%，内存占用率为 86%，网络 IO 为 15kb/s，磁盘 IO 为 0）。

我们正在读取和写入未压缩的 CSV（我们发现未压缩的 CSV 比 gzip 压缩的 CSV 快得多），并在三个输入 DataFrame 中的每一个上重新分区 16 并且不关闭写入。

非常感谢我们可以调查的任何提示，为什么最后阶段需要这么多小时在我们独立本地集群中的 3 个节点中的 2 个节点上做的很少。

非常感谢

- - 更新 - -

我尝试写入本地磁盘而不是 s3a 并且症状是相同的 - 最后阶段的 32 个任务中有 2 个saveAsTextFile被“卡住”了几个小时：

在此处输入图像描述

4

2 回答 2

1

如果您通过 s3n、s3a 或其他方式写入 S3，请不要设置 spark.speculation = true，除非您要冒损坏输出的风险。我怀疑正在发生的事情是该过程的最后阶段是重命名输出文件，这在对象存储中涉及复制大量（许多 GB？）数据。重命名发生在服务器上，客户端只保持 HTTPS 连接打开，直到完成。我估计 S3A 重命名时间约为 6-8 兆字节/秒……这个数字会与您的结果相关吗？

写入本地 HDFS，然后上传输出。

  1. gzip 压缩无法拆分，因此 Spark 不会将处理文件的部分分配给不同的执行程序。一个文件：一个执行者。
  2. 尽量避免使用 CSV，这是一种丑陋的格式。拥抱：Avro、Parquet 或 ORC。Avro 非常适合其他应用程序流入，其他应用程序更适合其他查询中的下游处理。明显好转。
  3. 并考虑使用 lzo 或 snappy 等格式压缩文件，这两种格式都可以拆分。

另见幻灯片 21-22：http ://www.slideshare.net/steve_l/apache-spark-and-object-stores

于 2016-11-18T15:35:31.637 回答
0

我见过类似的行为。截至 2016 年 10 月，HEAD 中有一个可能相关的错误修复。但现在你可以启用

spark.speculation=true

在中SparkConf或中spark-defaults.conf。

让我们知道这是否可以缓解问题。

于 2016-11-18T05:53:40.250 回答