加州大学伯克利分校为何能连续孵化出 Mesos,Spark,Alluxio,Ray 等重量级开源项目? 第1页

有人说，整个大数据时代基本是追着Google和UC Berkeley RISELab跑。Ion Stoica便是RISELab背后的那个男人。@包云岗 老师多次宣传Berkeley的那种“科研重工业模式”，而Ion Stoica便继承了Berkeley的这种传统，每隔一段时间就推出一个大项目：从早期的Chord，到后来的Mesos、Spark、李浩源和 @范斌 创立的Alluxio、Ray……每个项目都极富影响力，在学术界和工业界掀起了巨浪，让Berkeley在计算机系统领域封神。

科学网-伯克利科研模式的启发 - 包云岗的博文

前不久，Ion接受了一个访谈，提到了这些项目背后的故事和思考。以前我也断断续续从各个地方听说了这些故事，但这一次是作者亲自回答，权威而又系统，非常insightful。在本文中，我整合了这个访谈的各个零碎部分，同时加入了一些个人思考，抛砖引玉，供大家参考。

采访视频：https://www.youtube.com/watch?v=-MVLURFH5nk

采访文本：Weights & Biases

参考译文：Ion Stoica：做成Spark和Ray两个明星项目的秘笈

Mesos

Apache Mesos是上一代的Kubernetes，它来自于2009年春天Ion开的一门和云计算相关的研究生课程。这门课的课程项目中有一个和集群编排有关，希望同一集群能够运行多个框架，这便是Mesos的前身。这个问题来自软件升级。当时Hadoop向后兼容能力差，而用户很难在内部部署另一个集群来测试新版本，然后再迁移到下一个版本，所以升版本很费事。而Mesos允许你在已有的框架上构建新的数据框架，由Mesos负责一些调度和各个框架之间的隔离、检测故障等琐事，从而使用户能在同一集群上同时运行两个Hadoop版本。

该项目有四个人参与：Matei Zahariah，Andy Konwinski、Ali Ghodsi和Ben Hindman，其中Ben Hindman中止了其PhD学业，创建了依托Mesos的商业公司Mesosphere。

虽然Mesos被Kubernetes吊打，前段时间差点进了Apache Attic，Mesosphere也改名成了D2iQ，卖起了“The Leading Enterprise Kubernetes Solution”，但毕竟曾经风光无限，作为先驱是值得我们尊敬的。

https:// hacker-news.news/post/2 6713082

Spark

Spark一开始是作为Mesos的showcase而被开发出来的。因为有了Mesos后，开发者只用写几百行代码就能开发出Spark这样的新框架，然后让它跑在Mesos上。不过据我所知，这一开始是Matei的一个课程项目。

当时Spark的use case主要是机器学习和查询处理。

机器学习这个use case得益于RISElab的运营模式。RISElab大概每过五年就会换一个名字，从早期的RADlab到因Spark而为人熟知的AMPlab，再到现在的RISElab，这期间来自机器学习、数据库、系统等不同学科背景的人待在一块合作研究，碰撞出各种火花。Ion没提的是，其实从某种角度而言，与工业界人员的频繁交流也是这个实验室不可或缺的一部分。

那时候Netflix发起了一个挑战赛，奖励开发出最佳推荐系统的参赛者100万美元。当时实验室的博士后Lester问实验室里做system的人说，怎么处理这些海量数据呢？于是其他人让他用Hadoop。他用了，然后表示Hadoop太慢了。这很好解释，因为很多机器学习算法都是迭代式的，你灌进去数据后不停的迭代改进一个模型，直到某个版本的模型其准确性收敛到你设定的标准。每一次迭代都被翻译成了一个MapReduce job，每个MapReduce job都从磁盘中读写数据，而当时磁盘是非常慢的。

查询处理这个use case则来自于工业界的直接需求。当时一些大公司在用Hadoop和Hive或Pig Latin来处理大量数据，大家都相信这些来自于Google等大公司的技术方案不会有问题。但问题是，当你在数据库上写一个查询，几乎立刻就能得到答案；而当你在大数据系统上写一个查询，可能两小时后才能得到一些答案，这太慢了。

然后Spark则通过内存计算和lineage，在保证容错的情况下加速了这些计算。

接着，Spark就开始了和Hadoop MapReduce的战斗，然后不断地攻城略地，特别是在2013年Cloudera给Spark押注后，Spark像滚雪球般势如破竹，轻松赢下了这场战斗。Spark之所以能快速替代Hadoop MapReduce，一定程度上是因为Hadoop当时仍处于泡沫中。虽然在2000年代Hadoop对整个科技界都是如雷贯耳，但一直到2012年和2013年时真正使用Hadoop的公司都并不多，那时Hadoop峰会只有几百人参加。

而之所以会成立Databricks公司，是因为Ion的团队非常希望凭借扩大Spark的影响力来扩大自身的影响力，而Spark要想扩大影响力就得有商业化支持。最初，Spark是一个学术项目，那些喜欢Spark的公司会担心Matei或其他人毕业后这个项目何去何从，从而不敢给它押注。所以对客户来说，需要有一家公司使这个开源项目成为一个可靠的解决方案。

而要商业化，只有两条路可走，要么被收购，要么去创业。

一开始，Ion去了一家Hadoop公司，毕竟他是Cloudera、Hortonworks和MapR等公司的朋友，这家公司也是实验室的赞助商。Ion发现他们无意接管Spark，因为他们对于在MapReduce之后Hadoop的计算引擎怎么发展另有谋划。

那么就只能创业了。他们从2012年秋季开始谋划成立公司的事，然后刚好那时候Ion要学术休假，Matei要毕业了，Andy和Patrick在考虑成立一家公司......万事俱备，只欠东风，所以他们就创办了Databricks公司。一开始是由Ion担任Databricks CEO，因为那时候没有人确定会长期担任这个职位：Ali想去学术界，Matei在MIT做助理教授，当时正在休假......其他人也都有各自的原因。不过，2016年后Ali接管了Databricks的CEO一职。

创办公司时，他们进行了大量的讨论，很大一部分是关于公司产品形态的，包括开源项目成功和公司成功的关系，以及是做本地部署还是云服务。

那时开源公司的形势尚不明朗。虽然基于Linux的商业化成功了，但那个现象过于特殊。而Cloudera不够大，Hortonworks也很小。曾经基于MySQL的商业化成功了，但后来公司还是卖给了Oracle。除此以外，就没有其他开源独角兽了。Ion认为开源项目的成功是公司成功的必要条件。因为这样的话，只要公司能够基于开源项目打造出最好的产品，那就有希望赢得大量的客户。可以说，Databricks是最早基于开源来发展云服务的公司之一，而如今不管是国内还是国外，基于开源的基础设施公司都很多。

Databases in 2021: A Year in Review - OtterTune

Yingjun Wu：投资数据库领域：2021年总结（OLTP、OLAP、streaming）

Yingjun Wu：投资数据库领域：2021年总结（NoSQL、图、时序）

选择放弃做本地部署而去做云服务，同样是艰难重重。比如说，大家都觉得Cloudera既然名为“coud era”，那它最初肯定是想做云服务的。这可能是真的，但那时云端的业务规模还不够大，所以Cloudera还是转向了本地部署。即便如此，Databricks依旧决定采用云服务这种新的商业模式。

当时做云服务产品风险很大，因为此前业界基本都是做本地部署，所以一开始时Databricks也面临了转向本地部署的巨大压力。一些同时期成立的公司就选择了做本地部署，结果虽然他们开源做的很成功，公司却失败了，或者不像人们想象的那么成功。

Ion很早就意识到云服务和本地部署是两回事，需要两支团队才能搞定。但他们那时只有40或80个人这个样子，连能不能做好一件事都不清楚，更不用说两件事了。他们相信云市场对当时的公司而言足够大，所以打算all in cloud。即使本地部署的市场有数百亿美元，他们那时也无可奈何，因为占领那个市场的任何一小部分都需要几年时间，想那么多有啥用呢？

而这些决策的结果就是，仅仅一两年后，Databricks的估值就高达四十多亿美元了，现在经历了去年股价起飞和与Snowflake的厮杀后更是直接封神，彻底成功！

那为什么好像没有什么云服务公司基于TensorFlow和PyTorch呢？主要是因为这些来自大公司的开源项目本身另有变现方式。例如，TensorFlow框架在GCP上运行的最好，特别是用上了TPU后。Kubernetes等其他框架也差不多。

虽然对于PyTorch有Grid.ai公司来提供云服务，但一家公司如果没有那个开源项目的创建者参与，业务开展就会比较困难，因为你很难协调同步开源项目和商业产品的开发，而这些人都在大公司里待着呢。

另一个insight是，基于分布式解决方案的云服务会更有价值，因为它能够降低管理集群的复杂性。如果产品本身是单机的，那价值就会小一点。

Ray

2015年的秋天，Ion给研究生教一门系统课，当时他仍是Databricks的CEO。课上有两个学生，叫做Robert和Philip，他们是学机器学习的。他们俩的课程项目是data parallel training。当时他们改了改Spark，搞出了SparkNet，但发现了一些问题。

首先，Spark太死板了。有些场景下，比方说强化学习，我们需要的计算模型比大数据处理场景复杂得多，需要嵌套并行之类的东西，对此Spark不够灵活。

其次，Spark是基于JVM的，而当时这套生态对于GPU支持得不够好。

有一个系统开发的准则，就是如果你需要一些功能，最好尝试在现有系统上实现它们，如果现有系统不提供你需要的功能，你再开发一个新系统。所以Robert和Philip从头开发出了Ray，后来又和Ion以及Michael I. Jordan一起成立了基于Ray的公司Anyscale。

Ray的story依旧是降低分布式应用的难度，只是这一次是专门面向机器学习。

2017年图灵奖获得者John Hennessy与David Patterson在其图灵奖获奖演讲中表示，在摩尔定律走向终点的同时，GPU、TPU等专用硬件让体系结构闪耀出新的活力。

https://www. youtube.com/watch? v=3LVeEjsn8Ts&t=125s

恰好，这个演讲也在Spark Summit上做过一次。Ion可能受该演讲影响，在其本次访谈和其博文《The Future of Computing is Distributed》中表示，机器学习等新型应用的增长速度远远快于单个节点或单个处理器的能力，即使你考虑了GPU、TPU等专用硬件后情况也一样。尽管GPU和TPU等加速器带来了更多算力，但它们本质上是在给摩尔定律续命罢了，而非从根本上提高速度。在机器学习的热潮下，毫无疑问，摩尔定律已死。因此，只能用分布式技术来处理这些负载。

https://www. anyscale.com/blog/the-f uture-of-computing-is-distributed

我觉得其实双方都是在鼓吹自己所处领域在大规模机器学习中的应用，本身并不冲突，毕竟这些年各种分布式系统和新硬件的结合工作并不少见。

Ray的story具体说来，是指大多数机器学习开发人员仍然喜欢在笔记本电脑上做各种数据处理，很多人对分布式技术所知甚少。Ray的目标正是让编写分布式应用变得更容易。它提供了一套非常灵活且极简的API，并且拥有非常强大的生态——正如Java或Python等很多语言的成功并不一定是因为它们是最好的语言，而是因为他们有一个强大的生态。Ray允许开发人员使用笔记本电脑来开发程序，然后让这些程序能在云端运行，并且自动扩缩容。这一切对于程序员都是透明无感的，和云相关的部分由Ray负责处理。

总的来说，Ray和Spark的主要差别在于他们的抽象层次。Spark对并行进行抽象和限制，不允许用户编写真正并行的应用，从而使框架有更多的控制权。Ray的层次要低得多，虽然给用户提供了更多灵活性，但更难编程。可以说，Ray揭示和暴露了并行，而Spark抽象和隐藏了并行。

就架构而言，Spark采用BSP模型，是无副作用的，而Ray本质上是一个RPC 框架+Actor框架+对象存储。

Spark中有一个启动任务的master节点，它在某个状态下启动了一个stage的所有任务。同一stage内的任务无法相互通信，只能在它们的分区上工作，然后传播因上一个stage引起的变动，创建另一个数据集以用于下一个stage。而在Ray中，一个任务可以启动其他任务或启动actor，它们可以相互通信。

Ray主要是针对复杂机器学习场景而设计的。

一方面，由于从主存中往显内存中传输数据开销非常大，像TensorFlow那样初始化变量将耗时很久，所以用户希望把状态保留在GPU中。

另一方面，用户可能会在仿真或游戏中使用强化学习，而这些游戏之类的应用可能不开源，所以它们会隐藏其内部状态，从而用户无法获取这些内部状态。

这一切都导致了Ray转向了Actor模型，而不像Spark那样采用BSP模型。而Actor模型中的容错就难得多了。在分布式系统中，想兼具高性能、容错性和灵活性本质上就非常困难。

Ray一开始指出顺序化的Actor模型可以重建状态。它假设在每个actor中都只有一个顺序的单线程，这样可以排序那些要在actor上执行的方法，再记录这些方法，并通过回放命令来重建状态。

但接着就遇到了多线程场景的容错。虽然多线程在Python中不太好使，但你阻止不了用户去用它。为了给多线程场景提供一些容错性，让排序操作仍然可行，得让每个actor的方法都只有一个调用源，所以Ray规定只有创建actor的一方才能调用该actor上的方法。

再后来，人们想做一些类似Parameter Server的事。对于Parameter Server，除了actor的创建者，其他actors也会调用某个actor的方法。这种来自不同actor的方法调用导致了复杂的并发行为。所以Ray不得不放弃理想化的透明容错，而要求那些想容错的上层应用程序做些恢复状态的工作。

重复一下，从根本上说，Ray是一个RPC 框架+Actor框架+对象存储，它允许你在不同函数和actor之间通过引用传递来高效传递数据，这使得它很灵活。理论上，如果要在今天重新开发一个Spark，最好在Ray之上开发Spark。

Sky Computing

Ion现在正在期待的一件事是一个叫sky computing的多云平台项目，这个项目会在下一次实验室改名字时做。

传统上，互联网将一堆各种各样的网络连接在一起，将它们抽象成单一网络，因此当发送一个package时你不知道这个package将通过哪些网络进行传播。

而将来，云计算场景下也可能会出现一层互联网抽象，这被称为intercloud layer（互联云层），它将各种各样的云抽象化。

举个例子，一个机器学习pipeline中，data processing、training、serving等环节可能适合在不同云上进行。比方说，data processing时你处理的是机密数据，所以希望从数据中删除P-II信息，那你就可以在Azure上执行操作，因为Azure有机密计算。同时，你可能想在TPU上进行training，并且使用Amazon Inferentia这种新芯片进行serving。

当前，各种专用云（specialized cloud）不断涌现，特别是些面向机器学习的专用云，比如NVIDIA发布的Equinox就是针对GPU而优化的数据中心。这些都为intercloud layer的出现提供了一个很好的基础。

Intercloud layer的想法看似疯狂，不过确实有可能实现。不过话说回来，一家公司要想取得成功，必须对某种不确定性押注。如果你没有对任何事情下注，你一定在做和其他人一样的事情。换句话说，当你开始创业的时候，你所相信的事情以及正在做的事情一定还不是那么明朗才行。

开源公司

不管是在Databricks还是在Anyscale，团队成员都是互补的，尽管他们都有很多成就，但他们都非常随和开放。他们并不总是意见一致，有时会因为争论大喊大叫等等。后来才有人告诉他们，由于Berkeley的小办公室隔音不好，人们几乎听到了他们谈论的一切，而他们完全没有察觉。这些公司的领导在非常基本的事情上意见都不一致，这看上去有点吓人，不过大家还是很乐意辩论。

Ion表示，Databricks成功的原因有几点。一方面是遵循了一些众所周知的基本原则，这个难点在于执行力；另一方面是坚持了一些对的事情，比如选择了云服务；还有就是从别人那获取优质反馈，并重视这些反馈。除此外再无捷径，唯有努力工作，希望好运来临。

不过，或有意或无意，Ion省略了很多RISElab成功的秘诀。据我所知，RISElab对于方向的把握总是非常好，因为它和工业界建立了大量联系；实验室的学生质量也非常好，能够撑起一个个大项目，事实上很多学生读博前都在工业界待过；然后开源社区又玩得很溜，能够很好的扩大自己的影响力。

所以，他们总能提前洞察到业界的需求，比如说Mesos、Spark以及Ray都和Ion布置的课程项目紧密相关；

所以，他们总能把一些research prototype转变为production-ready的项目，甚至在早期就敢雇佣全职程序员提升Spark的代码质量，在Spark被收购无望后直接开起了创业公司；

所以，他总是能在正确的时间做正确的事情，并且觉得这些事理所当然，不值一提。