在 Spark 中处理压缩文件：重新分区可以提高还是降低性能

Posted 2023-03-06

【中文标题】在 Spark 中处理压缩文件：重新分区可以提高还是降低性能

【英文标题】：Handling compressed files in spark: Can repartition improve or detoriate performance

【发布时间】：2020-09-01 12:40:33

【问题描述】：

我正在使用“start_pyspark_shell”命令启动我的 spark shell，并将 cli 选项提供为 - 4 个执行程序，每个执行程序 2 个内核和 4GB 内存用于工作节点和 4GB 用于主节点

存储：HDFS

输入文件：大小为 221.3 MB 的压缩 .csv.gz 文件（HDFS 上为 2 个块）& Spart 版本：2.4.0

手头的任务是计算文件中的记录数的简单任务。唯一的问题是它是一个压缩文件。 我使用

加载了文件

df = spark.read.format("com.databricks.spark.csv").load(hdfs_path)

当我执行df.count() 时，我看到有一个执行程序任务并且可能是预期的（？），因为我正在处理一个不可拆分的压缩文件，并且将使用单个分区对其进行操作？

我检查了分区的数量 - df.rdd.getNumPartitions()，它返回了 1，可能与预期的一样。

同一命令多次运行的处理时间约为 15-17 秒。

我想我们可以在这里得出结论，上述处理没有太多的并行性？

我现在尝试执行df.repartition(10).count()，期望数据将重新分区到 10 个新分区中，并且可能跨工作节点。我可以看到 TASKS 的数量现在取决于我指定的分区数量。我希望在执行时间方面有一些改进的性能。结果现在是 25-26 秒。

当我使用.repartition(20)时，它运行了4多分钟，我不得不杀死它。

性能降低。我是不是做错了什么，或者我错过了提高性能的任何步骤？

注意：我确实看到了一些很好的现有帖子，但仍然不清楚。因此发布了一个新查询。

【问题讨论】：

您能否在 spark UI 中检查所有任务是否正在运行或只有一个正在运行，而其他的只是处于 dead_state 状态。请验证一次任务状态。

同时检查 spark UI 中的 spark 事件时间线 以了解您的工作并检查哪些阶段需要更多时间。

【参考方案1】：

压缩文件似乎被加载到单个执行器上的单个分区中。当我们尝试重新分区时，我们会在不同的工作节点上并行运行更多任务，但是，重新分区也需要额外的时间来将数据混洗/复制到多个工作节点。

这似乎是处理时间较长的原因。

结论： a) 如果任务/动作很简单，则不值得对压缩文件的数据进行重新分区。 b) 如果我们有很多处理线，重新分区的成本只有一次，但多个处理活动可能会受益，并且值得额外的处理时间。