如何選擇合適的分布式Machine Learning Platform for AI

這是一個建立於 的文章，其中的資訊可能已經有所發展或是發生改變。

導讀：機器學習和深度學習是近年技術的熱點，面對眾多的Machine Learning Platform for AI如何進行選擇，這是一個很困擾的問題。本文對分布式機器學習（ML）平台中使用的設計方法進行了調查，並提出了未來的研究方向。

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

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

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

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

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

1. 基本資料流

2. 參數伺服器模型

3. 進階資料流

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

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

Spark

在 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

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

PS（在圖中的綠色框中顯示）使用分布式記憶體KVStore for Redis來維護參數資訊。 它可以複製和分區：每個節點作為模型（參數空間）的分區的主節點，以及其他分區的副本。 因此，PS相對於節點數量很容易擴充。

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

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

TensorFlow

Google 有一個基於分布式Machine Learning Platform for AI的參數伺服器模型，名為 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 翻譯，轉載譯文請註明出處，技術原創及架構實踐文章，歡迎通過公眾號菜單「聯絡我們」進行投稿。

    推薦閱讀

• 一鍵搭建深度學習平台，基於Docker/Mesos和NVIDIA GPU詳細教程

• 迭代速度慢？成熟的機器學習流如何設計：微博大規模機器學習架構Weiflow揭秘

• 使用深度學習方法實現面部表情包識別

• Spark的RDD原理以及2.0特性的介紹

• Machine Learning Platform for AI痛點與模型提升方法：基於Spark的Machine Learning Platform for AI在點融網風控應用介紹
  

高可用架構

改變互連網的構建方式

長按二維碼 關注「高可用架構」公眾號