轉(zhuǎn)自：微信公眾號 數(shù)據(jù)極客
在大規(guī)模數(shù)據(jù)上跑機器學(xué)習(xí)任務(wù)是過去十多年內(nèi)系統(tǒng)架構(gòu)師面臨的主要挑戰(zhàn)之一，許多模型和抽象先后用于這一任務(wù)。從早期的MPI，到后來的Hadoop，乃至于目前使用較多的Spark，都曾被廣泛應(yīng)用于大規(guī)模機器學(xué)習(xí)處理任務(wù)。John Langford曾經(jīng)在他的博客(機器學(xué)習(xí)領(lǐng)域最好的博客之一)上總結(jié)和對比了主流的分布式機器學(xué)習(xí)框架的抽象[1]：
MPI Gradient Aggregation：主要缺點是批任務(wù)求解器的速度不高，另外是MPI本身的問題無法支撐大規(guī)模數(shù)據(jù)。
MapReduce：解決了MPI無法支撐大數(shù)據(jù)的問題，但無法改進批處理求解器的訓(xùn)練性能，并且還引入了新的問題，包括迭代式計算的低效，節(jié)點之間通信低效。
基于圖的抽象：由CMU推出的GraphLab是這方面的佼佼者，目前已經(jīng)成立了Dato公司專門推廣基于圖的大規(guī)模機器學(xué)習(xí)系統(tǒng)。用圖來做抽象可以解決許多機器學(xué)習(xí)問題，但仍然有許多問題無法很好高效求解，比如深度學(xué)習(xí)中的多層結(jié)構(gòu)。
Parameter Server參數(shù)服務(wù)器：跟基于圖的方法主要區(qū)別在于把模型參數(shù)存儲和更新上升為主要組件，并且采用了異步機制提升處理能力，這是本文主要介紹的模型。
AllReduce：AllReduce本身就是MPI的原語，這其實是最顯然和直接的分布式機器學(xué)習(xí)抽象，因為大部分算法的結(jié)構(gòu)都是分布數(shù)據(jù)，在每個子集上面算出一些局部統(tǒng)計量，然后整合出全局統(tǒng)計量，并且再分配給各個節(jié)點去進行下一輪的迭代，這樣一個過程就是AllReduce。AllReduce跟MapReduce有類似，但后者采用的是面向通用任務(wù)處理的多階段執(zhí)行任務(wù)的方式，而AllReduce則讓一個程序在必要的時候占領(lǐng)一臺機器，并且在所有迭代的時候一直跑到底，來防止重新分配資源的開銷，這更加適合于機器學(xué)習(xí)的任務(wù)處理。AllReduce跟參數(shù)服務(wù)器都會是機器學(xué)習(xí)算法框架的重要抽象，DMLC組陳天奇開發(fā)的Rabit框架[2]是AllReduce模型的良好實現(xiàn)之一，其余的當(dāng)然可以借助于vw這樣的系統(tǒng)，它們都能直接運行在Hadoop上。基于同步的AllReduce模型并不是本文討論的重點，我們只需要知道它很重要，很多算法離不了。

機器學(xué)習(xí)算法和計算機領(lǐng)域的其他算法相比，有自己的一些獨特特點。例如：迭代性，模型的更新并非一次完成，需要循環(huán)迭代多次；容錯性，即使在每個循環(huán)中產(chǎn)生一些錯誤，模型最終的收斂不受影響；參數(shù)收斂的非均勻性，模型中有些參數(shù)經(jīng)過幾個循環(huán)便不再改變，其他參數(shù)需要很長時間收斂。這些特點決定了機器學(xué)習(xí)系統(tǒng)的設(shè)計和其他計算系統(tǒng)的設(shè)計有很大不同，因此理想中的分布式機器學(xué)習(xí)任務(wù)，并不能隨著機器的增加而能力線性提升，因為大量資源都會浪費在通訊，等待，協(xié)調(diào)，這些時間可能會占據(jù)大部分比例。參數(shù)服務(wù)器就是被提出來專門用于大規(guī)模最優(yōu)化處理的框架，它特定用于這種需求：大規(guī)模的訓(xùn)練數(shù)據(jù)，比如TB甚至PB級別的；大規(guī)模的模型參數(shù)，在大規(guī)模的優(yōu)化框架中，常常會有數(shù)十億乃至千億級別的參數(shù)需要估計。因此，在設(shè)計面臨這種挑戰(zhàn)的系統(tǒng)時，比如大規(guī)模深度學(xué)習(xí)系統(tǒng)，大規(guī)模Logistic Regression系統(tǒng)，大規(guī)模主題模型，大規(guī)模矩陣分解等等依賴于SGD或者L-BFGS最優(yōu)化的算法，需要解決頻繁訪問修改模型參數(shù)時所需消耗的巨大帶寬，以及如何提高并行度，減少同步等待造成的延遲，還有容錯等挑戰(zhàn)。

參數(shù)服務(wù)器的概念最早來自Alex Smola于2010年提出的并行LDA的框架[4]。它通過采用一個分布式的Memcached作為存放參數(shù)的存儲，這樣就提供了有效的機制用于在分布式系統(tǒng)不同的Worker節(jié)點之間同步模型參數(shù)，而每個Worker只需要保存它計算時所依賴的一小部分參數(shù)即可。當(dāng)然，這里存放參數(shù)的存儲跟做OLTP應(yīng)用中的Key-Value抽象有所不同，因為以Key-Value為單元進行頻繁的參數(shù)數(shù)據(jù)交互會導(dǎo)致過高的通信開銷，因此參數(shù)服務(wù)器通常采用數(shù)學(xué)封裝來進行參數(shù)同步，比如向量，張量，矩陣的行列等。

上圖的sampler是并行LDA里的組件，可類比為通用參數(shù)服務(wù)器框架里的計算單元。Smola提出的模型是最早的參數(shù)服務(wù)器抽象，隨后出現(xiàn)了許多改進，最出名的應(yīng)當(dāng)是Google的跨界高人Jeff Dean 2012年進一步提出了第一代Google大腦的解決方案DistBelief[5]，主要用于超大規(guī)模深度學(xué)習(xí)網(wǎng)絡(luò)的訓(xùn)練。DistBelief將巨大的深度學(xué)習(xí)模型分布存儲在全局的參數(shù)服務(wù)器中，計算節(jié)點通過參數(shù)服務(wù)器進行信息傳遞，很好地解決了SGD和L-BFGS算法的分布式訓(xùn)練問題。由于SGD和L-BFGS是機器學(xué)習(xí)的普遍性優(yōu)化問題，因此盡管DistBelief是作為深度學(xué)習(xí)的系統(tǒng)框架而提出，但DistBelief的核心結(jié)構(gòu)卻可以應(yīng)用到多種普通機器學(xué)習(xí)手段中。相比最早的參數(shù)服務(wù)器模型，DistBelief把該模型擴展成為更加通用和靈活的框架，豆瓣的Paracel[3]正是參考DistBelief的直接實現(xiàn)，先來看看Paracel和DistBelief模型：

圖中是分布式異步SGD架構(gòu)流程圖，運行時，需要把訓(xùn)練數(shù)據(jù)分為多個子集，然后在每個子集上運行模型的多個副本，模型通過集中式的參數(shù)服務(wù)器通信，參數(shù)服務(wù)器存放了模型的全部參數(shù)和狀態(tài)。異步體現(xiàn)在兩方面：模型的副本獨立運行；參數(shù)服務(wù)器的分片也各自獨立運行。DistBelief沒有過多談?wù)撓到y(tǒng)實現(xiàn)，從Paracel里我們可以看到具體的工程實現(xiàn)：總體上Paracel實現(xiàn)非常簡單，參數(shù)服務(wù)器直接采用內(nèi)存hashtable，并封裝了對分網(wǎng)絡(luò)，圖，稀疏矩陣，稠密矩陣等數(shù)據(jù)格式用于參數(shù)同步。Paracel解決的另一問題是straggler問題：由于一些軟硬件的原因，節(jié)點的計算能力往往不盡相同。對于迭代問題來說，每一輪結(jié)束時算得快的節(jié)點都需等待算得慢的節(jié)點算完，再進行下一輪迭代。這種等待在節(jié)點數(shù)增多時將變得尤為明顯，從而拖慢整體的性能。Paracel放寬了“每個迭代步都等待”這個約束：當(dāng)在一輪迭代結(jié)束時，算得快的節(jié)點可以繼續(xù)下一輪迭代，但不能比最慢的節(jié)點領(lǐng)先參數(shù)s個迭代步。當(dāng)領(lǐng)先超過s個迭代步，Paracel才會強制進行等待。這樣異步的控制方式既從整體上省去了等待時間，也能間接地幫助慢的節(jié)點趕上。從優(yōu)化問題的角度來看，雖然單迭代步收斂得慢了，然而每個迭代步的時間開銷變少了，總體上收斂也就變快了。這種做法又叫Staleness Synchronous Parallel (SSP)，基本思想是允許各機器以不同步調(diào)對模型進行更新，但是加一個限制，使得最快的機器的進度和最慢機器的進度之差不要太大。這樣做的好處是：既減輕慢的機器拖整個系統(tǒng)的后腿，又能保證模型的最終收斂。

SSP是相對于BSP(Bulk Synchronous Parallel)來說的，BSP是上世紀(jì)八十年代就提出的，它要求算法在每一次迭代結(jié)束后都要同步等待，因此會因為最慢的機器拖慢整個系統(tǒng)。BSP在絕大部分已有的分布式機器學(xué)習(xí)和數(shù)據(jù)挖掘框架框架中都在使用，例如Spark MLBase，Google Pregel，Apache Hama等。

SSP是由CMU Eric Xing的Petuum項目組提出的[6]，Paracel引入SSP使得豆瓣的參數(shù)服務(wù)器方案工程上更加成熟，在Paracel內(nèi)部，SSP的等待通過調(diào)用MPI來實現(xiàn)。關(guān)于一致性收斂和Petuum，在下邊還會有介紹。關(guān)于參數(shù)服務(wù)器，另一個重要的方面是容錯設(shè)計。在幾十臺機器的集群上運行，這也許并不是一個問題，但是如果在有上千臺機器的集群上運行任務(wù)，節(jié)點發(fā)生任務(wù)失敗的概率就會大很多，如果缺乏容錯設(shè)計，就會導(dǎo)致任務(wù)重啟，從而浪費大量時間。不過，在Paracel的代碼里并沒有找到相關(guān)的處理邏輯，通常容錯處理需要借助于Checkpoint來做快照，這樣任務(wù)重啟時無需從頭進行，比如DistBelief就是這樣處理。跟豆瓣的工程師咨詢后已經(jīng)確認，在開源版本的Paracel里確實還沒有相關(guān)設(shè)計。

上面講述了不少參數(shù)服務(wù)器的背景和系統(tǒng)結(jié)構(gòu)，那么為什么參數(shù)服務(wù)器能夠具備更好的性能呢？仍以SGD為例說明：在傳統(tǒng)同步SGD中，如果一臺機器失效，整個訓(xùn)練過程將會延時；但是對于異步SGD來講，如果某個模型副本的一臺機器失效，其他模型副本仍然繼續(xù)處理樣本并更新參數(shù)服務(wù)器中的模型參數(shù)，因此異步SGD具備更好的魯棒性。此外，多種異步處理形式給最優(yōu)化過程帶來進一步的隨機性：模型實例最可能是使用一個稍微過時的參數(shù)來計算梯度，因為這時其他的副本可能已經(jīng)更新了參數(shù)服務(wù)器上的參數(shù)。除此之外還有其他隨機的來源，因為參數(shù)服務(wù)器組的每臺機器是行為獨立的，所以無法保證在給定時間點上，每個節(jié)點的參數(shù)被更新的次數(shù)相同，或者以同樣的順序被更新。更進一步，因為模型副本使用不同的線程來獲取參數(shù)和推送梯度值，故在同一時間戳上，單個副本內(nèi)的參數(shù)將有額外的稍微不一致的現(xiàn)象。盡管對于非凸問題的這些操作的安全性缺乏理論基礎(chǔ)，但是在實踐中，這種放松一致性要求的做法是相當(dāng)有效的。傳統(tǒng)同步SGD的最優(yōu)化過程，每次迭代選取的方向是由全部訓(xùn)練數(shù)據(jù)決定，或者由隨機選定的一小部分訓(xùn)練集指定(mini-batch)。而異步的做法由于上述更多的隨機性則會同時在很多方向上由不同的mini-batch選定不同梯度方向，這就好比整個最優(yōu)化過程是以一個區(qū)域為單位進行的，而區(qū)域內(nèi)的點代表不同SGD的過程，因此這種并行化的工作會帶來性能上的提升。

豆瓣的Paracel并不是唯一一種開源的參數(shù)服務(wù)器，這里繼續(xù)介紹另外一個重要項目，來自Alex Smola的高徒——李沐設(shè)計的參數(shù)服務(wù)器[7]。這個項目在早期擁有一個獨立域名http://parameterserver.org，后來因為李沐和陳天奇等國內(nèi)英才成立的DMLC深度學(xué)習(xí)項目組，之前的項目也進行了重構(gòu)因此轉(zhuǎn)移到[7]所在的地址，而項目的背景介紹則在[8]和[9]。從架構(gòu)上來說，ps-lite跟Paracel并沒有什么不同，作為參數(shù)服務(wù)器，都需要一個全局分布式的key-value用來存儲算法的模型或參數(shù)。當(dāng)計算節(jié)點需要某個參數(shù)的時候，可以從參數(shù)服務(wù)器上讀取。用戶可定義不同的函數(shù)在參數(shù)服務(wù)器端對參數(shù)進行更新、過濾等操作。在大部分情況下，計算節(jié)點之間的通信都是通過參數(shù)服務(wù)器進行。圖中W代表計算節(jié)點，X代表參數(shù)服務(wù)器節(jié)點。

根據(jù)作者的宣傳，ps-lite應(yīng)當(dāng)屬于第三代參數(shù)服務(wù)器，就是提供了更加通用的設(shè)計，在架構(gòu)上包含一個Server Group和若干個Worker Group：
Server Group用來做參數(shù)服務(wù)器，每個Server Node存放一個參數(shù)分片，由Server Manager管理整個Server Group，維持整個Server Group的元數(shù)據(jù)的一致性視圖，以及參數(shù)分片情況。
每個Worker Group運行一個應(yīng)用，Worker Node只跟Server Node通信用來更新參數(shù)，Worker Node之間沒有任何交互。每個Worker Group內(nèi)有一個調(diào)度器，負責(zé)給Worker Nodes分配任務(wù)以及監(jiān)控，如果有Worker Node掛掉或者新加入，調(diào)度器負責(zé)重新調(diào)度剩余的任務(wù)。

跟Paracel不同，ps-lite提供了多種數(shù)據(jù)一致性選擇：
Sequential：這種情況下，所有任務(wù)順序進行，因此數(shù)據(jù)嚴(yán)格一致，不會出現(xiàn)不同副本看到的數(shù)據(jù)有不同的情況，因此實際上跟前文介紹的BSP是等價的。
Eventual：這種情況下，所有任務(wù)并行執(zhí)行，因此擁有最大的隨機性。Eventual只適用于對于數(shù)據(jù)一致沒有要求，非常健壯的算法，比如SGD。
Bounded Delay：每個任務(wù)需要設(shè)置最大超時時間，在該時間之前如果有任務(wù)未結(jié)束，那么新任務(wù)將會等待。Bounded Delay類似于上面的SSP，只不過這是用時間而SSP則是用迭代次數(shù)。
在容錯設(shè)計方面，ps-lite通過給參數(shù)服務(wù)器引入多副本機制來提供：整個模型參數(shù)按照一致哈希分片存儲，在默認情況下，采用鏈?zhǔn)綇?fù)制確保參數(shù)多副本，如下圖所示：

鏈?zhǔn)綇?fù)制會導(dǎo)致網(wǎng)絡(luò)帶寬占用增加數(shù)倍，而ps-lite還提供了另外一種容錯設(shè)計：先聚合再復(fù)制。聚合的意思是在機器學(xué)習(xí)算法中，參數(shù)在很多時候是可以累加的，比如梯度。采用先聚合再復(fù)制的方式，可以降低網(wǎng)絡(luò)帶寬占用。

根據(jù)作者在Logistic Regression上的測試，ps-lite可以比傳統(tǒng)實現(xiàn)所占用時間縮短1到兩個數(shù)量級。

ps-lite目前在DMLC項目中處于核心基礎(chǔ)地位，因為大部分的分布式機器學(xué)習(xí)算法都會基于它來進行，包括DMLC最新推出的熱門深度學(xué)習(xí)框架MXNet。ps-lite的代碼整體非常簡單，便于修改和移植，而且DMLC項目組目前也給它增加了資源管理器的集成，使得Yarn能夠來管理參數(shù)服務(wù)器的資源分配。
下面再來介紹由CMU機器學(xué)習(xí)系領(lǐng)頭人Eric Xing帶領(lǐng)的小組推出的參數(shù)服務(wù)器Petuum。Eric Xing和Smola和李沐同來自CMU，但卻做出了兩份獨立的工作，個中緣由不在本文八卦之行列，畢竟跟雙方都不熟悉。因此這里只談?wù)摷夹g(shù)。事實上，Petuum是最早開源的參數(shù)服務(wù)器，其目的都是在DistBelief之后期望推出通用的參數(shù)服務(wù)器設(shè)計。跟Paracel和ps-lite一樣，Petuum也采用C++開發(fā)，Eric Xing據(jù)此給出的解釋是目前Petuum仍然處于原型階段，是學(xué)術(shù)產(chǎn)品，所以沒有考慮通用的語言如Java等。Petuum目前分成幾個子項目，分別包含了參數(shù)服務(wù)器Bosen，以及基于Bosen和Caffe的分布式深度學(xué)習(xí)系統(tǒng)Poseidon，后者不是本文介紹的范圍。Bosen的系統(tǒng)設(shè)計建立于機器學(xué)習(xí)的特征之上，目前包含兩個主要模塊：Key Value Store和Scheduler，一致性協(xié)議是上文介紹過的SSP。通過調(diào)節(jié)SSP的staleness參數(shù)，SSP可以轉(zhuǎn)化成數(shù)據(jù)流系統(tǒng)常用的BSP（Bulk Synchronous Parallel) 協(xié)議或者早期機器學(xué)習(xí)系統(tǒng)（如Yahoo LDA）使用的ASP(Asynchronous Parallel)。Scheduler用于模型并行，它提供的編程接口主要包含三個操作：
Schedule: 調(diào)度節(jié)點根據(jù)模型參數(shù)的相互依賴性和收斂的不均勻性，自動選擇一個待更新的參數(shù)子集。
Push: 調(diào)度節(jié)點令計算節(jié)點并行地為選好的參數(shù)計算Update。
Pull：調(diào)度節(jié)點從計算節(jié)點收集Update，并更新參數(shù)。

Petuum/Bosen的架構(gòu)如上圖所示。跟其他的參數(shù)服務(wù)器并沒有大的差別，但模塊化設(shè)計更加良好，比如一致性模型，調(diào)度這些重要功能都放入單獨組件。比較遺憾的是Petuum/Bosen也沒有在容錯設(shè)計上有所考慮，這跟Eric Xing宣稱的原型系統(tǒng)也相吻合，因此跟Paracel類似，Bosen目前主要適用于幾十臺機器的集群，在更大集群上處理有風(fēng)險。

從代碼上來看，Bosen的結(jié)構(gòu)相比Paracel和ps-lite都要復(fù)雜不少，主要原因是Bosen在所有的組件，包括存儲，調(diào)度，還有Worker上面都是多線程實現(xiàn)，調(diào)度器的設(shè)計更為復(fù)雜，因為對機器學(xué)習(xí)模型參數(shù)的更新進行細粒度的調(diào)度，能根據(jù)參數(shù)的優(yōu)先級自動調(diào)整更新次序，并根據(jù)參數(shù)的相關(guān)性防止不安全的并行。我們來進一步分析功能：

如上圖所示，在Bosen中，SSP跟參數(shù)服務(wù)器封裝在一起，稱為SSPTable，供多個Worker節(jié)點以類似分布式共享內(nèi)存的方式訪問，讓W(xué)orker節(jié)點操作SSPTable跟操作本地內(nèi)存一樣。Worker通過SSPTable更新參數(shù)服務(wù)器的同時，SSPTable同時更新SSP一致性控制器內(nèi)部的設(shè)置。SSPTable是參數(shù)服務(wù)器節(jié)點運行的主體結(jié)構(gòu)，Bosen在每個參數(shù)服務(wù)器節(jié)點上可以啟動多個SSPTable，這是它顯著區(qū)別于ps-lite和Paracel的地方之一。之所以這樣設(shè)計，是因為Petuum項目需要根據(jù)不同的算法來配置并行任務(wù)。例如，Petuum的示例程序中，運行深度學(xué)習(xí)DNN算法，就配置了神經(jīng)網(wǎng)絡(luò)層數(shù)兩倍的SSPTable數(shù)量，而其他一些算法比如隨機森林，矩陣分解，只配置了2個SSPTable。究竟應(yīng)當(dāng)如何配置并沒有從Petuum的文檔和代碼中找到說明，因為本文只是介紹性文字，故而這里不去深究，在使用中需要注意這一點。SSPTable內(nèi)部運行若干Background線程，來運行SSP控制邏輯，線程的數(shù)目跟SSPTable數(shù)保持一致。Bosen實現(xiàn)了多種SSP模型，默認的SSP實現(xiàn)需要根據(jù)客戶端(運行在參數(shù)服務(wù)器節(jié)點)匯報的時鐘計數(shù)來決策，時鐘在這里代表機器學(xué)習(xí)算法的計算單元，比如一次迭代。其他還有SSP Push和SSP Aggregation，前者只是在SSP基礎(chǔ)之上提供額外的接口用于異步推送SSPTable的指定行數(shù)據(jù)，后者則修改了SSP的實現(xiàn)原語，如何使用這兩個模型目前還沒找到正式說明，使用SSP應(yīng)當(dāng)基本可以滿足全部需求。

接下來看看Bosen的調(diào)度器設(shè)計，這是Petuum項目區(qū)別于其他參數(shù)服務(wù)器的主要組件之一。它的主要思想是在并行的同時避免模型出錯，這個概念叫做Structure-Aware Parallelization(SAP)[11]，在Petuum項目里叫做Strads。

Strads系統(tǒng)由若干Master節(jié)點，若干Worker節(jié)點和一個Cordinator節(jié)點構(gòu)成。調(diào)度流程如下：Master執(zhí)行Schedule接口，作用是選出可以并行的參數(shù)子集，這個過程可能需要Strads從參數(shù)服務(wù)器讀取參數(shù)數(shù)據(jù)。用來更新這些參數(shù)的任務(wù)被Cordinator通過Push接口下發(fā)到Worker節(jié)點進行計算，參數(shù)服務(wù)器通過Pull接口從Worker節(jié)點接收參數(shù)然后更新存儲。為了更有效地執(zhí)行任務(wù)，Strads把調(diào)度流程流水線化，Master無需等待Worker的結(jié)果就提前把任務(wù)準(zhǔn)備好，Cordinator依次把待執(zhí)行的任務(wù)下發(fā)到Worker。在決定如何并行從而避免模型出錯這方面，并不存在一個通用的做法，因為這跟不同的模型有很大關(guān)系，因此Strads把這個工作留給不同算法來進行，例如對主題模型，Lasso，矩陣分解，都提供了相應(yīng)的實現(xiàn)。

Eric Xing把他眼中的若干分布式機器學(xué)習(xí)模型的適用場景做了個概要圖，可以看到，Petuum/Bosen的定位在于在較小集群上運行，但同時需要大量參數(shù)(百億，千億級)的場景，而DistBelief和ps-lite這些工作是運行在大規(guī)模集群上的參數(shù)服務(wù)器方案。至于為何是這樣的結(jié)論（更大量參數(shù)），從架構(gòu)上還沒有得出很明顯的結(jié)論，只能說Petuum項目相比其他參數(shù)服務(wù)器，對于更廣泛的機器學(xué)習(xí)算法上考慮更多，然而由于缺乏容錯機制，所以最好還是運行在獨立中小集群之上(幾十臺服務(wù)器規(guī)模)。

上面介紹了3種最知名的開源參數(shù)服務(wù)器，隨著這種模型為更多人所接受，一些公司也推出了相關(guān)的框架和產(chǎn)品，例如微軟研究院[12]和英特爾[13]。下面分別簡要介紹一下：

微軟研究院的參數(shù)服務(wù)器是跟它在15年底開源的機器學(xué)習(xí)工具包DMTK一起發(fā)布的，DMTK最知名的項目就是老師木主導(dǎo)的LightLDA，這是一個超大規(guī)模主題模型(百萬主題級別)，在最初的版本中，LightLDA正是基于Petuum來開發(fā)的。DMTK內(nèi)部的參數(shù)服務(wù)器項目叫做Multiverso，在架構(gòu)上比較簡單，由于是來自研究院的項目，因此對大集群，容錯等方面考慮得并不多。一致性模型方面，Multiverso包含BSP，SSP，以及ASP(Asynchronous Parallel)，ASP就是指全異步，所有的任務(wù)相互沒有等待。在一致性模型的選擇上，Multiverso跟ps-lite類似。

英特爾的DistML是對Spark的通用機器學(xué)習(xí)庫MLLib的一個補充，它跟Spark和Hadoop的關(guān)系如下圖所展示。這是本文談?wù)摰侥壳盀橹沟谝粋€JVM上的實現(xiàn)。DistML利用Spark RDD任務(wù)來運行Worker，在Spark之外新增了兩個組件，一個是Databus用于參數(shù)傳送，另一個就是參數(shù)服務(wù)器本身，基于Actor實現(xiàn)。盡管Spark RDD任務(wù)具備容錯功能，但參數(shù)服務(wù)器本身并沒有類似ps-lite那樣的多副本機制。由于Spark RDD的限制，DistML的參數(shù)更新只能在一次迭代完成后進行，因此這并不是嚴(yán)格意義上的參數(shù)服務(wù)器方案，所以也就談不上采用何種一致性模型，但DistML第一次在Spark集群上增加了類似參數(shù)服務(wù)器的模型抽象，在網(wǎng)上看到有人用它嘗試過4億參數(shù)和200億維度的Logistic Regression，從這個角度來說，DistML也是滿足了許多依賴Spark進行算法開發(fā)的人的需求。

除了以上這些參數(shù)服務(wù)器，Spark社區(qū)本身也有支持參數(shù)服務(wù)器的計劃[14]，從issue的建議來看，Spark計劃采用可選的BSP和SSP作為一致性模型，容錯設(shè)計采用Checkpoint定期刷盤。由于是真正的參數(shù)服務(wù)器模型，跟Spark RDD本質(zhì)上的BSP有沖突，因此這需要對Spark核心的修改，目前的實現(xiàn)在[15]，也許在Spark上使用參數(shù)服務(wù)器應(yīng)當(dāng)不會很久了。

在商業(yè)化方面，國內(nèi)的百度，阿里，今日頭條是已知大規(guī)模采用參數(shù)服務(wù)器的公司。阿里的材料可以從QCon 2015上海的演講中獲得：

從上圖顯示，阿里的方案采用HBase作為參數(shù)服務(wù)器，Worker則采用內(nèi)部的數(shù)據(jù)流式計算引擎，并且只實現(xiàn)了DistBelief里的異步SGD—Downpour SGD，因此，這個架構(gòu)主要是服務(wù)在線實時計算，而不是通用的參數(shù)服務(wù)器。另據(jù)稱今日頭條的參數(shù)服務(wù)器集群已達到4000臺規(guī)模，百度也是拿C++自行研發(fā)專用集群，這些公司并沒有采用開源方案，主要原因應(yīng)當(dāng)還是在于超大規(guī)模集群上的容錯處理，因此，這兩家公司目前在大規(guī)模集群應(yīng)用參數(shù)服務(wù)器的經(jīng)驗屬于領(lǐng)先(阿里的上述方案目前只用于特定應(yīng)用的在線實時計算，在容錯架構(gòu)上不需更多復(fù)雜的設(shè)計)。

這篇文章是本人在2014年就有想法撰寫的，一直拖拉到了2016年初才完成初步輪廓。短短的一年多內(nèi)，參數(shù)服務(wù)器發(fā)生了巨大的變化：DMLC項目組的橫空出世，Petuum的重構(gòu)，Paracel的開源，以及其他眾多公司的工作，并且這些工作全部是國人或者國人主導(dǎo)的項目。究其原因，是因為在最熱門的機器學(xué)習(xí)算法中，包括深度學(xué)習(xí)，推薦引擎，計算廣告等領(lǐng)域，參數(shù)服務(wù)器相對于其他抽象都具有無可比擬的優(yōu)勢，再加上其架構(gòu)實現(xiàn)簡單，因此出現(xiàn)這么多的可選就并不是一件意外的事情了。在為自己的項目引入?yún)?shù)服務(wù)器的同時，需要深刻了解每種方案背后的應(yīng)用場景。在當(dāng)前來說，所有的開源方案，都還不具備在大規(guī)模商業(yè)集群上使用的能力，因此這也是為何會有公司自己攢相關(guān)輪子的緣故。如果你想打造自己的輪子，DMLC的ps-lite是一個好的起點；如果你對機器學(xué)習(xí)算法很精通并且愿意探索更優(yōu)秀的性能，你值得在Petuum基礎(chǔ)上進一步研究；如果你只想等著在已有中等規(guī)模集群上使用，那么可以等待Spark社區(qū)。可以預(yù)計，在接下來的一兩年中，相關(guān)的工作會更快地推進，尤其是在可運維性和容錯方面有更加周到的考慮，這也是基礎(chǔ)架構(gòu)領(lǐng)域值得大干特干的若干領(lǐng)域之一。

[1] http://hunch.net/?p=151364
[2] https://github.com/dmlc/rabit
[3] http://paracel.io/
[4] Alex Smola, An Architecture for Parallel Topic Models. VLDB, 2010
[5] Jeff Dean. Large scale distributed deep networks. In NIPS, 2012
[6] Solving the stragglerproblem with bounded staleness. In HotOS (2013).
[7] https://github.com/dmlc/ps-lite
[8] Mu Li, Dave Andersen, Alex Smola, Scaling Distributed Machine Learning with the Parameter Server, In OSDI, 2014
[9] Mu Li, Zhou Li , Alex Smola, Parameter server for distributed machine learning, In NIPS, 2013
[10] Eric P Xing, Petuum: A New Platform for Distributed Machine Learning on Big Data, In SIGKDD 2015
[11] Seunghak Lee, Jin Kyu Kim, Xun Zheng, Qirong Ho, Garth A. Gibson, and Eric P. Xing, On Model Parallelization and Scheduling Strategies for Distributed Machine Learning, In NIPS 2014
[12] https://github.com/Microsoft/DMTK
[13] https://github.com/intel-machine-learning/DistML
[14] https://issues.apache.org/jira/browse/SPARK-6932
[15] https://github.com/chouqin/spark/tree/ps-on-spark-1.3

總結(jié)

以上是生活随笔為你收集整理的参数服务器——分布式机器学习的新杀器的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。