Spark 为什么有时候不适合做大规模机器学习

在 Spark 中,计算被建模为一种有向无环图(DAG),图中的每个顶点表示一个 RDD,每条边表示了 RDD 上的一个操作。RDD 由一系列被切分的对象(Partition)组成,这些被切分的对象在内存中存储并完成计算,也会在 Shuffle 过程中落到磁盘上。

在 DAG 中,一条从顶点 A 到 B 的有向边 E,表示了 RDD B 是在 RDD A 上执行操作 E 的结果。操作分为转换(Transformation)和动作(Action)两类。转换操作(例如 map、filter 和 join)应用于某个 RDD 上,转换操作的输出是一个新的 RDD。

Spark 用户将计算建模为 DAG,该 DAG 表示了在 RDD 上执行的转换和动作。DAG 进而被编译为多个 Stage。每个 Stage 执行为一系列并行运行的任务(Task),每个分区(Partition)对应于一个任务。这里,窄依赖将有利于计算的高效执行,而宽依赖则会引入瓶颈,因为这样的依赖关系引入了通信密集的 Shuffle 操作,这打断了操作流。

Spark 的分布式执行是通过将 DAG Stage 划分到不同的计算节点实现的。驱动器(Driver)包含有两个调度器(Scheduler)组件,即 DAG 调度器和任务调度器。调度器对工作者分配任务,并协调工作者。

Spark 是为通用数据处理而设计的,并非专用于机器学习任务。要在 Spark 上运行机器学习任务,可以使用 MLlib for Spark。如果采用基本设置的 Spark,那么模型参数存储在驱动器节点上,在每次迭代后通过工作者和驱动器间的通信更新参数。如果是大规模部署机器学习任务,那么驱动器可能无法存储所有的模型参数,这时就需要使用 RDD 去容纳所有的参数。这将引入大量的额外开销,因为为了容纳更新的模型参数,需要在每次迭代中创建新的 RDD。更新模型会涉及在机器和磁盘间的数据 Shuffle,进而限制了 Spark 的扩展性。这正是基本数据流模型(即 DAG)的短板所在。Spark 并不能很好地支持机器学习中的迭代运算。

Spark 的核心概念是 RDD,而 RDD 的关键特性之一是其不可变性,来规避分布式环境下复杂的各种并行问题。这个抽象,在数据分析的领域是没有问题的,它能最大化的解决分布式问题,简化各种算子的复杂度,并提供高性能的分布式数据处理运算能力。

然而在机器学习领域,RDD的弱点很快也暴露了。机器学习的核心是迭代和参数更新。RDD凭借着逻辑上不落地的内存计算特性,可以很好的解决迭代的问题,然而 RDD 的不可变性,却非常不适合参数反复多次更新的需求。这本质上的不匹配性,导致了 Spark 的 MLlib 库,发展一直非常缓慢,从 2015 年开始就没有实质性的创新,性能也不好。

参考资料