如何看UCBerkeley RISELab即将问世的Ray,replacement of Spark?

从新闻和博客介绍看,Ray不在采取MapReduce/BSP风格,而是采用data flow的风格协调异构任务之间数据交互,从技术上讲借鉴了MPI的一些思想;Ray主要面向一些自动驾驶、辅助医疗等基于ML/AI技术且需要Just-In-Time decision的应用场景。
关注者
618
被浏览
15,429
收录于 编辑推荐 ·

本人背景:分布式系统博士生,研究改进过MapReduce类系统,同时利用actor开发了工业界应用的新一代实时计算引擎(尚未开源)。因此对于Spark和Ray的设计初衷和可能遇到的技术债有一定了解。

先说个人的看法:Ray和Spark是立志于解决两个领域问题的计算机系统,Ray取代Spark是危言耸听了。

背景

回首分布式计算系统进化的10年,我们可以更容易认识到Spark和Ray的相对位置。

2004年,Google提出MapReduce作为一个集群编程框架,并且配合Google File System等技术作为底层存储的支持。之后10余年,MapReduce大行其道。其成功的原因在于其给广大程序员和数据科学家提供了一个非常好理解,表达力丰富,容错性极高,且很容易基于商业硬件(commodity devices)来实现的分布式系统架构。之后在2010年,随着Stanford提出的memory cloud的概念,研究人员意识到原本看似非常昂贵的内存正在变得廉价,许多高度依赖于磁盘的容错操作其实可以利用在内存中实现。在这个背景下,Spark应运而生,催生了RDD和一系列基于内存的优化技术,在中小型规模计算上取代了原本的Hadoop Hive等基于磁盘的框架。可是至今,Hive并没有因此而被完全取代。在超大规模计算(PB级别)场景下,其依赖于SSD以及超强的鲁棒性,依然是很多公司的首选。因此,计算框架出现的初衷往往不是相互取代的关系,而是支持新计算需求和场景,对于新的硬件条件进行利用,形成优势互补,相互合作的关系。ray和spark也是如此。


为什么我们需要新的计算框架?

2015年前后,大量AI计算任务崛起,其中增强学习(Reinforcement Learning)和自动驾驶AI训练等等作为一个重大的计算需求,一直很难在MapReduce得到很好的表达。MapReduce本质上是一个大规模的数据聚合(data aggregation)的模型。另一方面,许多AI的任务的核心诉求是在大规模仿真(Simulation)的环境下优化AI的行为。这种诉求和Spark当时的设计初衷完全不同。


首先,仿真的规模能够轻易轻易到达Billions的级别。这种级别难以在Spark集群得到良好支持。Spark的Task本质上对于基于CPU的操作系统线程抽象。因此Spark并没有非常自然的方式能够将数十亿个仿真实体(AlphaGo的仿真级别)能够合理的同时调度到几千个CPU上面。

另外,MapReduce范式难以表达复杂的计算状态和同步。上亿个仿真实体不仅仅运行的时间不同(有些游戏只要几秒就结束,有些游戏可能十几分钟那个还在运行)。让他们在统一的Bulk Synchronization Processing(BSP)模型频繁的同步,不仅仅系统开销很大,而且很难实现。另外,仿真实体往往需要实现复杂的计算行为,伴随计算中间状态的抽象,而这在Spark下难以实现。

最后,资源调度层的压力。Spark的设计初衷是解决大数据处理问题。那么数据已经静态的存储在文件系统中,Spark只需要依照资源可用性,启动一定的大小的计算图做静态计算即可。可是在大规模仿真中,这上亿个计算实体可能在计算中间大量产生和消失(例如,分布式优化算法的剪枝行为)。这些庞大的对于计算图在线修改的行为在Spark中很难有效支持。


Ray解决了什么问题?

因此,Ray针对这类超大规模仿真的计算任务提供了一种全新的计算框架。其底层利用actor而不是类似于Spark的基于系统线程实现的资源框架。

首先在抽象层次,Ray专门给RL的几大类经典仿真问题提供了专用算法框架。RL用户现在难以得到满足的计算需求得到迅速满足。另外牺牲普适性后,Ray可以为几大类的RL算法专门设计同步算法,从而高效推进算法的执行和资源利用率。


然后在计算效率上,Ray的底层使用了actor框架来实现。这么做有两大优势。第一,actor可以认为是用户级的线程。其可以轻易在16核的服务器上,同时调度上百万的actor。这使得我们可以轻易实现Billion级别的大规模仿真。第二,actor之间本身是松耦合的,在运行时大量创建和删除actor都可以在server本地完成(毫秒级别的调度延迟),并不会严重影响整个集群的运行效率(当然,这么做的假设是大量的分布式AI算法可以忍受eventual consistency,因此比BSP模型更局限)。


另一方面,actor相对于Spark系统线程实现存在三大挑战。第一,缺少了系统隔离能力,一个有害的actor实现可以轻易独占当前的cpu资源从而影响他人的使用(依赖于cooperative scheduling)。第二,由于频繁的需要在cpu上切换不同的actor,其频繁调度以及context switch的开销理论上更大。第三,大规模仿真的巨大中间计算状态的更新和存储可能成为Ray一个可能的技术债。目前论文中,他们提到利用master来存储大量的计算中间状态,而所有的仿真actor是无状态的。这样虽然可以让系统的实现变简单,但是master却非常容易成为系统的瓶颈(同步通讯,大状态存储)。


结论

因此我们可以看到,Ray其实本质上Berkeley对于AI时代大量崛起的大规模仿真计算需求的一个方案。其在牺牲了Spark等批处理框架易用性的同时,着眼于AI领域特定算法,针对AI程序员的核心诉求提供了的灵活和高性能的框架支持。


一个可以预见的场景是,人们利用spark来做大规模数据准备,利用ray来训练AI,最终将训练的AI回馈到spark的计算图里面去。

最后一句话回答本题:Spark更懂数据科学(大数据里找总结),Ray更懂AI训练(大仿真中求智慧)。