有迹象表明 Spark 中的连接是使用/基于 cogroup 函数/原语/变换来实现的。因此，让我首先关注 cogroup - 它返回一个结果，该结果是 RDD，基本上由 cogrouped RDD 的所有元素组成。换句话说，对于每个同组 RDD 中的每个键，存在来自至少一个同组 RDD 的至少一个元素。
这意味着当较小时，而且流式传输例如JavaPairDstreamRDD 不断与更大的批处理 RDD 连接，这将导致为结果(共同分组)RDD 的多个实例分配 RAM，本质上是大批 RDD 以及更多... 显然，当 DStream RDD 被丢弃时，RAM 将会被返回，而且它们会定期这样做，但这似乎仍然是 RAM 消耗中不必要的峰值
我有两个问题:
有没有办法更“精确”地控制 cogroup 过程，例如告诉它只包含共同分组的 RDD 元素，其中每个给定键的共同分组 RDD 中至少有一个元素。根据当前的 cogroup API，这是不可能的
如果 cogroup 确实是一个大锤，其次连接是基于 cogroup 的，那么即使它们可以在最终用户可见的最终结果方面呈现出更漂亮的图片，但这是否意味着在幕后有仍然是同样严重的内存消耗
最佳答案
情况并没有那么糟糕。这很大程度上取决于分区的粒度。 Cogroup 将首先在磁盘中按键洗牌到不同的执行器节点。是的，对于每个键，对于两个 RDD，具有该键的所有元素的整个集合都将加载到 RAM 中并提供给您。但并非所有 key 在任何给定时间都需要位于 RAM 中，因此除非您的数据确实存在偏差，否则您不会因此受到太大影响。
关于apache-spark - Spark 中的加入和联合组，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/29657330/