心灵爆炸: RDD.zip()方法

Question

我只是发现 RDD.zip()方法，我无法想象的 http://en.wikipedia.org/wiki/Design_by_contract可能是什么。

当然，我明白它的作用。然而，据我所知，

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

换句话说，RDD是一个(多个)集合，而不是序列(当然，在Python获得AttributeError: 'set' object has no attribute 'zip'时也是如此)

我上面的理解有什么问题？

这种方法背后的理由是什么？

它在像a.map(f).zip(a)这样的琐碎上下文之外是合法的吗？

编辑1：

• 另一个疯狂的方法是zipWithIndex()，以及各种zipPartitions()变体。
• 请注意，first()和take()并不疯狂，因为它们只是RDD的(非随机)样本。
• collect()也很好--它只是将一个set转换成一个完全合法的sequence。

编辑2：回复说：

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

这似乎意味着，即使是微不足道的a.map(f).zip(a)也是，而不是保证与a.map(x => (f(x),x))等价的。当zip()结果可复制时，情况如何？

Answer 1

RDDs总是无序的说法是不正确的。例如，如果RDD是sortBy操作的结果，它就有一个有保证的订单。RDD不是一个集合；它可以包含重复项。分区对调用方不是不透明的，可以控制和查询。许多操作都保留分区和顺序，比如map。尽管如此，我发现无意中违背zip所依赖的假设有点容易，因为它们有点微妙，但它肯定有其目的。

Answer 2

我使用的心智模型(并推荐)是，RDD 的元素是有序的，但是当您从另一个RDD中计算一个RDD时，新RDD中元素的顺序可能与旧RDD中的元素顺序不相对应。

对于那些想知道分区的人，我想说：

1. RDD的分区有一个顺序。
2. 分区中的元素有顺序。
3. 如果考虑使用分区内元素的顺序“连接”分区(例如，将分区按“端到端”排列)，则如果忽略分区，则最终得到的总体顺序对应于元素的顺序。

但是，如果您从另一个RDD中计算一个RDD，那么关于这两个RDD的顺序关系的所有赌注都会取消。

RDD类的几个成员(我指的是Scala )强烈建议使用订单概念(以及他们的文档)

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

Partition.index、SparkContext.parallelize()和SparkContext.makeRDD() (两者都采用Seq[T])也是如此。

在我的经验中，这些“观察”顺序的方式给出了彼此一致的结果，在RDDs和ordered集合之间来回转换的结果就像您所期望的那样--它们维护元素的总体顺序。这就是为什么我说，在实践中，RDD有一个有意义的订单概念。

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

但是，这就引出了您关于“合同”的问题，而文档在这方面确实有一个问题。我从未见过一个地方清楚地说明了操作对元素顺序的影响。( OrderedRDDFunctions类不计算，因为它引用基于数据的排序，这可能与RDD中元素的原始顺序不同。同样，RangePartitioner类也是如此。)我可以看到，这可能导致您得出这样的结论:元素顺序不存在概念，但我上面给出的示例使该模型令我感到不满意。