本論文從散布式體系的角度展開針對以后一些機械進修平臺的研討，綜述了這些平臺所應用的架構設計，對這些平臺在通訊和掌握上的瓶頸、容錯性和開辟難度停止剖析和比較，并對散布式機械進修平臺的將來研討任務提出了一些建議。文中的任務由 Murat Demirbas 傳授與他的研討生 Kuo Zhang 和 Salem Alqahtani 配合完成。
機械進修，特殊是深度進修，已在語音辨認、圖象辨認和天然說話處置和近期在推舉及搜刮引擎等范疇上獲得了反動性的勝利。這些技巧在無人駕駛、數字醫療體系、CRM、告白、物聯網等范疇具有很好的運用遠景。固然，是資金引領和驅動了技巧的加快推動，使得我們在近期看到了一些機械進修平臺的推出。
斟酌到練習中所觸及的數據集和模子的范圍非常宏大，機械進修平臺平日是散布式平臺，安排了數十個甚至數百個并交運行的盤算節點對模子做練習。據估量在不遠的未來，數據中間的年夜多半義務都邑是機械進修義務。
我來自于散布式體系研討范疇，是以我們斟酌從散布式體系的角度展開針對這些機械進修平臺的研討，剖析這些平臺在通訊和掌握上的瓶頸。我們還斟酌了這些平臺的容錯性和易編程性。
我們從設計辦法大將機械進修平臺劃分為三個根本種別，分離是：根本數據流、參數 - 辦事器模子和高等數據流。
上面我們將對每類辦法做扼要引見，以 Apache Spark 為例引見根本數據流，以 PMLS（Petuum）為例引見參數辦事器模子，而高等數據流則應用 TensorFlow 和 MXNet 為例。我們比較了上述各平臺的機能并給出了一系列的評價成果。要懂得具體的評價成果，可參考我們的論文。遺憾的是，作為一個小型研討團隊，我們沒法展開年夜范圍的評價。
在本篇博文的最初，我給出了一些結論性要點，并對散布式機械進修平臺的將來研討任務提出了一些建議。對這些散布式機械進修平臺已有必定懂得的讀者，可以直接跳到本文開頭。
Spark
在 Spark 中，盤算被建模為一種有向無環圖（DAG），圖中的每一個極點表現一個 RDD，每條邊表現了 RDD 上的一個操作。RDD 由一系列被切分的對象（Partition）構成，這些被切分的對象在內存中存儲并完成盤算，也會在 Shuffle 進程中溢出（Overflow）到磁盤上
在 DAG 中，一條從極點 A 到 B 的有向邊 E，表現了 RDD B 是在 RDD A 上履行操作 E 的成果。操作分為“轉換”（Transformation）和“舉措（Action）”兩類。轉換操作（例如 map、filter 和 join）運用于某個 RDD 上，轉換操作的輸入是一個新的 RDD。
Spark 用戶將盤算建模為 DAG，該 DAG 表現了在 RDD 上履行的轉換和舉措。DAG 進而被編譯為多個 Stage。每一個 Stage 履行為一系列并交運行的義務（Task），每一個分區（Partition）對應于一個義務。這里，無限（Narrow）的依附關系將有益于盤算的高效履行，而廣泛（Wide）的依附關系則會引入瓶頸，由于如許的依附關系引入了通訊密集的 Shuffle 操作，這打斷了操作流 。
Spark 的散布式履行是經由過程將 DAG Stage 劃分到分歧的盤算節點完成的。上圖清楚地展現了這類“主機（master）- 任務者（worker）”架構。驅動器（Driver）包括有兩個調劑器（Scheduler）組件，即 DAG 調劑器和義務調劑器。調劑器對任務者分派義務，并調和任務者。
Spark 是為通用數據處置而設計的，并不是公用于機械進修義務。要在 Spark 上運轉機械進修義務，可使用 MLlib for Spark。假如采取根本設置的 Spark，那末模子參數存儲在驅動器節點上，在每次迭代后經由過程任務者和驅動器間的通訊更新參數。假如是年夜范圍安排機械進修義務，那末驅動器能夠沒法存儲一切的模子參數，這時候就須要應用 RDD 去包容一切的參數。這將引入年夜量的額定開支，由于為了包容更新的模子參數，須要在每次迭代中創立新的 RDD。更新模子會觸及在機械和磁盤間的數據 Shuffle，進而限制了 Spark 的擴大性。這恰是根本數據流模子（即 DAG）的短板地點。Spark 其實不能很好地支撐機械進修中的迭代運算。
PMLS
PMLS 是專門為機械進修義務而設計的。它引入了稱為“參數 - 辦事器”（Parameter-Server，PS）的籠統，這類籠統是為了支撐迭代密集的練習進程。
PS（在圖中以綠色方框所示）以散布式 key-value 數據表情勢存在于內存中，它是可復制和分片的。每一個節點（node）都是模子中某個分片的主節點（參數空間），并作為其它分片的二級節點或復制節點。如許 PS 在節點數目上的擴大性很好。
PS 節點存儲并更新模子參數，并呼應來自于任務者的要求。任務者從本身的當地 PS 拷貝上要求最新的模子參數，并在分派給它們的數據集分區上履行盤算。
PMLS 也采取了 SSP（Stale Synchronous Parallelism）模子。比擬于 BSP（Bulk Synchronous Parellelism）模子 ，SSP 放寬了每次迭代停止時各個機械需做同步的請求。為完成同步，SSP 許可任務者間存在必定水平上的分歧步，并確保了最快的任務者不會搶先最慢的任務者 s 輪迭代以上。因為處置進程處于誤差所許可的規模內，這類非嚴厲的分歧性模子仍然實用于機械進修。我已經揭橥過一篇博文專門引見這一機制。
TensorFlow
Google 給出了一個基于散布式機械進修平臺的參數辦事器模子，稱為“DistBelief”（此處是我對 DistBelief 論文的綜述）。就我所知，年夜家對 DistBelief 的不滿足的地方重要在于，它在編寫機械進修運用時須要混雜一些底層代碼。Google 想使其任一雇員都可以在無需精曉散布式履行的情形下編寫機械進修代碼。恰是出于統一緣由，Google 對年夜數據處置編寫了 MapReduce 框架。
TensorFlow 是一種設計用于完成這一目的的平臺。它采取了一種更高等的數據流處置范式，個中表現盤算的圖不再須要是 DAG，圖中可以包含環，并支撐可變狀況。我以為 TensorFlow 的設計在必定水平上遭到了 Naiad 設計理念的影響。
TensorFlow 將盤算表現為一個由節點和邊構成的有向圖。節點表現盤算操作或可變狀況（例如 Variable），邊表現節點間通訊的多維數組，這類多維數據稱為“Tensor”。TensorFlow 須要用戶靜態地聲明邏輯盤算圖，并經由過程將圖重寫和劃分到機械上完成散布式盤算。需解釋的是，MXNet，特殊是 DyNet，應用了一種靜態界說的圖。這簡化了編程，并進步了編程的靈巧性。
如上圖所示，在 TensorFlow 中，散布式機械進修練習應用了參數 - 辦事器辦法。當在 TensorFlow 中應用 PS 籠統時，就應用了參數 - 辦事器和數據并行。TensorFlow 宣稱可以完成更龐雜的義務，然則這須要用戶編寫代碼以通向那些未摸索的范疇。
MXNet
MXNet 是一個協同開源項目，源自于在 2015 年涌現的 CXXNet、Minverva 和 Purines 等深度進修項目。相似于 TensorFlow，MXNet 也是一種數據流體系，支撐具有可變狀況的有環盤算圖，并支撐應用參數 - 辦事器模子的練習盤算。異樣，MXNet 也對多個 CPU/GPU 上的數據并行供給了很好的支撐，并可完成模子并行。MXNet 支撐同步的和異步的練習盤算。下圖顯示了 MXNet 的重要組件。個中，運轉時依附引擎剖析盤算進程中的依附關系，對不存在互相依附關系的盤算做并行處置。MXNet 在運轉時依附引擎之上供給了一個中央層，用于盤算圖和內存的優化。
MXNet 應用檢討點機制支撐根本的容錯，供給了對模子的 save 和 load 操作。save 操作將模子參數寫入到檢討點文件，load 操作從檢討點文件中讀取模子參數。
MXNet 應用描寫式編程說話表述盤算為一個有向圖，也支撐應用一些指令式編程去界說 tensor 的盤算和掌握流。MXNet 供給了多種說話（例如 C++、Python、R 和 Scala 等）編寫的客戶端 API。與 TensorFlow 一樣，MXNet 的后臺焦點引擎庫異樣是應用 C++ 編寫的。
部門評價成果
在我們的試驗中，應用了 Amazon EC2 m4.xlarge 實例。每一個實例具有 4 個由 Intel Xeon E5-2676 v3 完成的 vCPU，及 16GB 的內存，EBS 帶寬是 750Mbps。我們對兩種罕見的機械進修義務停止了試驗，它們分離是二分類邏輯斯蒂回歸和應用多層神經收集的圖象分類。本文中只給出了部門成果圖，更多的試驗成果可拜見我們的論文。需指出的是，我們的試驗具有一些局限性。起首，我們應用機械數目不年夜，不克不及測試擴大性。其次，我們也只應用了 CPU 盤算，并未測試 GPU 的應用情形。
該圖展現了各個平臺對邏輯斯蒂回歸的盤算速度。PMLS 和 MXNet 是最快的兩個體系，TensorFlow 速度最慢，而 Spark 介于二者之間。對此，我們剖析以為是由多個緣由招致的。起首，比擬于 Spark 和 TensorFlow，PMLS 是一個輕量級體系，它是采取高機能 C++ 編程說話完成的，而 Spark 是應用運轉在 JVM 上的 Scala 說話編寫的。其次，PMLS 中包括的籠統較少，而 TensorFlow 中則具有過量的籠統。籠統增長了體系的龐雜度，并招致運轉時開支。
該圖展現了 DNN 在各個平臺上的速度。比擬于單層神經收集，當成長到兩層神經收集時，因為須要更多的迭代盤算，Spark 的機能降低。我們將模子參數存儲在 Spark 的驅動器中，由于驅動器可以包容這些參數。然則假如我們應用 RDD 堅持參數，并在每次迭代后做更新，成果能夠會更差。
該圖展現了平臺的 CPU 占用率。Spark 運用看上去具有偏高的 CPU 占用率，這重要來自于序列化的開支。有些后期任務也指出了統一成績。
結論及將來的研討偏向
機械進修和深度進修運用是高度可并行的，然則從并發算法角度看，要做到其實不那末輕易。可以說，參數 - 辦事器辦法最合適于散布式機械進修平臺的練習義務。
斟酌到瓶頸，收集仍然是散布式機械進修運用的瓶頸。比擬于更高等的通用數據流平臺，更主要的是要提出對數據和模子的更好組織和介入機制。應將數據和模子視作一等國民。
另外，還有其它一些身分對平臺具有奧妙的影響。關于 Spark，CPU 開支成為比收集局限更嚴重的瓶頸成績。Spark 應用的編程說話是 Scala 等 JVM 說話，這對 Spark 的機能具有明顯的影響。是以存在著對更好的監控對象和對散布式機械進修平臺機能猜測的需求。近期曾經涌現了一些對象，例如 Ernest 和 CherryPick，它們處理了一些 Spark 數據處置運用上的成績。
關于支撐機械進修的運轉時散布式體系，仍然存在著一些開放成績，例如資本調劑和運轉時機能改良。斟酌到運用的運轉時監控和機能剖析，下一代的散布式機械進修平臺應供給對運轉于平臺上義務的盤算、內存、收集資本的運轉時彈性設置裝備擺設和調劑等才能。
在編程和軟件工程的支撐上，也異樣有一些開放成績。甚么是合適機械進修運用的散布式編程籠統？這些成績還須要做進一步的研討，并對散布式機械進修運用停止磨練和驗證，例如應用特定成績輸出測試 DNN。
參考文獻
論文原文：https://www.cse.buffalo.edu/~demirbas/publications/DistMLplat.pdf
Learning Machine Learning: A beginner's journey，https://muratbuffalo.blogspot.com/2016/12/learning-machine-learning-beginners.html
Paper Review. Petuum: A new platform for distributed machine learning on big data，https://muratbuffalo.blogspot.com/2016/04/petuum-new-platform-for-distributed.html
Google DistBelief paper: Large Scale Distributed Deep Networks，https://muratbuffalo.blogspot.com/2017/01/谷歌-distbelief-paper-large-scale.html
Paper summary: Making sense of Performance in Data Analytics frameworks （NSDI 15），https://muratbuffalo.blogspot.com/2017/05/paper-summary-making-sense-of.html
Naiad: A timely dataflow system，http://muratbuffalo.blogspot.hk/2014/03/naiad-timely-dataflow-system.html
Paper summary: Making sense of Performance in Data Analytics frameworks （NSDI 15），http://muratbuffalo.blogspot.hk/2017/05/paper-summary-making-sense-of.html
https://spark-summit.org/east-2017/events/ernest-efficient-performance-prediction-for-advanced-analytics-on-apache-spark/
https://blog.acolyer.org/2017/05/04/cherrypick-adaptively-unearthing-the-best-cloud-configurations-for-big-data-analytics/
作者引見
Murat Demirbas傳授供職于 University at Buffalo，SUNY 的盤算機迷信與技巧系
