专注于最重要的事情，其他一切都会跟进 | 5Y View

作者 | wandb.ai

编译 | OneFlow社区

原标题为“Ion Stoica：Spark，Ray和企业开源”

Spark和Ray，一个是开源于2010年，专为大规模数据处理而设计的快速通用的计算引擎，另一个则是开源于2018年，由UC Berkeley RISELab推出的新一代高性能分布式计算框架，两者都已成为开源领域备受关注的明星项目，而它们成长的背后都离不开一个核心人物，Ion Stoica。

Ion Stoica 是分布式计算框架 Spark 和 Ray 的联合发起者，也是Databricks的原CEO，Databricks 和 Anyscale 的联合创始人兼执行主席。他还是加州大学伯克利分校的计算机科学教授和 RISELab的首席研究员。RISELab 是一个运作长达五年且致力于开发低延迟、智能决策技术的研究实验室，并孵化了过去十年中出现的许多令人兴奋的创业公司。

Spark和Ray不仅是业界影响力很大的开源项目，它们都以开源项目为基础发展成为商业上非常成功的公司。他们一定是做对了一连串难而正确的事才有今天，他们到底做对了什么？

在机器学习节目《Gradient Dissent》中，主持人Lukas Biewald与Ion Stoica进行了一场深度访谈，从中我们可以通过第一手资料了解到发起Spark和Ray、成立创业公司、重视开源、拥抱云这一系列关键决策是怎么做的。通过这篇文章，希望朋友们能找到Spark和Ray成功的秘笈。

Ray：如何解决分布式程序开发面临的性能和灵活性挑战

Lukas：很多听这个访谈的人都会知道Ray和Anyscale，但对于那些从事机器学习工作的人来说，他们并不知道Anyscale以及它在做什么。 

Ion：基本来讲，如果你看一下新型应用的需求，比如机器学习应用或数据应用，其增长速度远远快于单个节点或单个处理器的能力。即使你考虑了专用硬件如GPU、TPU等，情况也是一样的。因此，除了用分布式技术处理这些工作负载之外，似乎没有其他办法了。

现在，编写分布式应用非常困难。而且，如果越来越多的应用采用分布式的形式，那么人们希望通过分布式来扩展工作负载的愿望与大多数程序员所拥有的专业知识之间的差距就会越来越大。 

所以，在讨论Databricks之前，让我先从Ray说起。Ray的目标是让编写分布式应用变得更容易，通过提供一个非常灵活和极简的API来做到这一点。除此之外，我们还拥有非常强大的分布式库的生态。可能很多人都知道它们，比如用于强化学习的RLlib，用于超参数调优的Tune，以及最近的Serve，还有许多其他第三方库，如XGBoost、Horovod等。 

归根结底，如果你查看最流行的语言，例如Java或Python，它们最成功并不是因为它们是最好的语言，而是因为他们有一个强大的库的生态，当然，这个worse is better的观点仍值得商榷。开发人员喜欢库，因为如果你有用于特定应用程序或工作负载的库，只需要调用一些API就可以完成，而不用编写数千行代码。 

现在Ray是开源的。Anyscale是Ray的云托管产品。我们致力于构建开发、部署和管理Ray的最佳平台。这意味着当你在生产中部署应用时有更高的可用性、更好的安全性、自动扩容功能、工具和监控。 

在开发人员方面，我们试图为他们提供无限笔记本电脑体验的错觉。我们完成的一项调查表明，大多数机器学习开发人员仍然喜欢他们的笔记本电脑，他们仍然在笔记本电脑上做很多事情。 

我们希望在笔记本电脑上保留使用编辑器等工具的体验的同时，也希望将其扩展到云端。所以当你在笔记本电脑上做任何事情，你可以在云端处理。我们将应用打包到云端，在云端运行，自动扩容，它非常透明。这就是Anyscale提供的服务。但实际上Anyscale和Ray的目的都在于尽可能简单地扩展应用程序，尤其是机器学习应用程序。 

Lukas：你在Ray和Anyscale上投入了很多工作，但显然很长一段时间以来都存在一个问题：是什么让开发一个简单的分布式框架真正具有挑战性？ 

Ion：这是一个好问题。我们学到的一个教训是，在某种意义上，用户和开发人员真正优先考虑的是性能和灵活性，甚至超过可靠性。 

举几个例子，当我们开始开发Ray时，我们只用了任务抽象（Task），它们没有副作用（side-effect free）。任务从存储中获得一些输入，并在该输入上进行计算，将结果存储在此，然后可以被另一个任务消费。 

这是一个非常简单的模型，你可以在此基础上构建一个非常强大的系统。这是我们从Spark中学到的经验：如果你丢失了一些数据，那可以保留最初创建该数据的任务链。基于无副作用的任务，一旦知道任务的顺序，就可以重新执行任务。如果任务无副作用并且它们是确定性的，那么重新执行将获得同样的输出。我们对这样的性质很满意。 

但后来人们开始想要更高的性能，事情开始变得分崩离析。 

对于GPU，你并不只是想运行任务、获取数据和存储数据。因为即使从RAM、计算机内存、GPU内存中传输数据，这也很昂贵。然后，如果你的任务也是像TensorFlow一样执行这个操作，启动它，初始化所有变量，至少需要几秒钟。实际上会花更长时间。 

这种开销开始有点令人望而却步。人们希望状态实际上保留在GPU上，这就导致你不再继续享受那种纯粹(pure)无副作用的任务。这进而导致要提供非常好的容错性模型要困难得多。 

还有另外一个例子，人们使用强化学习，并把它用于模拟或仿真、游戏。有些游戏不是开源的，对于这些不开源的游戏，它们会有隐藏在内部的状态。 

它不会为你提供状态，你无法提取内部状态，它们让你采取向左、向右移动的操作，你只能看屏幕并阅读屏幕。 

正因如此，我们必须用actor这样的抽象，但是用了actor，提供容错能力会变得更困难。我们在Ray的第一篇论文中尝试过，假设在每种类型的actor中，都有一个顺序性的单独线程。这样，基本上，你可以对在actor上执行的方法进行排序。通过顺序化，每执行一个命令，就记录下来，然后可以重新执行来重建状态。 

但你猜猜怎么了？人们开始使用多线程。即使多线程在Python中不能很好的工作，他们仍然在使用它。然后我们就想要简化它，并尝试在多线程场景仍提供一些容错性。 

我们就增加了以下限制：如果你创建一个actor，只有创建actor的一方才能调用该actor上的方法。对actor方法的调用只有一个来源，所以至少让序列化操作仍是可行的。 

但后来，人们开始想做一些类似参数服务器的事情。对于参数服务器，不仅actor的创建者希望访问它，还可以通过另外一群actors来访问——所以其他人也需要调用actor的方法。这种来自不同actor或任务提交的不同方法就导致了复杂的并发行为。 

因此，从某种意义上说，所有这些都增加了复杂性。如果你谈论容错性，它仍然很重要，特别是在分布式系统中。 

Paxos的开发者、图灵奖得主Leslie Lamport，很久以前对分布式系统的定义是，当你不知晓的机器或服务出现故障时，系统就会停止工作。 

然后，我们不得不放弃我们理想的容错透明性。我们可以支持恢复actor，但上层应用程序必须也做一些恢复状态的工作，如果它仍需要容错的话。 

在分布式系统中，性能和容错性是困难的事情。并发是另一回事，因为事情是并行发生的，而且是在不同的机器上。 

同样，当你想让它变得灵活时，事情会困难得多。因为像在Spark中，你对并行进行抽象和限制。你不允许用户编写真正并行的应用，所以你就可以有更多的控制权。

有了Spark，为什么还要做Ray？

Lukas：在某些方面，Ray确实与Spark非常相似，我想这是基于你对Spark的经验。你能描述一下Spark，然后谈谈它是如何影响Ray的吗？ 

Ion：总的来说，Spark是为数据并行应用设计的。作为程序员，使用Spark时看到的是受控的序列，在Spark上做开发就像写普通代码一样，都是顺序化的指令，Spark中的这些指令在API的外观上和普通代码一样，而真正的区别在于，Spark的后台将在数据集上起作用，而且这个数据集都是被划分到不同的机器上去了（开头是弹性分布式数据集RDD，现在是数据框架Data Frame）。 

所以你有一个数据集，它被划分到不同的机器上。现在你在这个数据集上执行一个命令，该命令也在后台的每个数据分区上并行执行。 

当你用Spark编写程序时，你只需要操作数据集，然后应用一些函数。这种执行模式也称为批量同步处理(BSP) 的计算模型基本上是“分阶段（stage）运行”。 

每个阶段，我们都有一堆基本相同的计算，在相同数据的不同分区上进行操作。stage之间以接力的方式协作，也就是上一个stage为下一stage创建一个新的数据集以进行操作。 

最基本的stage是map和reduce，它们都是同步操作。就像一个stage对一个数据集进行操作，然后做一个洗牌操作来创建另一个数据集，其他的stage依次类推...

对于Spark程序员来说，你无法对并行做细粒度的控制。因为你编写了一个指令，该指令在语法上处于数据集级别。只有在后台接受该指令或功能时，才能在不同的分区上执行。 

这非常适合大数据处理，显然，对这种场景，Spark有一个很棒的API或数据API。 

现在，Ray的层次要低得多。Spark抽象和隐藏了并行，Ray揭示和暴露了并行。因此，你在用Ray时实际上可以说，这个任务将对这个数据进行操作，这可能会并行发生，以及这是这些任务输出之间的依赖关系。你还有另一项任务正在对这些不同任务的输出进行操作。这为你提供了灵活性，但更难编程。 

另一方面，在Spark和其他系统中，你有唯一一个启动任务的master节点，它在某个状态下启动了一个stage的所有任务。

Ray则不同，一个任务可以启动其他任务或启动actor，它们可以相互通信。对于Spark和其他BSP系统，同一stage内的任务无法相互通信。同一个stage内的任务只是在它们的分区上工作，然后传播因上一个stage引起的变动，创建另一个数据集以用于下一个stage。 

但是，对于人类来说，很难编写并行程序。我们习惯于按顺序思考，甚至上下文切换对人类也很难，顾名思义，上下文切换不一定是并行处理。这是多任务处理——做一点这个，做一点那个——即使这也很困难。我们不习惯并行思考。这很难。 

因此，这就是为什么需要用库的另一个原因，Ray上的库正是用来抽象并隐藏并行性的。如果你使用RLlib，或者使用Tune，你不知道底层并行细节也会运行良好，也不需要担心那些细节。 

但事情就是这样。这是一个更灵活、更低层次的API。开玩笑说，如果Ray能兑现我希望它能兑现的承诺，有人今天要重新开发一个Spark，那他应该在Ray之上开发Spark。 

所以，从根本上说，Ray是一个RPC（远程过程调用）框架，加上一个actor框架，以及一个对象存储，它允许你在不同函数和actor之间通过引用（reference）高效传递数据。你只需要传递引用，而不需要总是复制它。这就是灵活性的来源。 

Lukas：当你在Databricks或Spark上工作时，是否看到了让你想要开发Ray的用例？还是说Ray是你一直想创造的东西？ 

Ion：不不不，那时发生了一件事。如果现有系统不提供你需要的功能，你应该开发一个新的系统，我对这一点深信不疑。但在开发这个新系统之前，你最好尝试在现有系统上实现你想要的东西。 

当我们在2015年的秋天开发Spark时，我给研究生教一门系统课。当时我仍然是Databricks的首席执行官。Robert和Philip这两个学机器学习的学生上了这门课，他们的项目是关于数据并行机器学习训练。 当时他们用Spark来做数据并行。事实上，他们稍微修改了一下，称之为SparkNet。但后来出现了一些挑战。 

Spark太死板了。使用强化学习，你需要的计算模型要复杂得多，需要嵌套并行之类的东西。Spark对数据处理来说很棒，但现在你需要更多的灵活性来完成强化学习，这就不太合适了。 

另一件事是，Spark在Java、JVM和Scala中，至少在当时对GPU、Java没有很好的支持。这就是为什么我们开始开发Ray。Robert和Philip自己开始做了一些开发工作。

Spark和Databricks背后的故事

Lukas：那很棒。我也想听Spark的故事，我记得Hadoop具有相同的价值，每个人都对此感到非常兴奋。Spark似乎以如此不同的方式取代了它，我认为这在技术上比较罕见。我很想听听推动Spark开发的用例是什么，以及为什么你认为转变发生得这么快。 

Ion：这是一个很好的问题。Spark也始于一个课程项目。2009年春天，我在为研究生班教学，大概是云计算服务和应用程序这样的课程。其中一个项目是进行集群编排，当时的问题是，你希望同一集群能够运行多个框架，在不同框架之间共享同一集群。 

问题的来源实际上是和软件升级有关。Hadoop当时不太能向后兼容。如果你有一个新版本，升级很费事，大多数开发部署都在本地。因此，很难在内部部署另一个集群来测试新版本，然后再迁移到下一个版本。因此，如果你能够在同一集群上同时运行两个Hadoop版本，这要好得多，在当时这意味着一个巨大的价值。 

最初，这个系统被称为Nexus，但后来学术界人士告诉我们，这名字不太合适，因为他们已经用过了，所以改名为Mesos。也许你可能还记得Apache Mesos，这是上一代的Kubernetes。 

这个项目有四个人参与：Matei Zahariah，Andy Konwinski、Ali Ghodsi和Ben Hindman。使用Mesos的价值主张之一是，你可以拥有所有已有的框架，而且可以更轻松的在其上构建新的数据框架。Mesos关心框架之间的一些隔离，检测故障之类等繁杂的事情，或做一些调度。 

你会看到，开发Spark的原因之一是作为Mesos的Show Case。因为有了Mesos，开发者现在更容易只编写数百行代码就可以开发一个像Spark这样的新框架，并在Mesos上运行它。这大约在2009年年中。 

那么用例是什么？主要用例是机器学习。那是一个很棒的故事，从RADlab到AMPlab，然后是RISElab，每届实验室大约5年时间，来自机器学习、数据库，系统人员等不同学科背景的人待在同一个开放空间合作研究。大约在那个时候，Netflix也发起了一个挑战赛，这个大奖赛为开发出最佳推荐系统的参赛者发出100万美元的奖金。一个博士后Lester来问，他们有很多数据，我们有什么，可以拿来做点什么，能派上什么用场？ 

好吧，你应该用Hadoop，我们正在与Hadoop合作。我们向他展示如何使用Hadoop，Lester真的用了。但后来他回复，他用Hadoop分析了大数据，尽管没有耗尽内存，但它太慢了。显然这很慢，因为大多数机器学习算法本质上都是迭代的，你灌进去更多数据，不停的迭代改进一个模型，直到你得到一个对准确性满意的版本，就代表它收敛了。 

每一次迭代都在MapReduce作业中进行交接。每个MapReduce作业都从磁盘读写数据。当时，磁盘是慢速磁盘驱动器，所以要花很长时间。 

这是用例之一，另一个用例是查询处理。当时一些大公司都在采用Hadoop来处理大量数据。毕竟是MapReduce，谷歌也正在做MapReduce，一定很好。 

而且，这些人就像数据库人员一样，他们一直需要查看或查询数据等。现在你有了区别于数据库的巨大数据，他们要访问这些数据。他们可以访问数据，唯一需要做的就是编写Java代码，也就是MapReduce代码，然后才可以处理数据。但这些人不是这么做的，他们喜欢编写SQL语句。 

然后，人们开始开发Hive，也就是Hadoop之上的一层，提供了一些类似于SQL的查询语言。所以现在你可以在上面用SQL进行查询了。问题是，当你在数据库上做查询时，写一个查询，几乎立刻能得到答案。在大数据上你写查询时，2小时后得到一些答案，速度很慢。 

所以这些是Spark的目标用例，它的解决方式是尽可能多地将数据集保存在内存中。 

当然，Spark的诀窍不仅是将数据保存在内存中，而且也事关如何保证弹性和容错性。 

这很重要。在此之前，你想要很强大的处理能力，就买一台超级计算机。但现在你有了这个廉价服务器构建大型计算机、集群，你猜怎么着？他们很容易出错。 

所以从根本上来说，需要提供容错机制。这就是为什么Hadoop将数据落到磁盘上，是持久存储，而且会为每个数据创建三个副本。但对于Spark，现在将数据保存在内存中，是易失的。 

那么我们如何做到容错呢？你做容错时，因为只有无副作用的任务(task)，你只需要保留任务链，记录下来。如果出现故障，将重新执行任务：重新创建因失败而丢失的数据。 

这就是Spark。因为数据在内存中，机器学习应用将运行得更快。主要是因为在迭代之间，数据仍在内存中。顺便说一句，它作为一个计算模型也更灵活，因为Hadoop只能在stage里做MapReduce。但在Spark里，你可以链接更多的stage。显然，如果数据在内存中，查询会更快地返回，即使必须扫描内存中的整个数据。 

这些是启发Spark的用例，它是如何取代Hadoop的？从某种意义上说，Hadoop当时的影响是被夸大了，仍然处于泡沫中。 

2000年代太神奇了，至少在科技界都知道Hadoop和大数据。比如2012年、2013年，真正使用Hadoop的公司数量并不多，但Hadoop峰会大约有300到500人，也许是700人，这就像一个泡沫。然后Spark进入了Hadoop这个泡沫，说我们将提供更好的计算引擎。Hadoop有两个部分，一个计算引擎，即MapReduce和HDFS，也就是这个文件系统。 

起初，这是一场战斗，或者也不像战斗那么激烈。Ray长期以来一直被认为只能用于适合放在内存的小数据运行。但当我们开始时，对磁盘上的数据进行操作并不困难，即使Ray实际上从第一天起就是这样做的，但我们重心仍放在内存计算的场景，因为那是Ray最擅长的场景。（译者注：Ion Stoica 在这里想强调的意思可能是，用一个小的切口打开一个大的市场） 

然后它成为一个非常丝滑的替代品，现在是同一生态系统中的另一个引擎。后来，Cloudera在2013年押注给它，开始滚雪球般越变越大。 

Lukas：围绕Spark成立一家公司的机会是否显而易见？ 

Ion：最初，我们构建了Spark，这是一个学术项目。越来越多的人开始使用它，用户面临的一个显而易见的问题是“作为一家公司，我喜欢Spark，但我能押注它吗？当Matei或其他人毕业后会发生什么？这个项目会发生什么？”。 

我们真的很想有影响力，我们认为这是一种更好的数据处理方式，我们看到大数据处理是个大问题。无论如何最终需要有一家支持开源的公司，以使开源成为可靠的解决方案，至少对大型客户来说是如此，有两种方法可以做到这一点，被收购或者创业。 

我不会透露这家公司的名字，但我们去了一家Hadoop公司——我们是Cloudera、Hortonworks等的朋友，甚至MapR。 

我们认识一些人，他们实际上是我们在伯克利实验室的赞助商。我们问过，你想不想接管Spark。但关于Hadoop和MapReduce之后的计算引擎怎么做，他们还有其他计划。 

被收购的路走不通，创业也就自然而然了。那时，我正好要学术休假，Matei也要毕业了，Andy和Patrick已经在考虑成立一家公司了，所以一切都碰到了一起。那好吧，我们开一家公司吧。 

当我们创办公司时进行了大量讨论，其中一个大问题是公司的成功是以开源项目Spark的成功为前提的。当我们开始的时候，形势并不是很明朗。从2012年秋季开始谈论成立公司，当我们环顾四周，Linux还是一个非常特殊的现象，没有其他基于开源的独角兽，MySQL算一个，但后来才出售给Oracle。 

Lukas：Cloudera还不大吗？ 

Ion：Cloudera不够大。Hortonworks很小，不够大。仅仅一两年后，我们就开始有四十多亿美元的估值。 

此外，人们认为Cloudera进入的是云时代(coud era)，他们最初想在云端做，但那时云端的业务规模还不够大，然后他们转向本地部署。 

我们创办了这家公司后，说来话长，我们当时的决定是采用云服务这种新的商业模式。我们只在云端提供Spark的托管版本，最初只支持AWS。 

我们认为开源的成功是公司成功的必要条件。一旦开源成功了，我们把开源项目构建成最佳产品，就有希望获得这些客户。即使也可能有其他开源公司提供基于Spark的云服务，譬如后来Cloudera向他们的用户提供了Spark，然后是MapR、Hortonworks，还有AWS、Azure和Microsoft等。 

我们押注于开源的成功，为此付出了很多努力。 

Lukas：现在看来，基于开源模式的业务对于基础设施公司来说是一种非常受欢迎的策略。

Ion：Databricks是最早这样做的公司之一。在此之前，基本是本地部署的商业模式。本地部署的商业模式要重很多。一些同时期成立的公司就失败了或者并不像人们认为的那样成功。当时做云托管产品是一个相当大的赌注。至少在最初，我们也面临了转向本地化的巨大压力。但现在，为开源构建托管产品相当常见。

为什么TensorFlow和PyTorch没有商业化

Lukas：为什么你认为流行的深度学习框架，如TensorFlow和PyTorch没有在云端托管？很多企业通常在用它们，但这种商业模式在那里并不存在。 

Ion：这是一个很棒的问题。显然这不全部是事实，对于PyTorch，已经有Grid.AI提供托管产品服务了。 

我认为这些来自大公司的开源项目本身对商业变现不太感兴趣。例如，谷歌考虑TensorFlow的货币化方式可能是，即TensorFlow和其他一切都在GCP上运行的最好，特别是使用TPU，这就是他们赚钱的方式。训练TensorFlow模型的最佳地方将是GCP。 

Kubernetes也是如此。一家公司如果没有那个开源项目的创建者参与，创建业务很难。如果那个开源项目已经是另一个公司开源出来的，而你这家公司没有这个项目的开创者，那就更难了。你无法协调，也无法同步开发开源和产品。到目前为止，我还不知道有哪些公司基于Kubernetes 做商业化取得了巨大成功。你能怎么做？大多数Kubernetes开发人员仍然在谷歌。 

另一件事是，基于分布式解决方案的托管产品才更有价值，因为它的价值在于管理集群的复杂性。只要你只在一台机器上运行，价值就会小一点。 

当然，现在TensorFlow可以在不同机器上运行等等，它是分布式的。但我确实认为这是两回事。第一，使用PyTorch和TensorFlow的大部分情况是在一台机器上。其次，这些开源库的大多数开发人员仍然还是在谷歌、Facebook等这些大公司工作。我可能说得不对，但这就是我认为的一些差异。

选择创业伙伴及其他创业建议

Lukas：作为一个创办了两家非常成功的公司的人，你认为你选择的联合创始人的人与此有关吗？你在他们身上看到了什么，或者你选择的联合创始人之间的一些共同点是什么？ 

Ion：人太重要了。Databricks是一家更老一点的公司，我有更多的时间来观察它。在某些时候，要想成功，你需要一切，包括运气。我认为团队成员是互补的，尽管他们都有很多成就，但他们都没什么架子。 

作为一个团队我们非常开放。和Matei一样，我从2006年、2007年加入伯克利后认识他。Ali于2009年来到伯克利，Andy当时也在那里，然后是Patrick。我们认识很久了，讨论任何问题都非常开放。 

我们并不总是意见一致，有时会因为争论大喊大叫等等。后来有人告诉我们，当我们进行这些非常热情的交流时，由于伯克利的小办公室隔音不好，人们几乎听到了我们所谈论的一切，而我们完全没有意识到。 

在某种程度上，这看上去有点吓人，因为其余的人期许我们这些人去领导公司，但我们甚至可能在非常基本的事情上意见都不一致。不过，我们很乐意辩论。 

我认为Anyscale的Robert和Phillip也是如此，这又提到了“小我(low ego)”。你希望每个人（包括CEO等）做的一件事是，都把公司的成功置于个人的诉求之上。这是绝对正确的。俗话说，输掉的队伍里没有赢家。 

当你认识一个人很长时间，信任是绝对的基础。每家公司的生存都有高潮和低谷。一个小公司就像你有一架非常接近地面飞行的飞机，没有太多的腾挪空间。我并不是说每个人都是绝对谦虚，但他们绝对需要认可最重要的是公司的成功这一点。 

Lukas：当你成立Ray时，你已经运行了一段时间的Databricks，开始看到真正的成功。我想你是一个很不一样的人。你是否考虑过以不同于创办Databricks的方式创办这家公司？ 

Ion：让我印象最深的是，你从人们那里得到了多少很棒的反馈，以及你又把多少反馈抛之脑后。 

回想起来，把事情做成主要取决于一些基本的原则。至少在理论上，每个人都知道你需要什么才能建立一个伟大的公司。当然，你需要有一个很棒的团队。你需要远见、策略，真正关注产品市场契合度。从早期客户那里迭代，让他们变得非常成功。 

人们通常知道什么是正确的事情，但他们之所以选择错误的事情，仅仅是因为做正确的事情太困难了。 

想象一下，你去旧金山，或者选择任何你喜欢的城市，然后你问路人，成功需要什么？人们会说你需要努力工作、专注，再加上一点运气等等。每个人都会告诉你需要什么，你会得到很多类似的答案，但问题是，有多少人真正做到了？原因在于做正确的事只是很难。 

回首往事，Databricks发展得还不错的原因是我们坚持了一些事情，做对了一些事情。 

比如，我们选择了云端。我们想专注于一些事情，很早就意识到为云和本地部署是一个完全不同的工程，你需要两支团队才能搞定。我们甚至不确信能不能建立一个很棒的工程团队来把一件事做成，更不用说两件事了。 

所以，我们想可以做云，因为我们相信云市场对我们来说足够大。如果你告诉我本地部署有数百亿美元的市场规模，我们那时也做不了什么事。我们只有40或80个人，为了占领那个市场的任何一小部分都需要几年时间。想那么多有什么用呢？ 

我想说的是，从某种意义上讲，除了遵循一些最基本的原则外，我们并没有什么特别之处。Anyscale也是这样。你只要专注于你想创新的地方，其余的，你只需要尝试使用最先进的解决方案。 

那么，现在Anyscale和Databricks有什么不同呢？从某种意义上说，Databricks让我更加确信这些基本的东西是对路的，还让我更确信接近成功没有捷径，而只是努力工作。 

然后它让你更加意识到执行的重要性，而且可能是最重要的事情。正如John Doerr所说：“想法很简单，执行就是一切。” 

你会遇到一些能产生如此巨大影响的人，就像最终成为我们CRO的Ron Gabrisko一样，他在公司年收入几百万美元时加入了我们，现在把我们带到了数千万美元的营收。 

每个人都在告诉你招聘时做好背调非常重要，但这很难，因为这一切都需要努力。不幸的是，我不能告诉你有任何灵丹妙药。只要坚持基本原则，没有任何捷径可走。 

你还需要思考每家公司都是不同的，必须有所不同，因为事情会变化，例如Anyscale与Databricks。 

当我们启动Databricks时，AWS是最大的云。现在你有GCP，Azure多个云，不能忽视它们。当我们做Databricks时，关注的对象主要是数据科学家，数据工程师等等。但现在Anyscale就不同了，必须面向更广的开发人员和机器学习开发人员，不同的用户显然想要不同的东西。 

再说一遍，这并不是什么惊天动地的事情，这是显而易见的。执行和速度这些小事很重要。 

Lukas：关于第二次建立公司，你有什么不同的做法？我的理解是几乎完全一样，就像你知道你应该做什么，但在细节上，你做得更好。但我很好奇，因为你的经历与我不同，第二次你创办了一家公司，但你不是首席执行官。在某些方面和Robert合作会很难吗？我的意思是，他看起来非常聪明，令人印象深刻，但我认为这可能是他人生中的第一份工作。你一定会觉得，“我知道怎么去做但你没有这么做“，有发生这样的情况嘛？ 

Ion：不。我认为我早些时候担任Databricks首席执行官的原因是，没有人确定会长期担任这个职位。事实上，Ali想去学术界，Matei在麻省理工学院有一份工作，他正在休假等等。对于Robert和Philip，他们什么都没看，也没问什么，这就是他们想做的。 

我认为这样的安排，现在看是对路的。从 2015 年以来，我们再次合作。在我们创办公司的四年前，我们非常了解彼此。

我认为在责任方面，Robert和我，还有Philip在某种程度上我们分配得很好。如你所知，作为首席执行官有很多事情要做，与一个你可以信赖的人帮助分担一些责任去解决......

未来最想做的项目：Sky Computing

Lukas：如果你有更多的时间，是否有另一个像Spark或Ray这样的项目是你梦寐以求会去做的？ 

Ion：我认为我现在正在期待的一件事是一个叫Sky Computing的项目。它是多云平台，请考虑下云计算的互联网。从根本上说，这里的信念是......互联网所做的是将一堆不同的网络链接在一起并提供单一网络的抽象，因此，当你发送package时，你不知道package将通过哪些网络传播。 

我认为，在云计算领域，我们将越来越多地看到这一层的出现，我们称之为互联云层（intercloud layer），它将把云抽象化。 

它还会有专有云。例如，你有一个机器学习管道、数据处理、训练、服务。出于充分的理由，你实际上可以在不同的云上运行每个组件。 

例如，也许你处理的是机密数据，并希望从数据中删除P-II信息。你可以决定在Azure上执行操作，因为Azure有机密计算。你可以决定在TPU上进行训练，也可以决定使用Amazon Inferentia（新芯片）进行服务。 

我想你也会看到更专有的云的兴起，特别是机器学习。NVIDIA发布了一个名为Equinox的公告，这真的就像紧密构建的GPU优化的数据中心。 

所以我觉得这是一件令人兴奋的事情。在趋势演变中，云必然由开源驱动，提供更多的类似服务。这为出现下一个抽象层次提供了一个很好的基础。 

我认为它会发生。顺便说一句，对每家公司来说，要想取得成功，你都需要对某种不确定性押注。如果你没有对任何事情下注，你一定在做和其他人一样的事情。换句话说，当你开始创业的时候，你所相信的事情以及正在做的事情一定还不是那么明朗才行。

困境中做决策的技巧 

Lukas：最后一个问题，将机器学习模型投入生产时最困难的部分是什么？作为一个创始人，建立一个真正成功的大企业最困难的部分是什么？ 

Ion：显然每家公司都有起起落落。我认为当情况不好的时候，你可能需要纠错。它可能会因为产品无法交付而情况不好，也可能是因为你在做产品时走错了路，也许是用了不合适的人......

当事情进展顺利时就太棒了。但我认为，它总是回到基本面，尽量不情绪化并始终关注事实。是否有行业趋势，是否有来自客户的数据，是否有关于某些人不适合的问题。我们是情绪化的人类。我总是发现很难将情绪分开并把它放在次要位置，并在做决策时尝试只考虑事实。 

事情越难，你就越情绪化。因为你把它当成一种个人问题，这就是我认为的最困难的事情。而且，我也是一个情绪化的人。在某种程度上，我也非常冲动。 

总的来说，当你试图根据情绪做出决定时，对一些人来说是有效的，这是直觉，但就我而言，它不起作用。 

Lukas：你有什么技巧可以在压力下管理情绪并清晰思考吗？ 

Ion：当你面临压力时，会有很多事情发生，我会试着思考最重要的是什么，试着忘记其他一切，然后尝试简化问题，这样更容易根据事情的重要程度做出决定，这就是我发现的。特别是当一个决策和多个维度的变量相关而举棋不定时，降维和简化问题总是有用的。 

例如，当我们启动Databricks时进行了大量讨论，开源做成功是不是那么重要，特别是我们搭建了一个公司，围绕开源项目构建一个产品，在某个时候需要获得和形成一些收入。显然，有2x2种可能性：开源成功公司不成功，开源成功公司成功，开源不成功公司不成功，开源不成功公司成功。 

当我们思考这个问题的时候，如果没有开源成功，我们看不到公司成功的可能性，一旦我们得出了这个结论，就不用讨论其他的了。我们只是试图找到简化它的方法，只要你专注于最重要的事情，其他一切都会跟进。当然，试图过度简化它有时可能并不好。试着想象我需要解决的最重要的事情是什么，最重要的维度是什么。

（原文链接：

https://wandb.ai/wandb_fc/gradient-dissent/reports/Ion-Stoica-Spark-Ray-and-Enterprise-Open-Source--VmlldzoxNDEyMzY0?galleryTag=gradient-dissenthttps://wandb.ai/wandb_fc/gradient-dissent/reports/Ion-Stoica-Spark-Ray-and-Enterprise-Open-Source--VmlldzoxNDEyMzY0?galleryTag=gradient-dissent）