Apache Spark RDD sortByKey算法和时间复杂度答案

【问题标题】：Apache Spark RDD sortByKey algorithm and time complexityApache Spark RDD sortByKey算法和时间复杂度
【发布时间】：2016-11-02 07:35:13
【问题描述】：

Apache Spark RDD sortByKey 的 Big-O 时间复杂度是多少？

我正在尝试根据特定顺序将行号分配给 RDD。

假设我有一个 {K,V} 对 RDD，我希望使用键执行订单

myRDD.sortByKey(true).zipWithIndex

这个操作的时间复杂度是多少，大 O 形式？

幕后发生了什么？冒泡排序？我希望不是！我的数据集非常大并且跨分区运行，所以我很好奇 sortByKey 函数是否是最佳的，或者在分区内执行某种中间数据结构，然后跨分区执行其他操作以优化消息传递，或者是什么。

【问题讨论】：

这里还有其他有用的 cmets：apache-spark-user-list.1001560.n3.nabble.com/…

标签： apache-spark time-complexity big-o rdd

【解决方案1】：

快速查看代码表明 RangePartitioner 正在幕后使用。文档说：

按范围将可排序的记录大致划分为 * 相等的范围。范围是通过对传入的RDD的内容进行采样来确定的

所以本质上你的数据被采样（O[n]），然后只有唯一的样本键（m）被排序（O[m log（m）]）并确定键的范围，然后是整个数据被打乱（O[n]，但代价高昂），然后在给定分区上接收到的键范围内对数据进行内部排序（O[p log[p]）。

zipWithIndex 可能使用本地大小来分配数字，使用分区号，因此很可能存储分区元数据用于此效果：

用它的元素索引压缩这个 RDD。排序首先基于分区索引 * 然后是每个分区中项目的排序。所以第一项中的第一项 * 分区获取索引0，最后一个分区中的最后一项获取最大索引。

【讨论】：

我不相信在这里用大 O 表示法说话是合理的。以这种方式描述时间复杂度的整个想法是我们可以定义具有恒定执行时间的基本操作。在分布式上下文中，我们不能再假设这样的事情了。
那么，Daniel，总时间复杂度大约是 O(NlogN) 吗？只是好奇 RangePartitioner 如何比较分区内排序的数据并有效地洗牌。更糟糕的是，它可能必须成对比较分区，所以我们可能有一个额外的因子 p 或 p^2 吗？
某种意义上不受数据局部性的影响。假设您要添加两个 n 位数字。简单的 O(N) 操作总是成功的。在分布式系统的情况下 a) 它可能成功也可能不成功 b) 操作的成本可能会根据数据的位置而变化多个数量级。从某种意义上说，它仍然是一个常数因素，但是... c) 非本地操作需要序列化、传输和反序列化 - 以上都没有考虑。
@zero323，您可能对分布式上下文删除假设是正确的，但我认为我们仍然可以用大 O 表示法计算“更坏情况”的时间复杂度。如果我有 N 行数据以反向或随机顺序分布在 P 个分区中，我们希望知道最大时间
我认为你们俩都是对的。我同意@zero323 的观点，即增加的负担和复杂性使事情变得不简单，特别是因为就处理时间而言，一些“常数”非常大（我特别提到了洗牌作为一个例子）。 O(N logN) 确实是我认为出于推理目的的上限，但您必须在分布式系统概念（数据局部性、磁盘和网络速度等）方面将推理提高到更详细的水平。