apache-spark - 如何知道何时对不平衡分区的 RDD 进行重新分区/合并(可能不会进行混洗)？

Question

我正在从 s3 加载数以万计的 gzip 压缩文件用于我的 Spark 作业。这会导致一些分区非常小(10 条记录)，而一些分区非常大(10000 条记录)。分区的大小在节点之间分布得很好，因此每个执行器似乎都在处理相同数量的数据。所以我不确定我是否有问题。

我如何知道是否值得重新分区或合并 RDD？其中任何一个都能够在不打乱数据的情况下平衡分区吗？另外，该 RDD 不会被重用，只是映射并连接到另一个 RDD。

Answer 1

有趣的问题。 With respect to coalescing versus repartitioning ，合并肯定会更好，因为它不会触发完全洗牌。一般来说，当跨分区的数据稀疏时(例如，在过滤器之后)，建议使用合并。我认为这是一个类似的场景，但直接来自初始负载。然而，我真的认为合并对你来说可能是值得的，因为你在初始加载后对 RDD 做了什么。

当您将联接应用到加载的 RDD 时对数据进行混洗时，Spark 会咨询混洗管理器以查看应使用哪种混洗实现(通过 spark.shuffle.manager 配置)。随机播放管理器有两种实现:hash(版本<1.2.0 的默认值)和sort(默认>= 1.2.0)。

如果使用hash实现，每个输入分区将创建输出文件以发送到将发生连接的相应 reducer 。这可能会造成文件的巨大爆炸，可以通过将 Spark.shuffle.consolidateFiles 设置为 true 来缓解这种情况，但如果有大量分区作为输入，最终可能会导致连接速度相当慢。如果使用此实现，合并绝对是值得的，因为大量输入分区可能会产生大量需要减少的文件。

如果使用sort实现，每个分区只有一个输出文件(哇!)并且该文件被索引，以便reducer可以从各自的索引中获取它们的键。但是，对于许多输入分区，Spark 仍将从所有输入分区中读取以收集每个可能的键。如果使用此实现，合并可能仍然值得，因为对每个分区应用此查找和读取也可能成本高昂。

如果您最终使用了合并，则可能需要调整要合并的分区数量，因为合并将是执行计划中的一个步骤。但是，此步骤可能会为您节省一笔非常昂贵的连接费用。另外，作为旁注，this post对于解释洗牌背后的实现非常有帮助。