Ion Stoica：做成Spark和Ray兩個明星專案的祕笈

語言: CN / TW / HK

時間 2022-02-08 17:02:43 OneFlow深度學習框架

主題: hadoop 機器學習 tensorflow mapreduce apache mesos cloudera 大資料 java

作者 | 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種可能性：開源成功公司不成功，開源成功公司成功，開源不成功公司不成功，開源不成功公司成功。

當我們思考這個問題的時候，如果沒有開源成功，我們看不到公司成功的可能性，一旦我們得出了這個結論，就不用討論其他的了。我們只是試圖找到簡化它的方法，只要你專注於最重要的事情，其他一切都會跟進。當然，試圖過度簡化它有時可能並不好。試著想象我需要解決的最重要的事情是什麼，最重要的維度是什麼。

（本文已獲取編譯轉載授權，因翻譯引入的繆誤由譯者承擔責任。原文連結：

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

其他人都在看

歡迎下載體驗OneFlow新一代開源深度學習框架：http://github.com/Oneflow-Inc/oneflow/

‍

本文分享自微信公眾號 - OneFlow（OneFlowTechnology）。
如有侵權，請聯絡 [email protected] 刪除。
本文參與“OSC源創計劃”，歡迎正在閱讀的你也加入，一起分享。

「其他文章」