微軟分布式云端機器學(xué)習(xí)應(yīng)用探討
如今，各類企業(yè)都在積聚越來越龐大的數(shù)據(jù)資產(chǎn)，比如用戶行為、系統(tǒng)訪問、使用模式等數(shù)據(jù)記錄。而運用像微軟Azure機器學(xué)習(xí)平臺這樣的云端服務(wù)平臺，企業(yè)不僅僅可以用它來儲存數(shù)據(jù)，做一些經(jīng)典的“后視”商務(wù)智能分析，更能使用云端的強大力量做出具有“前瞻性”的預(yù)測分析。使用Azure機器學(xué)習(xí)這樣的現(xiàn)代化工具，企業(yè)可以獲得關(guān)于其業(yè)務(wù)未來發(fā)展的切實見解——這將成為它們的競爭優(yōu)勢。
對“大數(shù)據(jù)”的收集和維護已經(jīng)成為許多應(yīng)用程序的普遍需求。隨著數(shù)據(jù)量的劇增，分布式儲存已成為必然趨勢。在許多應(yīng)用中，收集數(shù)據(jù)本身就是一個分散的過程，自然導(dǎo)致了分布式的數(shù)據(jù)儲存。這種情況下，建立起以分布式計算處理分布式數(shù)據(jù)的機器學(xué)習(xí)(以下簡稱“ML”)方案就十分必要。這些方案包括：通過在線廣告領(lǐng)域的邏輯回歸分析來估計點擊率，應(yīng)用于大量圖像和語音訓(xùn)練的數(shù)據(jù)集的深度學(xué)習(xí)方案，或為檢測異常模式而進行的記錄分析。
因此，在一個集群中對ML方案進行高效的分布式訓(xùn)練，是微軟云信息服務(wù)實驗室(CISL——Microsoft Cloud & Information Services Lab，發(fā)音像“sizzle”:-))的重要研究領(lǐng)域。本文，我們將對這一主題進行一些較為深入的探討。下面所闡述的一些細(xì)節(jié)可能技術(shù)性略強，但我們會盡可能以簡單易懂的方式來闡明它的中心思想。理解了這些想法，任何對大數(shù)據(jù)分布式ML感興趣的人都會有所收獲，我們也很期待你們的評論和反饋。
選擇合適的基礎(chǔ)設(shè)施
John Langford在近期發(fā)表的一篇文章中，介紹了用于快速學(xué)習(xí)的Vowpal Wabbit (VW) 系統(tǒng)，并簡要談及了對兆級數(shù)據(jù)集的分布式學(xué)習(xí)。因為大多ML的算法本質(zhì)上是迭代，因此選擇合適的分布式框架來運行它們就變得十分關(guān)鍵。
Map Reduce和它的開源實現(xiàn)Hadoop，是目前較為流行的分布式數(shù)據(jù)處理平臺。但由于ML每次迭代都有巨大的開銷——如作業(yè)調(diào)度，數(shù)據(jù)傳送和數(shù)據(jù)解析，因此以上的分布式數(shù)據(jù)處理平臺并不能很好的用于迭代性的ML算法。
一個更好的選擇是增加通信基礎(chǔ)設(shè)施，如與Hadoop兼容的All Reduce(像在VW中那樣)，或者采用更新的分布框架，如支持有效迭代運算的REEF。
統(tǒng)計查詢模型 (SQM)
目前分布式ML***進的算法，如用于VW中的是基于統(tǒng)計查詢模型(SQM--Statistical Query Model)的算法。在SQM中，學(xué)習(xí)是基于對每個數(shù)據(jù)點進行計算，然后將對所有數(shù)據(jù)點的運算結(jié)果進行累加。舉例來說，假設(shè)線性ML問題的結(jié)果是一個特征向量與其權(quán)重參數(shù)向量的點積。這包含了邏輯回歸、支持向量機(SVMs)和最小二乘方擬合(least squares fitting)等重要的預(yù)測模型。在這種情況下，每次迭代時的訓(xùn)練目標(biāo)函數(shù)的整體梯度是由各個數(shù)據(jù)點的梯度相加而成的。每個節(jié)點形成與該節(jié)點的訓(xùn)練數(shù)據(jù)相一致的局部梯度，然后用All Reduce運算來獲得整體梯度。
通信瓶頸
分布式運算常常要面臨一個關(guān)鍵瓶頸，即運算與通信寬帶之間的巨大比例差。舉例來說，通信速度比運算速度慢10倍到50倍都很常見。
以Tcomm和Tcomp分別表示通信和運算的單次迭代時間，那么一個迭代性ML算法的總時間花費可用下列算式表示：
總時間 =(Tcomm + Tcomp)* #迭代次數(shù)
當(dāng)節(jié)點增多時，Tcomp通常為線性下降，而Tcomm則上升或保持不變(All Reduce良好實施的情況下)。涉及大數(shù)據(jù)的ML方案經(jīng)常有眾多的權(quán)重參數(shù)(d)，這些參數(shù)在每次迭代時都會在集群中的節(jié)點間通信、更新。此外，其他步驟如SQM中的梯度運算也需要復(fù)雜度為O(d)的 通信。這種情況在Map Reduce中更加不理想——每次迭代都需要一次獨立的Map Reduce工作。因此，當(dāng)參數(shù)d很大時，Tcomm也會變得很大。SQM并未在這方面的低效率問題上給予足夠的重視。
攻克通信瓶頸問題
我們近期的研究正是針對這一關(guān)鍵問題，并建立在下述現(xiàn)象之上：假設(shè)Tcomm節(jié)點間權(quán)重參數(shù)的通信時間非常大。在每次迭代中，采用SQM這種標(biāo)準(zhǔn)方法會使得Tcomp每個節(jié)點內(nèi)與運算相關(guān)的時間，遠(yuǎn)小于Tcomm。因此我們提出以下問題，有沒有可能修改算法和其迭代，使Tcomp與Tcomm接近，并且在這個過程中，將該算法轉(zhuǎn)變成為迭代次數(shù)較少的理想方案呢?
當(dāng)然，回答這個問題并不簡單，因為它意味著一次根本性的算法改變。
#p#
更多的具體細(xì)節(jié)
接下來讓我們考慮ML學(xué)習(xí)線性模型的問題。在我們的算法中，節(jié)點中權(quán)重更新和漸變的方式與SQM方式類似。然而，在每個節(jié)點中的漸變梯度(用All Reduce算出)和本地數(shù)據(jù)經(jīng)過復(fù)雜的方式形成對全局問題的本地近似值。每個節(jié)點解決自己的近似問題，形成權(quán)重變量的本地更新，隨后所有節(jié)點的本地更新結(jié)合形成權(quán)重變量的全局更新。每個節(jié)點解決近似問題時會導(dǎo)致其計算量增多，但不需要任何額外的通信。這樣一來，雖然Tcomp增高，但因為Tcomm 本身就很高，因此每次迭代花費的時間并未受到顯著影響。但是，由于每個節(jié)點現(xiàn)在解決的是近似全局視圖的問題，解決問題需要的迭代數(shù)量將大大減少。設(shè)想在無比龐大的數(shù)據(jù)中，每個節(jié)點自身的數(shù)據(jù)就足以實現(xiàn)良好的學(xué)習(xí)。這種情況下，每個節(jié)點形成的近似問題就近似于全局問題，這樣SQM的算法需要幾百次甚至幾千次的迭代時，我們的算法只需要一或兩次迭代就能完成。此外，我們的方法也較為靈活，允許出現(xiàn)一系列的近似值而不只是一個特定值。總體來說，我們的算法比 SQM平均快了兩到三倍。
也可以考慮將權(quán)重向量分散到多個集群節(jié)點中，建立分布式數(shù)據(jù)儲存和運算方式，使任何一個權(quán)重變量的更新只發(fā)生在一個集群節(jié)點上。這在一些情況下非常有效，比如對線性ML問題中相關(guān)權(quán)重變量的歸零問題，或者做分布式深度訓(xùn)練時。這樣我們又一次建立了特殊的迭代算法，增加了每節(jié)點內(nèi)的運算但減少了迭代的次數(shù)。
評估
上述我們重點關(guān)注的算法比較適合通信負(fù)擔(dān)較重的情況，但這并不能解決在實際中的所有問題。對于一般的情況，最近的學(xué)術(shù)文獻中有很多好的分布式ML算法，但目前對這些方法還沒有一個細(xì)致的評測。***的方法還在尋找它們通往云端ML庫的道路上。
根據(jù)用戶需求的自動分布式ML
另外，還有一個重要的部分，即在云端上使用分布式ML的用戶擁有不同的需求。他們也許對最短時間內(nèi)產(chǎn)生方案感興趣，也許認(rèn)為最少花費產(chǎn)生方案很重要。在考慮上述變量進行***選擇時，用戶愿意犧牲一些精確度。另一種可能是，他們也許迫切地想知道最確切的結(jié)果，而不計時間和花費?？紤]到問題描述、用戶的不同要求和系統(tǒng)配置的可應(yīng)用性細(xì)節(jié)，擁有一個能夠選擇合適算法和參數(shù)設(shè)定的自動程序十分重要。我們目前的研究也集中在這一方面。
