豆瓣PARACEL：讓分布式機器學習變得簡單

在豆瓣，我們常通過機器學習的方式從各種數據中訓練出模型，利用這些模型幫助我們理解用戶并為大家挖掘出有價值的內容：豆瓣 FM 的個性化歌曲推薦、書影音的喜歡也喜歡、首頁的豆瓣猜等等。

早期的時候，單機訓練的程序基本就能滿足需求。一方面數據量不大，另一方面有的模型算一次可以用很長時間，對性能要求就沒有那么高。不過很快，隨著豆瓣的壯大，我們有了分布式計算的需求。當時 Spark 還沒有 Python 接口，豆瓣基于 Spark 的思路開發了 Dpark 系統。Dpark 非常成功，一下子把我們能解決問題的規模擴大了不少。

Dpark 的出現解決了豆瓣大部分的數據需求和一部分機器學習模型的訓練需求。然而，對于那些對性能要求較高的模型，Python 并不能達到預期。同時，mapreduce 的計算模式對于機器學習算法來說不夠靈活。因此，對于較為復雜的模型的并行訓練，我們仍然采用 C++ 加 MPI 這樣較為費時費力的方式來開發。

2013 年初，我們從 Jeff Dean 發表在 NIPS12 上的論文《Large Scale Distributed Deep Networks》中了解到 Google 公司用來做深度學習的訓練框架 DistBelief。DistBelief 將巨大的深度學習模型分布存儲在全局的參數服務器中，計算節點通過參數服務器進行信息傳遞，很好地解決了隨機梯度下降和L-BFGS 算法的分布式訓練問題。豆瓣當時并沒有做深度學習的需求，但我們意識到機器學習問題可以轉化成優化問題，而解優化問題的眾多方法和隨機梯度下降的過程是類似的：選定初始值，按某種方向，迭代直到收斂。

為了提高分布式算法的開發效率和增強代碼被復用的能力，我們決定抽象出一個比 mapreduce 更適合機器學習模型訓練的范式做成框架。Paracel 項目就是在這樣的背景下產生的，自從 2014 年 3 月在豆瓣內部發布最初版本至今已一年時間，我們決定將它開源。

Paracel 是一個基于參數服務器通信模型的分布式訓練框架。參數服務器可以被理解成一個全局分布式的 key-value 存儲，用來存儲待訓練的模型。同時，參數服務器還能通過用戶定義的 update 函數進行分布式計算，這時它與 mapreduce 系統中的 reducer 很類似。隨著數據量的增長和模型的越來越復雜，單機的內存已經裝載不下許多模型的參數了。Paracel 不僅支持數據并行剖分，同時支持模型的并行剖分。開發者可以將訓練數據劃分到各個計算節點，并將對應的模型在參數服務器端進行劃分，使得算法在計算性能和內存使用上都做到可擴展。

Paracel 提供了簡單又通用的通信接口，計算節點可以向參數服務器讀取、寫入、更新模型。在更新操作時，用戶可以自定義的 update 函數。與瑣碎的 MPI 通信方式相比，計算節點并不需要知道參數存放的具體信息，而是通過統一的接口與參數服務器進行交互，簡化了開發的復雜度。值得強調的一點是，基于 Paracel 來開發分布式機器學習算法非常地直觀，對于開發者而言，在 Paracel 中實現一個分布式機器學習算法和實現一個串行算法并沒有太大區別。事實上，在開發 Paracel 中算法庫的過程中，我們通常也是先實現一個單機的版本，然后在其基礎上加少量的代碼完成并行化的。

Paracel 解決的另一問題是 straggler 問題：由于一些軟硬件的原因，節點的計算能力往往不盡相同。對于迭代問題來說，每一輪結束時算得快的節點都需等待算得慢的節點算完，再進行下一輪迭代。這種等待在節點數增多時將變得尤為明顯，從而拖慢整體的性能。Paracel 放寬了“每個迭代步都等待”這個約束：當在一輪迭代結束時，算得快的節點可以繼續下一輪迭代，但不能比最慢的節點領先參數s個迭代步。當領先超過s個迭代步，Paracel 才會強制進行等待。這樣異步的控制方式既從整體上省去了等待時間，也能間接地幫助慢的節點趕上。從優化問題的角度來看，雖然單迭代步收斂得慢了，然而每個迭代步的時間開銷變少了，總體上收斂也就變快了。

此外，我們還在 Paracel 項目中開源了一個基于它實現的算法工具集，用戶在安裝完 Paracel 后就可以用其中的算法工具進行數據處理。我們將會不斷地在這個工具集中加入更多的算法。

最后，希望能有更多的人使用 Paracel。如果你想貢獻代碼，不妨 fork 它在 GitHub 上的代碼倉庫并給我們提交 pull requests.

項目主頁：paracel.io

20 分鐘教程：paracel.io/docs/quick_tutorial.html

API 文檔：paracel.io/docs/api_reference.html