如何評價猿輔導分散式機器學習庫ytk-learn、分散式通信庫ytk-mp4j？

作為主要開發者不請自來了

ytk-learn

LR, GBDT/GBRT, FM, FFM 模型是廣告點擊率預測和推薦系統中廣泛使用的模型，但是到目前為止幾乎沒有一個高效的機器學習開源項目集這幾種常用模型於一身，每個都有自己的缺點：不支持分散式、速度慢、很難使用，很難集成到線上生成環境(java)，於是就決定自己造輪子。第一版兩年前就做好了，但是還是不好用，後面就不斷的迭代就成現在這個樣子了。

其中 GBDT/GBRT 的實現借鑒吸收了 XGBoost 和 LightGBM 的大部分有用特性(大部分特徵我們也早實現了，只是沒他們公布早了)，支持特徵並行和數據並行，支持傳統的精確演算法和直方圖近似演算法，支持 level-wise 或者 leaf-wise 的建樹方式，而且還實現了分散式帶權分位數近似。在單機數據並行的場景中訓練速度跟 XGBoost 相當，在非 台機器的分散式場景中比 LightGBM 速度更快，更穩定，實驗對比yuantiku/ytk-learn。

傳統的 GBDT/GBRT 在含有大量 Categorical 特徵的場景中無法使用，我們實現了多種適用於大量 Categorical特徵的 GBST(Gradient Boosting Soft Tree)模型，其中的一種模型在特殊情況下有點像阿里的mlr(本人在阿里公布mlr之前就已經在嘗試這個模型了，PRML p670)，在猿輔導的點擊率預測和推薦場景中效果明顯好於LR、FM、FFM等模型，感興趣的可以嘗試下。

實現了改進的 Hoag(Hyperparameter optimization with approximate gradient， ICML2016)演算法，能夠自動高效的進行超參數搜索。原始論文是需要精確知道hessian矩陣(其實是Hv)，所以只能在有限的模型中使用，後來我發現L-BFGS的two loops就是做Hg近似的，天然的就可以用上來了，這樣幾乎所有模型都可以使用該演算法了。當目標函數是凸函數時，hoag 能快速得到最優超參數(kaggle 比賽利器)，效率明顯高於傳統的網格超參數搜索演算法(grid search)，而且在非凸目標函數場景中也適用(稍微難調一點)。

ytk-learn中的機器學習模型、優化演算法、分散式通信、計算平台是解耦的，這樣我們只添加了少量代碼就可以在Hadoop, Spark跑起來，其中的分散式通信使用了我們另一個開源項目ytk-mp4j.

更多細節請參考：https://github.com/yuantiku/ytk-learn

ytk-mp4j(mpi for java)

目前可以用於分散式機器學習的通信主要基於MPI和RPC，其中MPI是分散式高性能計算的標配，雖然效率非常高，但是對於開發分散式機器學習任務來說有很多缺點: 開發難度大、數據支持太底層、只能用C/C++, Fortran編寫等等；RPC 方式來實現類似 allreduce 這種操作，在特徵維度特別高的場景，通信效率太低。於是我又造了一把輪子。

ytk-mp4j 是基於Java的高效分散式機器學習通信庫，實現了類似 MPI Collective 通信中的大部分操作，包含gather, scatter, allgather, reduce-scatter, broadcast, reduce, allreduce，使用 ytk-mp4j 可以快速地把串列機器學習程序改造成支持多線程和多進程。陳天奇大牛的Rabit只實現了allreduce和broadcast。

各種操作的時間複雜度：

相比於MPI, ytk-mp4j 擴展實現了一些非常實用的特性：

1. 所有的通信操作都是基於最優演算法實現[1,2]，性能非常高，同時支持多線程，多進程。同樣的功能，在C/C++ 環境中，可能需要結合 MPI 和 OpenMP 才能實現

2. 不僅支持基本的數據類型(double, float, long, int, short, byte)，而且還支持Java String及任意普通Java對象(Java 對象只需要實現 Kryo的 Serializer 介面)

3. 不僅支持傳統數組類型的 Collective 通信，而且還支持Java Map數據類型，使用Map數據類型，用戶可以實現非常複雜的通信操作(例如：集合求交、求並，鏈表的連接等操作)

4. 支持數據壓縮傳輸，在網路資源很緊張的情況下，可以節約大量的帶寬

5. 純Java代碼實現，可以無縫集成到 Hadoop, Spark 等分散式計算平台，構建自己的分散式機器學習系統

6. 使用 Java的SDP(Sockets Direct Protocol)可以實現高效的RDMA(Remote Direct Memory Access)

更多細節請參考：https://github.com/yuantiku/ytk-mp4j

參考文獻

1.Thakur, Rajeev, Rolf Rabenseifner, and William Gropp. "Optimization of collective communication operations in MPICH." The International Journal of High Performance Computing Applications 19.1 (2005): 49-66.

2.Faraj, Ahmad, Pitch Patarasuk, and Xin Yuan. "Bandwidth efficient all-to-all broadcast on switched clusters." Cluster Computing, 2005. IEEE International. IEEE, 2005.

這兩個項目還有很多不足和改進的地方，歡迎大家多提建議，貢獻代碼

不邀自來。屬於利益相關方。

ytk-learn, ytk-mp4j的一作 @夏龍 是我曾經實習公司的mentor，也是拉我來到現公司的引路人。在來公司前就在在線廣告、推薦系統應用方面有很深的造詣，在最優化理論上更是我的啟蒙老師。他早在14年就撰寫過凸優化相關的非公開迷你書（另外一個經典的迷你書在網路上熱度很高，是關於word2vec的：Deep Learning實戰之word2vec），我的專欄中有關優化部分的文章也受到了其中的一些啟發。由於他的理論功底非常紮實，團隊中很多關鍵技術都是由他主導攻克的。

另一個作者 @吳小凡 是萌妹子技術大牛，感覺這兩條已經夠吸引人了……（爆照什麼的也不是不可以考慮……）

ytk-learn,ytk-mp4j實際上是在公司內部使用多年的工具庫，這次正好趕上公司推動開源軟體的機會。實際上在這個框架所處的領域，已經有很多優秀的工具了，這些工具的群眾基礎也非常好，那麼我們為什麼還要做這個開源呢？

還是因為一些痛點。這些優秀開源工具在開箱即用和生態環境上還是存在一些小缺陷，同時部分實現的演算法對實驗環境的要求限制更多。

誠然java開發的機器學習工具在時間性能上會弱於c++，這個毫無疑問，但是使用java的好處也是很明顯的：開箱即用的可能性更高，更完整的生態環境（Hadoop,Spark），在分散式環境搭建、分散式數據存儲的問題上更容易通過現有系統解決。這讓工具投入使用的時間大大縮短，對於小至中型團隊來說，運行時間並不是衡量效果的唯一條件。能夠節省訓練之外一些步驟的時間也是一種整體效率的提升。

另外一部分就是數據通信了。有的工具對實驗環境有一些限制，比方說要求運算機器的數量要等於2的N次方，這樣數據傳輸可以使用最快的演算法完成。但是在一些情況下，機器的環境不一定會很理想，同一批機器可能還需要承擔其他的工作，那麼這些限制有時候會制約集群的成長。那麼一個將各種集群情況考慮在內的通信演算法就顯得很有必要了。

關於技術細節方面的事情作者已經講得很清楚了，在我看來，同行已經公開的工具和ytk-learn,ytk-mp4j並不存在明顯的衝突。ytk-learn,ytk-mp4j的目標是打造一個更親民，更接地氣的工具，解決用戶「為了一個滑鼠墊，配了一台電腦」的困擾。當然，開源之初，項目尚不完美，希望用戶多多提出寶貴意見，幫助他們成長！

最後吐個嘈：時代在變化，是不是該叫yfd-learn,yfd-mp4j？