深度：主流分散式機器學習平台比較

這篇文章調查分析了多個分散式機器學習平台所使用的設計方法，並提出了未來的研究方向。這是我與我的學生Kuo Zhang、Salem Alqahtani通力合作的成果。我們在2016年的秋天寫了這篇論文，並且將在ICCCN"17（International Conference on Computer Communications and Networks，計算機通信與網路國際會議）上介紹這篇文章。

機器學習，特別是深度學習（DL），最近已經在語音識別、圖像識別、自然語言處理、推薦/搜索引擎等領域獲得了成功。這些技術在自主駕駛汽車、數字衛生系統、CRM、廣告、物聯網等方面都存在著非常有前景的應用。當然，資金驅動著這些技術以極快的速度向前發展，而且，最近我們已經看到了有很多機器學習平台正在建立起來。

由於在訓練過程中要涉及到龐大的數據集和模型的大小，因此機器學習平台通常是分散式平台，而且並行運行了10到100個作業來訓練模型。據估計，在不久的將來，數據中心的絕大多數任務將是機器學習任務。

我的知識背景是分散式系統，因此，我們決定從分散式系統的角度來研究這些機器學習平台，分析這些平台的通信和控制瓶頸。我們還研究了這些平台的容錯性和編程的難易性。

我們根據三種基本的設計方法對分散式機器學習平台進行了分類，分別是：

1. 基本數據流

2. 參數伺服器模型

3. 高級數據流

我們將對每一種方法進行簡單的介紹，我們使用Apache Spark作為基本數據流方法的示例，使用PMLS（Petuum）作為參數伺服器模型的示例，使用TensorFlow和MXNet作為高級數據流模型的示例。 我們將提供它們之間的性能比較評估結果。有關更多的評估結果，請參閱本文最開始提到的那篇論文。不幸的是，我們無法作為一個來自學術界的小團隊進行規模上的評估。

在這篇文章的末尾，我對分散式機器學習平台的未來工作提出了總結性意見和建議。如果你已經有這些分散式機器學習平台的使用經驗，可以直接跳到文章的末尾。

Spark

在Spark中，計算被建模為有向無環圖（DAG， directed acyclic graph），其中的每個頂點表示彈性分散式數據集（RDD， Resilient Distributed Dataset），每個邊表示RDD上的操作。 RDD是以邏輯分塊進行劃分的對象集合，它緩存在內存中，當內存不夠時，會保存到磁碟上。

在DAG上，從頂點A到頂點B的邊E表示RDD B是在RDD A上執行操作E的結果。有兩種類型的操作：轉換和動作。轉換（例如，映射、過濾、連接）就是對RDD執行操作併產生新的RDD。

Spark用戶將計算作為DAG進行建模，該DAG會轉換並運行RDD上的動作。DAG會分階段進行編譯。每個階段將作為一系列的任務並行執行（每個分區一個任務）。窄的依賴關係有利於高效的執行，而廣泛的依賴關係會帶來瓶頸，因為它們會破壞流水線，而且需要通信密集的隨機操作。

Spark中的分散式執行是通過對機器上的DAG階段進行分塊來實現的。這個圖清晰地展示了master-worker架構。Driver包含了兩個調度組件，DAG調度器和任務調度器，用於給workers分配任務，以及協調workers。

Spark是為一般數據處理而不是為機器學習設計的。然而，利用專用於Spark的MLlib，使得在Spark上進行機器學習成為可能。在基本的設置中，Spark將模型參數存儲在driver節點中，而workers與driver進行通信，以便在每次迭代後更新參數。對於大規模的部署來說，模型參數可能不適合保存在driver中，而應該將其作為RDD進行維護。這引入了很大的開銷，因為需要在每次迭代中創建新的RDD以保存更新過的模型參數。更新模型包括在機器/磁碟之間混洗數據，這限制了Spark的可擴展性。這是Spark中基本數據流模型（DAG）不足的地方。 Spark不支持機器學習所需的迭代。

PMLS

PMLS從誕生的那一天起就是專門為機器學習設計的。它引入了參數伺服器（parameter-server，簡寫為PS）抽象用於迭代密集型機器學習訓練過程。

PS（在圖中用綠色的框表示）用於分散式內存鍵值的存儲。它複製和分片的方式是這樣的：每個節點既是模型中某個分片的主節點，又是其他分片的輔節點（或副本）。因此，PS可以通過增加節點數量的方法很容易地進行擴展。

PS節點用於存儲和更新模型參數，並響應workers的請求。workers從本地PS副本中請求最新的模型參數，並對分配給自己的數據集分區進行計算。

PMLS還採用了SSP（Stale Synchronous Parallelism，變味的同步並行）模型，它放寬了BSP（Bulk Synchronous Parellelism，批量同步並行）模型中workers在每次迭代最後要進行同步操作的要求。 SSP減少了workers同步的難度，確保最快的worker不能在最慢的worker之前迭代。由於對過程中產生的雜訊具有一定的容錯能力，這個寬鬆的一致性模型仍可適用於機器學習訓練。 我已經在2016年4月的一篇博客文章里介紹了這一點。

TensorFlow

Google有一個基於分散式機器學習平台的參數伺服器模型，名為DistBelief。這是我對DistBelief論文的評論。我在這篇文章中指出，人們對DistBelief主要的抱怨是編寫機器學習應用程序的時候會弄亂底層代碼。Google希望公司內的任何員工無需精通分散式執行就能編寫機器學習代碼，這也是Google為大數據處理編寫MapReduce框架的原因。

所以，TensorFlow正是為了實現這一目標而設計的。TensorFlow採用了數據流範例，但在它的高級版本中，計算圖不需要是DAG，但可以包括循環和支持可變狀態。我想，可能是Naiad的設計對TensorFlow產生了一些影響吧。

TensorFlow中的計算可以表示為一個帶有節點和邊的有向圖。節點表示具有可變狀態的計算。邊表示在節點之間傳遞的多維數據矩陣（張量）。 TensorFlow要求用戶靜態地聲明這個符號計算圖，並且使用圖形的重寫和分區來讓機器進行分散式的執行。

如上圖所示，這個TensorFlow中的分散式機器學習訓練使用了參數伺服器的方法。在TensorFlow中使用PS抽象的時候，可以使用參數伺服器和數據並行機制。對於TensorFlow來說，你可以做更為複雜的事情，但這需要編寫自定義代碼並走入未知的領域。

一些評估結果

為了對這些平台進行評估，我們使用了Amazon EC2 m4.xlarge實例。每個實例包含由Intel Xeon E5-2676 v3處理器和16GB RAM組成的4個vCPU。EBS帶寬為750Mbps。我們使用兩種常見的機器學習任務進行評估：使用多層神經網路的二級邏輯回歸和圖像分類。我只是在這裡提供幾張圖，請查看我們的論文以進行更多的實驗。我們的實驗有幾個限制：我們使用的機器比較少，不能進行規模上的測試。我們的測試僅限於CPU計算，並沒有進行GPU計算測試。

該圖顯示了邏輯回歸平台的速度。Spark比PMLS和MXNet慢，但表現得還算可以。

該圖顯示了DNN平台的速度。與單層邏輯回歸相比，Spark的性能損失比兩層NN更大，這是因為需要更多的迭代計算。這裡，我們將driver的參數保存在Spark中。如果我們將參數保存在RDD中並且在每次迭代之後進行更新，情況會更糟。

該圖顯示了平台的CPU利用率。 Spark應用程序的CPU利用率明顯比較高，主要是因為存在序列化的開銷。以前的工作已經指出了這個問題。

結語，以及未來的方向

機器學習/深度學習應用程序有著令人尷尬的並行機制，而且從並發演算法角度來看也並不是很有趣。可以肯定的是，參數伺服器方法贏得了分散式機器學習平台訓練的青睞。

至於瓶頸問題，網路仍然是分散式機器學習應用程序的瓶頸。更好的數據或模型分級比更先進的通用數據流平台更有用，請重視數據和模型。

然而，也存在著一些令人驚訝和微妙的地方。 在Spark中，CPU開銷正在成為比網路限制更為重要的瓶頸。 Spark中使用的編程語言（例如Scala/JVM）會顯著影響它的性能。因此，特別需要一個更好的工具來進行分散式機器學習平台的監控和性能預測。近來，已經出現了一些能夠解決Spark數據處理程序問題的工具，例如Ernest和CherryPick。

支持機器學習運行時的分散式系統存在著許多懸而未決的問題，例如資源調度和運行時性能提升。通過對應用程序運行時的監控和分析，下一代分散式機器學習平台應該要為正在運行的任務提供計算、內存、網路資源的通用運行時彈性配置和調度。

最後，還有編程和軟體工程支持方面的問題有待解決。適用於機器學習應用程序的分散式編程抽象是什麼？還需要更多的研究來檢驗和確認分散式機器學習應用程序。

文章原標題《A Comparison of Distributed Machine Learning Platforms》，作者：Murat，譯者：夏天，審校：主題曲。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！