如果我理解正确的话，当一个reduce任务开始收集它的输入shuffle块（来自不同map任务的输出）时，它首先将它们保存在内存中（Q1）。当执行器的 shuffles 保留内存量（在内存管理更改之前（Q2））耗尽时，内存中的数据将“溢出”到磁盘。如果spark.shuffle.spill.compress为true，那么内存中的数据将以压缩的方式写入磁盘。
我的问题：
Q0：我的理解正确吗？
Q1：reduce任务中收集的数据总是未压缩的吗？
问题 2：如何估计可用于收集 shuffle 块的执行器内存量？
问题 3：我见过这样的说法“当数据集无法容纳在内存中时，就会发生洗牌溢出”，但据我了解，只要洗牌保留的执行程序内存足够大，可以包含其所有（未压缩的）洗牌输入块ACTIVE 任务，则不应发生溢出，对吗？
如果是这样，为了避免溢出，需要确保最终在所有并行归约端任务中的（未压缩的）数据小于执行器的随机保留内存部分？
1.6前后内存管理存在差异。在这两种情况下，都有执行内存和存储内存的概念。不同的是，1.6之前它是静态的。这意味着有一个配置参数指定有多少内存用于执行和存储。当其中任何一个都不够时，就会发生泄漏。
Apache Spark 必须解决的问题之一是并发执行：
我想说你的理解是正确的。
内存中的内容未压缩，否则无法处理。执行内存以块的形式溢出到磁盘，并且正如您提到的可以压缩。
好吧，从1.3.1开始你可以配置它，然后你就知道大小了。至于在任何时刻剩下的内容，您可以通过查看执行程序进程来看到，例如jstat -gcutil <pid> <period>。它可能会告诉您有多少可用内存。了解配置了多少内存用于存储和执行，尽可能少default.parallelism尽可能给你一个线索。
确实如此，但很难推理；数据中可能存在偏差，例如某些键比其他键具有更多值，存在许多并行执行等。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
