如何選擇合適的分散式機器學習平台

本文比較了機器學習平台設計方法和使用指南，是我和 Kuo Zhang 和 Salem Alqahtani 同學合作而成。 我們在 2016 年秋天寫了這篇文章，並在 ICCCN"17（溫哥華）提交了這篇文章。

機器學習，特別是深度學習（DL）在語音識別，圖像識別和自然語言處理以及推薦/搜索引擎方面取得了成功。 這些技術在自主駕駛汽車，數字衛生系統，CRM，廣告，物聯網等方面都有廣泛的應用。隨著這些資本進入進一步推動技術變革，我們已經看到許多機器學習平台。

由於訓練中涉及到的巨大的數據集和模型大小，機器學習平台通常是分散式 ML 平台，通常並行運行了 10 - 100 個 worker 來訓練模型。 據估計，數據中心的絕大多數任務將在不久的將來成為機器學習任務。

於是我們決定從分散式系統的角度研究這些 ML 平台，分析這些平台的通信和控制瓶頸。 我們還研究了這些平台的容錯性和是否易於編程。

我們根據 3 種基本設計方法對分散式 ML 平台進行分類：

1. 基本數據流

2. 參數伺服器模型

3. 高級數據流

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

在這篇文章末尾，我將介紹分散式 ML 平台未來工作的總結和建議。 如果您已經有了這些分散式 ML 平台的經驗，請直接跳到最後。

在 Spark 中，計算被建模為有向無環圖（DAG），其中每個頂點表示彈性分散式數據集（RDD），每個邊表示RDD上的操作。 RDD 是劃分為邏輯（內存中或者交換到磁碟上）分區的對象集合。

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

Spark 用戶將計算作為 DAG 進行建模，該 DAG 會轉換並運行 RDD 上的操作。 DAG 被分階段編譯。 每個階段作為一系列並行運行的任務（每個分區的一個任務）而執行。 窄依賴關係對於高效執行是有好處的，而寬依賴關係則引入瓶頸，因為它們會中斷執行流水線並需要執行通信密集的操作。

通過在區分 DAG 階段來達成 Spark 中的分散式執行。 該圖顯示了 master 的架構。 driver 包含兩個調度程序組件，DAG 調度程序和任務調度程序，還有負責任務和協調 worker。

Spark 設計用於一般數據處理，而不是專門用於機器學習。 然而，在 Spark 上使用 MLlib，就可以在 Spark 上做 ML。 在基本設置中，Spark 將模型參數存儲在 driver 節點中，而 worker 與 driver 進行通信，以便在每次迭代後更新參數。 對於大規模部署，模型參數可能和 driver 不匹配，並將作為 RDD 維護。 這引入了很多開銷，因為需要在每次迭代中創建新的 RDD 以保存新模型參數。 更新模型需要在機器間混洗數據，這限制了Spark 的可擴展性。 這是 Spark 中的基本數據流模型（DAG）不足的地方。 Spark 不支持 ML 中需要的迭代過程。

PMLS 專為 ML 設計的。 它引入了參數伺服器（PS）以服務於迭代密集的 ML 訓練過程。

PS（在圖中的綠色框中顯示）使用分散式內存鍵值存儲來維護參數信息。 它可以複製和分片：每個節點作為模型（參數空間）的分片的主節點，以及其他分片的副本。 因此，PS相對於節點數量很容易擴展。

PS節點存儲和更新模型參數，並響應worker的請求。 worker從其本地PS副本中請求最新的模型參數，並對分配給它們的數據集分區執行計算。

PMLS還採用了同步並行（SSP）模型，該模型放寬了在每次迭代結束時工人進行同步的批量同步平行（BSP）的限制。 SSP減少了worker的同步困難，確保最快的worker不能在最慢的worker之前進行。 由於處理過程的雜訊容限，該一致性模型仍然適用於ML訓練。 我在2016年4月的博客文章[1]中介紹過。

TensorFlow

Google 有一個基於分散式機器學習平台的參數伺服器模型，名為 DistBelief。 （這是我對 DistBelief 論文的評論[2]）可以看出，DistBelief 的主要問題是，它需要混寫在 ML 應用程序的低級代碼中。 Google 希望其任何員工能夠編寫 ML 代碼，而不需要他們精通分散式執行 - 這與 Google 為大數據處理編寫 MapReduce 框架的原因相同。

所以 TensorFlow 旨在實現這一目標。 TensorFlow 採用數據流範例，但計算圖不需要 DAG 高級版本，但可以包括循環和支持可變狀態。 我認為 Naiad[3] 設計可能對 TensorFlow 設計有一些影響。

TensorFlow 表示使用節點和邊的有向圖進行計算。 節點表示具有可變狀態的計算。 邊緣表示在節點之間傳遞的多維數據陣列（張量tensor）。 TensorFlow 要求用戶靜態地聲明這個符號計算圖，並且利用圖的分區和重寫達成分散式計算。 （MXNet，特別是 DyNet，可以動態聲明符號計算圖，這提高了編程的簡單性和靈活性。）

在 tensorflow 分散式 ML 訓練使用參數伺服器的方法如圖所示。 在 TensorFlow 中使用 PS 抽象時，可以使用參數伺服器和數據並行。 TensorFlow 可以做更複雜的事情，但這需要編寫自定義代碼並進入未知領域。

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

該圖顯示了邏輯回歸執行的速度。 Spark 僅在 PMLS 和 MXNet 之後。

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

該圖顯示了平台的 CPU 利用率。 Spark 應用程序似乎具有更高 CPU 利用率（序列化開銷）。

結語和未來方向

ML / DL應用程序的並行計算並非很出色，從並發演算法的角度來看略微無趣。 在分散式ML平台上的參數伺服器是決定性因素。

就瓶頸而言，網路仍然是分散式ML應用程序的瓶頸。 與其在更先進的通用數據流平台上工作，不如提供更好的數據/模型，將數據/模型作為一等公民來處理。

但是，也可能會有一些驚喜和微妙之處。 在Spark中，CPU開銷正在成為瓶頸[4]。Spark中使用的編程語言（即Scala / JVM）會顯著影響其性能。 因此，需要更好的工具來進行分散式ML平台的監視和/或性能預測。 近來已經提出了一些解決Spark數據處理應用程序問題的工具，如Ernest[5]和CherryPick[6]。

分散式系統支持ML運行時還有許多開放性問題，例如資源調度和運行時性能改進。 通過對應用程序的運行時監控/分析，下一代分散式ML平台應為運行的任務提供計算，內存，網路資源的通用運行時彈性配置和調度。

最後還有編程和軟體工程支持的問題。 適用於ML應用程序的[分散式]編程抽象是什麼？ 這還需要更多的分析ML應用程序的驗證和驗證（測試具有特別有問題輸入的DNN）。

1. https://muratbuffalo.blogspot.com/2016/04/petuum-new-platform-for-distributed.html

2. https://muratbuffalo.blogspot.com/2017/01/google-distbelief-paper-large-scale.html

3. http://muratbuffalo.blogspot.com/2014/03/naiad-timely-dataflow-system.html

4. http://muratbuffalo.blogspot.com/2017/05/paper-summary-making-sense-of.html

5. https://spark-summit.org/east-2017/events/ernest-efficient-performance-prediction-for-advanced-analytics-on-apache-spark/

6. https://blog.acolyer.org/2017/05/04/cherrypick-adaptively-unearthing-the-best-cloud-configurations-for-big-data-analytics/

英文原文：http://muratbuffalo.blogspot.com/2017/07/a-comparison-of-distributed-machine.html

本文作者 Murat，由 Jesse 翻譯，轉載譯文請註明出處，技術原創及架構實踐文章，歡迎通過公眾號菜單「聯繫我們」進行投稿。

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