Apache spark 头脑发热：RDD.zip（）方法

我只知道这个方法，我无法想象它可能是什么

我当然明白它的作用。然而，我一直认为

• RDD中元素的顺序是一个毫无意义的概念
• 分区的数量及其大小是一个实现细节，仅可供用户用于性能调整

换句话说，RDD是一个（多）集合，而不是一个序列（当然，在例如Python中，一个获取

AttributeError:“set”对象没有属性“zip”

）

我的上述理解有什么问题

这种方法背后的原理是什么

在像

a.map（f）.zip（a）

这样的琐碎上下文之外，它合法吗

编辑1：

• 另一个疯狂的方法是，以及各种变体
• 请注意，和并不疯狂，因为它们只是RDD的（非随机）样本
• 也可以-它只是将

  集合

  转换为

  序列

  ，这是完全合法的

编辑2:

当您从一个RDD计算另一个RDD时，新RDD中的元素顺序可能与旧RDD中的元素顺序不一致

这似乎意味着即使是微不足道的

a.map（f）.zip（a）

也不能保证等同于

a.map（x=>（f（x），x））

。当

zip（）

结果是可复制的时，会出现什么情况？

我使用（并推荐）的心智模型是，RDD的元素是有序的，但当你从一个RDD计算另一个RDD时，新RDD中元素的顺序可能与旧RDD中的顺序不一致

对于那些想要了解分区的人，我想说：

RDD的分区有一个顺序

分区中的元素具有顺序

如果您考虑使用分区内元素的顺序来“连接”分区（比如说将它们“端到端”地排列），那么如果您忽略分区，则最终得到的整体顺序与元素的顺序相对应

但同样，如果从一个RDD计算另一个RDD，那么关于这两个RDD的顺序关系的所有赌注都是无效的

RDD类的几个成员（我指的是Scala API）强烈建议使用订单概念（他们的文档也是如此）：

collect()
first()
partitions
take()
zipWithIndex()

Partition.index

以及

SparkContext.parallelize（）

和

SparkContext.makeRDD（）

（两者都采用

Seq[T]

）

根据我的经验，这些“观察”顺序的方法给出的结果彼此一致，而在RDD和有序Scala集合之间来回转换的方法的行为与您预期的一样——它们保留了元素的整体顺序。这就是为什么我说，在实践中，RDD有一个有意义的顺序概念

此外，虽然在很多情况下，从另一个RDD计算RDD必须改变顺序，但根据我的经验，在可能/合理的情况下，顺序往往会被保留。不重新分区且不从根本上改变元素集的操作尤其倾向于保持顺序

---

但这让我想到了你关于“合同”的问题，事实上，文件在这方面存在问题。我还没有看到任何一个地方明确说明操作对元素顺序的影响。（

OrderedRDDFunctions

类不起作用，因为它指的是基于数据的排序，这可能不同于RDD中元素的原始顺序。同样地，

RangePartitioner

类。）我可以看出这可能会导致您得出结论，元素顺序的概念是没有的，但是我上面给出的例子使这个模型不能让我满意

RDD并不总是无序的。例如，如果RDD是

sortBy

操作的结果，则它具有保证顺序。RDD不是一个集合；它可以包含重复项。分区对于调用方来说不是不透明的，并且可以控制和查询。许多操作都保留了分区和顺序，比如

map

。也就是说，我发现有点容易意外地违反

zip

所依赖的假设，因为它们有点微妙，但它肯定有目的。

我必须深入挖掘，但这似乎不是最安全的方法（）。所以，我不知道我会依赖它吗？虽然，在这种情况下，至少现在看来：，Spark的最初作者，可能很有启发性。RDD的第一句话元素是有序的，但顺序可能会改变，这意味着没有有意义的顺序，无论实际观察到什么顺序，都只是一个偶然的实现细节，在这种情况下，没有明确的契约，一切都可能被指责为意外的实现细节。然而，我想说的是，当您从另一个RDD计算时，不能保证新的RDD与旧的RDD具有相同的顺序。在实践中，任何单独的RDD都有一个稳定的顺序：观察顺序的不同方式会在瞬间和一段时间内产生一致的结果。对我来说，这很有意义，但我更希望有一份合同。编辑答案是因为@sds让我意识到我的推理不清楚。我根据你的编辑添加了EDIT2。谢谢你的精彩回复；对此“评论/编辑讨论”感到抱歉。没问题：这是一个有趣的讨论，可能值得加入Spark社区。我发现发送到Spark用户列表的问题回答率很低，但我正在考虑编写一个核心开发人员可能感兴趣的问题，并将其发布到开发人员列表中。这不是真的相关。如果你愿意的话，请随时告诉我。是否保证

a.map（f）.zip（a）

等同于

a.map（x=>（f(