[[200819]]

本論文從分布式系統(tǒng)的角度開展針對當(dāng)前一些機器學(xué)習(xí)平臺的研究，綜述了這些平臺所使用的架構(gòu)設(shè)計，對這些平臺在通信和控制上的瓶頸、容錯性和開發(fā)難度進(jìn)行分析和對比，并對分布式機器學(xué)習(xí)平臺的未來研究工作提出了一些建議。文中的工作由 Murat Demirbas 教授與他的研究生 Kuo Zhang 和 Salem Alqahtani 共同完成。

機器學(xué)習(xí)，特別是深度學(xué)習(xí)，已在語音識別、圖像識別和自然語言處理以及近期在推薦及搜索引擎等領(lǐng)域上取得了革命性的成功。這些技術(shù)在無人駕駛、數(shù)字醫(yī)療系統(tǒng)、CRM、廣告、物聯(lián)網(wǎng)等領(lǐng)域具有很好的應(yīng)用前景。當(dāng)然，是資金***和驅(qū)動了技術(shù)的加速推進(jìn)，使得我們在近期看到了一些機器學(xué)習(xí)平臺的推出。

考慮到訓(xùn)練中所涉及的數(shù)據(jù)集和模型的規(guī)模十分龐大，機器學(xué)習(xí)平臺通常是分布式平臺，部署了數(shù)十個乃至數(shù)百個并行運行的計算節(jié)點對模型做訓(xùn)練。據(jù)估計在不遠(yuǎn)的將來，數(shù)據(jù)中心的大多數(shù)任務(wù)都會是機器學(xué)習(xí)任務(wù)。

我來自于分布式系統(tǒng)研究領(lǐng)域，因此我們考慮從分布式系統(tǒng)的角度開展針對這些機器學(xué)習(xí)平臺的研究，分析這些平臺在通信和控制上的瓶頸。我們還考慮了這些平臺的容錯性和易編程性。

我們從設(shè)計方法上將機器學(xué)習(xí)平臺劃分為三個基本類別，分別是：基本數(shù)據(jù)流、參數(shù) - 服務(wù)器模型和高級數(shù)據(jù)流。

下面我們將對每類方法做簡要介紹，以 Apache Spark 為例介紹基本數(shù)據(jù)流，以 PMLS(Petuum)為例介紹參數(shù)服務(wù)器模型，而高級數(shù)據(jù)流則使用 TensorFlow 和 MXNet 為例。我們對比了上述各平臺的性能并給出了一系列的評估結(jié)果。要了解詳細(xì)的評估結(jié)果，可參考我們的論文。遺憾的是，作為一個小型研究團(tuán)隊，我們無法開展大規(guī)模的評估。

在本篇博文的***，我給出了一些結(jié)論性要點，并對分布式機器學(xué)習(xí)平臺的未來研究工作提出了一些建議。對這些分布式機器學(xué)習(xí)平臺已有一定了解的讀者，可以直接跳到本文結(jié)尾。

Spark

在 Spark 中，計算被建模為一種有向無環(huán)圖(DAG)，圖中的每個頂點表示一個 RDD，每條邊表示了 RDD 上的一個操作。RDD 由一系列被切分的對象(Partition)組成，這些被切分的對象在內(nèi)存中存儲并完成計算，也會在 Shuffle 過程中溢出(Overflow)到磁盤上

在 DAG 中，一條從頂點 A 到 B 的有向邊 E，表示了 RDD B 是在 RDD A 上執(zhí)行操作 E 的結(jié)果。操作分為“轉(zhuǎn)換”(Transformation)和“動作(Action)”兩類。轉(zhuǎn)換操作(例如 map、filter 和 join)應(yīng)用于某個 RDD 上，轉(zhuǎn)換操作的輸出是一個新的 RDD。 

Spark 用戶將計算建模為 DAG，該 DAG 表示了在 RDD 上執(zhí)行的轉(zhuǎn)換和動作。DAG 進(jìn)而被編譯為多個 Stage。每個 Stage 執(zhí)行為一系列并行運行的任務(wù)(Task)，每個分區(qū)(Partition)對應(yīng)于一個任務(wù)。這里，有限(Narrow)的依賴關(guān)系將有利于計算的高效執(zhí)行，而寬泛(Wide)的依賴關(guān)系則會引入瓶頸，因為這樣的依賴關(guān)系引入了通信密集的 Shuffle 操作，這打斷了操作流 。

Spark 的分布式執(zhí)行是通過將 DAG Stage 劃分到不同的計算節(jié)點實現(xiàn)的。上圖清晰地展示了這種“主機(master)- 工作者(worker)”架構(gòu)。驅(qū)動器(Driver)包含有兩個調(diào)度器(Scheduler)組件，即 DAG 調(diào)度器和任務(wù)調(diào)度器。調(diào)度器對工作者分配任務(wù)，并協(xié)調(diào)工作者。

Spark 是為通用數(shù)據(jù)處理而設(shè)計的，并非專用于機器學(xué)習(xí)任務(wù)。要在 Spark 上運行機器學(xué)習(xí)任務(wù)，可以使用 MLlib for Spark。如果采用基本設(shè)置的 Spark，那么模型參數(shù)存儲在驅(qū)動器節(jié)點上，在每次迭代后通過工作者和驅(qū)動器間的通信更新參數(shù)。如果是大規(guī)模部署機器學(xué)習(xí)任務(wù)，那么驅(qū)動器可能無法存儲所有的模型參數(shù)，這時就需要使用 RDD 去容納所有的參數(shù)。這將引入大量的額外開銷，因為為了容納更新的模型參數(shù)，需要在每次迭代中創(chuàng)建新的 RDD。更新模型會涉及在機器和磁盤間的數(shù)據(jù) Shuffle，進(jìn)而限制了 Spark 的擴展性。這正是基本數(shù)據(jù)流模型(即 DAG)的短板所在。Spark 并不能很好地支持機器學(xué)習(xí)中的迭代運算。

PMLS

PMLS 是專門為機器學(xué)習(xí)任務(wù)而設(shè)計的。它引入了稱為“參數(shù) - 服務(wù)器”(Parameter-Server，PS)的抽象，這種抽象是為了支持迭代密集的訓(xùn)練過程。 

PS(在圖中以綠色方框所示)以分布式 key-value 數(shù)據(jù)表形式存在于內(nèi)存中，它是可復(fù)制和分片的。每個節(jié)點(node)都是模型中某個分片的主節(jié)點(參數(shù)空間)，并作為其它分片的二級節(jié)點或復(fù)制節(jié)點。這樣 PS 在節(jié)點數(shù)量上的擴展性很好。

PS 節(jié)點存儲并更新模型參數(shù)，并響應(yīng)來自于工作者的請求。工作者從自己的本地 PS 拷貝上請求***的模型參數(shù)，并在分配給它們的數(shù)據(jù)集分區(qū)上執(zhí)行計算。

PMLS 也采用了 SSP(Stale Synchronous Parallelism)模型。相比于 BSP(Bulk Synchronous Parellelism)模型 ，SSP 放寬了每一次迭代結(jié)束時各個機器需做同步的要求。為實現(xiàn)同步，SSP 允許工作者間存在一定程度上的不同步，并確保了最快的工作者不會領(lǐng)先最慢的工作者 s 輪迭代以上。由于處理過程處于誤差所允許的范圍內(nèi)，這種非嚴(yán)格的一致性模型依然適用于機器學(xué)習(xí)。我曾經(jīng)發(fā)表過一篇博文專門介紹這一機制。

TensorFlow

Google 給出了一個基于分布式機器學(xué)習(xí)平臺的參數(shù)服務(wù)器模型，稱為“DistBelief”(此處是我對 DistBelief 論文的綜述)。就我所知，大家對 DistBelief 的不滿意之處主要在于，它在編寫機器學(xué)習(xí)應(yīng)用時需要混合一些底層代碼。Google 想使其任一雇員都可以在無需精通分布式執(zhí)行的情況下編寫機器學(xué)習(xí)代碼。正是出于同一原因，Google 對大數(shù)據(jù)處理編寫了 MapReduce 框架。

TensorFlow 是一種設(shè)計用于實現(xiàn)這一目標(biāo)的平臺。它采用了一種更高級的數(shù)據(jù)流處理范式，其中表示計算的圖不再需要是 DAG，圖中可以包括環(huán)，并支持可變狀態(tài)。我認(rèn)為 TensorFlow 的設(shè)計在一定程度上受到了 Naiad 設(shè)計理念的影響。

TensorFlow 將計算表示為一個由節(jié)點和邊組成的有向圖。節(jié)點表示計算操作或可變狀態(tài)(例如 Variable)，邊表示節(jié)點間通信的多維數(shù)組，這種多維數(shù)據(jù)稱為“Tensor”。TensorFlow 需要用戶靜態(tài)地聲明邏輯計算圖，并通過將圖重寫和劃分到機器上實現(xiàn)分布式計算。需說明的是，MXNet，特別是 DyNet，使用了一種動態(tài)定義的圖。這簡化了編程，并提高了編程的靈活性。 

如上圖所示，在 TensorFlow 中，分布式機器學(xué)習(xí)訓(xùn)練使用了參數(shù) - 服務(wù)器方法。當(dāng)在 TensorFlow 中使用 PS 抽象時，就使用了參數(shù) - 服務(wù)器和數(shù)據(jù)并行。TensorFlow 聲稱可以完成更復(fù)雜的任務(wù)，但是這需要用戶編寫代碼以通向那些未探索的領(lǐng)域。

MXNet

MXNet 是一個協(xié)同開源項目，源自于在 2015 年出現(xiàn)的 CXXNet、Minverva 和 Purines 等深度學(xué)習(xí)項目。類似于 TensorFlow，MXNet 也是一種數(shù)據(jù)流系統(tǒng)，支持具有可變狀態(tài)的有環(huán)計算圖，并支持使用參數(shù) - 服務(wù)器模型的訓(xùn)練計算。同樣，MXNet 也對多個 CPU/GPU 上的數(shù)據(jù)并行提供了很好的支持，并可實現(xiàn)模型并行。MXNet 支持同步的和異步的訓(xùn)練計算。下圖顯示了 MXNet 的主要組件。其中，運行時依賴引擎分析計算過程中的依賴關(guān)系，對不存在相互依賴關(guān)系的計算做并行處理。MXNet 在運行時依賴引擎之上提供了一個中間層，用于計算圖和內(nèi)存的優(yōu)化。

MXNet 使用檢查點機制支持基本的容錯，提供了對模型的 save 和 load 操作。save 操作將模型參數(shù)寫入到檢查點文件，load 操作從檢查點文件中讀取模型參數(shù)。

MXNet 使用描述式編程語言表述計算為一個有向圖，也支持使用一些指令式編程去定義 tensor 的計算和控制流。MXNet 提供了多種語言(例如 C++、Python、R 和 Scala 等)編寫的客戶端 API。與 TensorFlow 一樣，MXNet 的后臺核心引擎庫同樣是使用 C++ 編寫的。

部分評估結(jié)果

在我們的實驗中，使用了 Amazon EC2 m4.xlarge 實例。每個實例具有 4 個由 Intel Xeon E5-2676 v3 實現(xiàn)的 vCPU，及 16GB 的內(nèi)存，EBS 帶寬是 750Mbps。我們對兩種常見的機器學(xué)習(xí)任務(wù)進(jìn)行了實驗，它們分別是二分類邏輯斯蒂回歸和使用多層神經(jīng)網(wǎng)絡(luò)的圖像分類。本文中只給出了部分結(jié)果圖，更多的實驗結(jié)果可參見我們的論文。需指出的是，我們的實驗具有一些局限性。首先，我們使用機器數(shù)量不大，不能測試擴展性。其次，我們也只使用了 CPU 計算，并未測試 GPU 的使用情況。

該圖展示了各個平臺對邏輯斯蒂回歸的計算速度。PMLS 和 MXNet 是最快的兩個系統(tǒng)，TensorFlow 速度最慢，而 Spark 介于兩者之間。 對此，我們分析認(rèn)為是由多個原因?qū)е碌?。首先，相比?Spark 和 TensorFlow，PMLS 是一個輕量級系統(tǒng)，它是采用高性能 C++ 編程語言實現(xiàn)的，而 Spark 是使用運行在 JVM 上的 Scala 語言編寫的。其次，PMLS 中包含的抽象較少，而 TensorFlow 中則具有過多的抽象。抽象增加了系統(tǒng)的復(fù)雜度，并導(dǎo)致運行時開銷。

該圖展示了 DNN 在各個平臺上的速度。相比于單層神經(jīng)網(wǎng)絡(luò)，當(dāng)發(fā)展到兩層神經(jīng)網(wǎng)絡(luò)時，由于需要更多的迭代計算，Spark 的性能下降。我們將模型參數(shù)存儲在 Spark 的驅(qū)動器中，因為驅(qū)動器可以容納這些參數(shù)。但是如果我們使用 RDD 保持參數(shù)，并在每次迭代后做更新，結(jié)果可能會更差。

該圖展示了平臺的 CPU 占用率。Spark 應(yīng)用看上去具有偏高的 CPU 占用率，這主要來自于序列化的開銷。有些前期工作也指出了同一問題。

結(jié)論及未來的研究方向

機器學(xué)習(xí)和深度學(xué)習(xí)應(yīng)用是高度可并行的，但是從并發(fā)算法角度看，要做到并不那么容易?？梢哉f，參數(shù) - 服務(wù)器方法最適合于分布式機器學(xué)習(xí)平臺的訓(xùn)練任務(wù)。

考慮到瓶頸，網(wǎng)絡(luò)依然是分布式機器學(xué)習(xí)應(yīng)用的瓶頸。相比于更高級的通用數(shù)據(jù)流平臺，更重要的是要提出對數(shù)據(jù)和模型的更好組織和參與機制。應(yīng)將數(shù)據(jù)和模型視作一等公民。

此外，還有其它一些因素對平臺具有微妙的影響。對于 Spark，CPU 開銷成為比網(wǎng)絡(luò)局限更嚴(yán)重的瓶頸問題。Spark 使用的編程語言是 Scala 等 JVM 語言，這對 Spark 的性能具有顯著的影響。因此存在著對更好的監(jiān)控工具以及對分布式機器學(xué)習(xí)平臺性能預(yù)測的需求。近期已經(jīng)出現(xiàn)了一些工具，例如 Ernest 和 CherryPick，它們解決了一些 Spark 數(shù)據(jù)處理應(yīng)用上的問題。

對于支持機器學(xué)習(xí)的運行時分布式系統(tǒng)，依然存在著一些開放問題，例如資源調(diào)度和運行時性能改進(jìn)?？紤]到應(yīng)用的運行時監(jiān)控和性能分析，下一代的分布式機器學(xué)習(xí)平臺應(yīng)提供對運行于平臺上任務(wù)的計算、內(nèi)存、網(wǎng)絡(luò)資源的運行時彈性配置和調(diào)度等能力。

在編程和軟件工程的支持上，也同樣有一些開放問題。什么是適合機器學(xué)習(xí)應(yīng)用的分布式編程抽象?這些問題還需要做進(jìn)一步的研究，并對分布式機器學(xué)習(xí)應(yīng)用進(jìn)行檢驗和驗證，例如使用特定問題輸入測試 DNN。