卡耐基梅隆大學教授邢波：Petuum，大數據分布式機器學習平臺
2014年12月12-14日，由中國計算機學會（CCF）主辦，CCF大數據專家委員會承辦，中科院計算所與CSDN共同協辦，以推進大數據科研、應用與產業發展為主旨的 2014中國大數據技術大會 （Big Data Technology Conference 2014，BDTC 2014）暨第二屆CCF大數據學術會議在北京新云南皇冠假日酒店盛大開幕。
2014中國大數據 技術大會首日全體會議中，卡耐基梅隆大學教授、ICML 2014程序主席邢波帶來了名為“A New Platform for Cloud-based Distributed Machine Learning on Big Data”的主題演講。期間，邢波表示，著眼當下大數據處理平臺，大量資源都都浪費在集群的通訊同步上。即使比較優秀的平臺，計算時間也只有20%，通訊 時間占到80%，就比如Hadoop的通訊時間占到90%甚至更高。
卡耐基梅隆大學教授、ICML 2014程序主席 邢波
以下為演講實錄：
邢波：
我首先感謝大會組委會邀請我來給這兒做一個報告。我這個報告風格可能跟以前幾個不一樣，干貨比較多，比較枯燥，有一些正規的實驗結果，甚至有一些數學公式，另外我也很樂意分享一下剛剛從學生那得出的結果。
我想討論一下用于大數據的分布式機器學習運算的平臺。當我們面對大數據，大家首先問到的問題通常是，我們從大數據里面能挖到什么東西，大數據到底有什么用？這個問題大家已經看到了很多展示，這塊就不再重復或者追加。
我 這兒希望能夠講一個更加看似無趣但是基本的問題，如何來進行大規模的大數據運算，如何把它做對。這個原因是？現在數據量如此之大，隨之而來關鍵的問題會是 對數據的正確理解，而這里邊的工具到底是什么呢？至少在我們計算機學家目前的經歷來看，很多人同意機器學習和它代表的統計學習的算法可能是一個對數據進行 有效挖掘的途徑。
我這里就要探討一下如何把這個工具過渡到大數據的平臺上，而這個“大”字對以前的研究產生什么影響？有必要強調一下這個問 題的重要性。現在有很多對大數據的忽悠，很多文章都會說數據就是金錢，有很多數據的話你就變得很有財富，甚至你變得非常聰明。但如果沒有一個很好有效體系 對這個數據作分析，其實數據不等于知識：就像森林里面倒下一棵樹，你沒看到的話，它倒沒倒下，你并不知道。今天我就講這些技術型的問題。
為什么大數據的機器學習挖掘比較困難，首先數據量變大，挑戰了存儲、通訊，甚至處理的極限，所以你要把它分布到一個大的多機的數據中心去而不再僅是單機上。但是其實挑戰不僅僅是這一些，當數據變得很大的時候，你的問題變得很復雜，需要聰明大腦和聰明的模型理解。
大 家在大型公司里面用到的模型有幾百幾千個億的參數，從單機里面溢出需要并行處理，想把這步做對并不是簡單的問題，這就涉及到第三個問題，這些軟件包工具到 底在哪兒？你可能看到剛才講解者展示IBM的系統，余凱先生下面會展示百度的系統，大數據的問題目前都是大型企業他們專屬權利，而比較屌絲級別的公司或非 IT公司就沒有辦法處理，是不是這樣的局面無法撼動？我想大數據工具庫普及變得非常好用情況就會改觀。
大數據工具庫不能僅包括簡單的工具諸 如決策樹，kNN，這些工具都有20、30年的歷史還在用但并不是很有效；我們要的高大上的工具，深度學習、話題模型、協同過濾這些東西在很現代的文獻里 面出現，開始被很高級的公司積極使用，他們到底有什么樣的一些技術上的挑戰，防止普通人或者更多大公司使用？
我這里要提出一個問題：當你這 個數據或者是模型大到了從一個機器內存里面溢出，大家希望顯然是這么一張曲線：我不斷加機器，越加越多能力越高，這是大家的期望。如果各位開發人員尤其工 程人員有實際經歷，我想你會告訴我，當我給你一千臺機器后你的能力并沒有增加一千倍；機器有很多的時候，你的資源中各種各樣的時間浪費在沒有用處計算上， 比如說通訊、等待、協調這些方面。因此我們看到的一個曲線是這樣的一個曲線－－我們實際收獲的計算能力并不隨機器增加而增加，而是很快封頂了，甚至跌落 了。對于計算機學家來說，固然去拿大數據來做挖掘，提供信息，親自做一個數據挖掘選手很重要，但是我覺得計算機學家另外一個很重要的任務是提供方法論和工 具，把這個曲線從這兒提到這兒，這就是我待會講話中心內容。
我為什么說現在已有的系統不足以實現我們剛才所希望的功能呢？這塊我舉幾個例 子。比如說有很多機器學習的學者，他們顯然對大數據很感興趣，由于本身訓練局限或者是習慣思維緣故，他們對系統知識通常并不了解，他們看到一百個機器跟一 臺機器的差別只不過乘了一百，中間的代價或者是機器的失效幾率他們可以都不太考慮，所以他們的算法主要是針對數學上的正確性或者是迭代算法迭代次數減少 性，但是他們不會鉆研這個算法到底在一個真實的機器群上怎么運作；他們會寫這么一個程序，中間有一句話：“并行運算”，然后就天真的假設這個就開始發生 了，把這些算法程序放在很多機器上它們就能算好。
實際過程中，我至少看到是這樣一個情況，你去做一個小實驗，去測量用在計算上的時間和用在通訊上的時間，最好結果也無非如此：至少20%的時間花在機器上面，80%的時間花在等待，經常更糟，上面提到那種理想狀態不存在，所以這些算法實際上通常無法應用。
另 一方面，系統工程師對機器學習或者統計學習原理或者技術并不見得非常精通，他們所需要實現的目標是盡可能實現極高的迭代的輸出，修正由于機器造成的一些損 耗，所以他們會發展一些非常可靠、非常高通的技術。但是他們對于機器學習的算法通常是做了一個非常簡單的假設：我只要把它能夠跑起來，它肯定能跑對，肯定 會收斂。如果系統中還有一個特殊編程模型，比如Spark里面有一個RDD，GraphLab中有一個節點模型，他們就會假設，無論什么機器學習的算法都 可以轉換成這么一個模型，這是工程師的任務。我就不知道各位工程師有沒有試過把話題模型變成RDD或節點模型，這是很困難的，需要對機器學習原理有深刻掌 握才能做到。因此你看不到復雜機器學習在這些系統上的普及應用。
所以系統方面的工作通常簡化了在機器學習理論上的工作，把它變得理想化，最 起碼會造成一些資源上的浪費，但更嚴重會造成算法本身的失敗會發散，你得到結果并沒有用處。所以總結一下，由于兩方面領域間的隔閡，通常我們在開發已知系 統對對方的框架都產生了比較簡單化的假設，實際工作中你喪失了很多機會，也造成了很多錯誤。
理想狀況下有這么一個途徑，你有很多任務和各種 硬件設備，咱們中間有一個普世的算法或者框架，然后這個框架上能夠來支持所有這些機器學習的軟件，然后使用所有已知的硬件，中間這層機器之間的協調、通訊 或者是錯誤處理應該是被抽象化被自動化，作為一個程序員我們不應該掌握去觸碰這些東西。
這個問題到底是在什么層面上能夠獲得解決呢？我首先 想指出這絕對不是一個軟件的問題，在設計打造這樣的一個界面的過程中，你不僅要懂得系統設計也要懂得機器學習的理論，而且還要懂得算法的設計，所以整個需 要的技能是相當龐大的一個技術支持。所以這也就造成了這種問題的困難性，而且它就說明并不是所有人去碰這個問題，風險很大，回報率并不是很高，但總有人在 做這樣的事情，有人開發類似的操作平臺或者框架。我們CMU的團隊正在開展這樣的工作，我待會想跟大家分享一下開發框架中比較有意思的思路和得到的經驗教 訓。
這里首先要研究設計分布式的策略，怎么做分布。當你有多臺機器的時候，顯然把任務分布到每個機器上去，每個機器往前走，把中間結果存在 局部的存儲空間，他們完成的時間并不是一樣，保證程序正確性你需要設置等待集合點，每一臺端點工作機和那個叫做服務器頭領機握手協同后可以接著往下走。機 器學習算法有這么一個特點，不是一次性，需要反復進行迭代，這樣就造成困難，在你選擇對于系統的行為采取不同的措施的時候，它會產生不同的結果，有些結果 就是像這樣，很多時間浪費在通訊上面，或等待所有端點完成協同，這能保證你的結果很對，它很慢，但是對。另一種方法我把通訊協議可以簡單化，讓它不必等待 彼此，有時候會得到一個很快的結果，但這種結果經常是一個發散的不正確的一個結果。
Hadoop，在過去被大家認為是一個適合寫并行程序的 平臺，但是Hadoop對機器學習的算法是不是真正適合呢？我不知道各位在自己開發過程中有這樣的經歷，我自己在學校里面或者非死book做訪問教授 的這方面的經歷是相當悲慘：你在Hadoop掌握了一千臺機器，你來寫一個Hadoop的項目，但中間硬盤讀取等等的瓶頸會極大程度限制了程序有效性，當 你有很多機器的時候，彼此之間很難同步，大部分時間發生在等待里面。硬盤讀取是相當昂貴的操作所以會耗費大量時間，經常造成程序相當難往前推進。
我 們從這個地方出發，怎么來解決這個問題，是相當有意思的一個問題。這塊為了表達我們的思路，有必要稍微展示一下到底機器學習的神秘性或者它的特點在哪兒？ 跟普通的程序有什么區別？我嘗試了一下做了比較。通常寫計算機程序希望是一個精密的執行，就像我搭一個樓，把一個藍圖精密到按步驟進行實現，這樣保證這個 樓能搭起來，錯一步都不行。機器學習不是精密實現以前設定好的計劃，而是通常實現一個數學優化問題，就像在體操里面有一個規定動作一個自選動作，爬這個山 頂你可以從這條路爬，也可以從那條路爬，所以有一種容錯性，有容錯性就給了新的機會。而且機器學習可以寫出這么個數學公式，達到最高點你可以用數學公式進 行評估，解決途徑通常可執行迭代程序，迭代程序本身有自動收斂性的特點。
當你在一定情況下進行迭代，不管你迭代精度是特別高還是比較高，它 都有可能收斂，這就造成了機器學習算法既難又簡單，關鍵看你從哪個角度解決。這里用容錯性做一個比較：比如說你在做一個排序，我們知道這個東西是不能容錯 的，這塊如果錯了以后不改，最后結果是錯的。這是傳統計算機程序的普遍特點，一旦在某個結骨眼出了錯，你必須改。機器學習算法的運行，就像這個有點喝醉的 家伙在爬山，雖然醉了，但知道山頂在哪兒，他看得見，腳還能走，多多少少還是能爬上去，不見得爬得那么快，或者每一步都向上，走錯了以后不一定要走回去， 還要重走，這個地方和傳統計算機程序是不一樣的。
還有數據和模型的兩相性，對于系統工程師，數據和模型并沒有什么區別，它都是在內存里邊的一些數字而已，把它分割沒有問題，比如我有數據分在某一個機器上。我這兒有模型，模型指里面參數，比如神經網絡參數可以把它分割，大了以后也可以做所謂的數據和模型并行。
在 通常經典的系統設計里面，這兩種并行沒有區別，有時候你會看到Hadoop和Spark不相區分的并行處理。但是如果你仔細觀察機器學習程序特點，你發現 這兩種并行的結果很不一樣，當數據被并行的時候，他們之間是不相關的，所以你不需要對他們之間進行協調，需要對算出的分布的子結果進行一定的協調，但在他 們算的過程中你不需要進行協調。
當模型被并行的時候，它中間實際是相關的，所以你不在過程中進行協調，最后結果就會出錯，所以這種情況下你會發現，你對數據并行對模型并行需要做不同的通訊和系統設計，還有其它一些東西我就不多討論。
我 做一個總結，機器學習算法有它的獨特性，基于優化的算法，而且用（遞歸）來實現，有一些容錯的能力，有一些動態結構，然后它還是非同質的，有一些參數會回 歸很快，有些收斂很慢，你可以對收斂快做完停下來把資源另外使用，這都是要求編程員或者程序對機器學習算法有一定的了解，這樣有一定的機會來進行加速。而 這種東西在傳統程序里面不存在，通常對于指令級的一個完全正確執行，造成這樣很多技術上更多的措施，但在機器學習不見得很有必要。
看看已知 的系統怎樣解決這個挑戰，大家都知道Spark實質上是Hadoop的升級版本，一開始需要把程序，模型，數據轉換成一個叫做RDD的特殊數據結構，它是 在內存中的，因而讀寫很快，后面迭代非常好。RDD保持一個過程樹，所以在運算中如果出現問題很快找出問題所在，這都是RDD和Spark非常優異的特 點，特別在數據庫的處理或者非迭代的數據并行處理里面是非常有效的。
做模型并行要求全局性的一個協調，這樣就會產生一些很大的代 價，Spark上沒有特別的機制來應對這種需要。Graphlab，用節點圖來表示模型，數據，圖上的邊表示相關度的強弱，你可以依此寫成一個節點程序自 動做一個非同步的通訊，仍然保持這個程序最后能夠正確收斂。這也是一個很好的思路，在很多情況下都產生了比較好的結果，甚至比Spark還要好。但它也有 一些問題，數據量變得非常大，程序會變得非常沉重，效率不是很高。
我們組正在開發這么一個平臺，叫Petuum，包含數據和模型并行兩套功能，也對機器學習的特點做了比較深入的一個研究，對他們做了一些針對性的使用，所以我們系統對機器學習內部特點比較有針對性，他們有一些非常有意思的特性和功能，這塊我可以總結一下。
大 致結構是這樣，它包含一個參數服務器，大家都知道參數服務器，給你提供很好編程的一個共享虛擬分布內存，大家在編程的時候不用對每個機器進行單獨通訊；我 們還有一個叫做調度器，它是能夠對模型進行有效的分割，甚至是動態分割，然后做一個分布化和載量平衡。運行原理就跟機器學習的工程師寫機器學習的算法基本 一個思路，用迭代加上對公式的更新量的隨機性而不是確定性的反復刷新，跟傳統的是不一樣的。
這個參數服務器有這樣一個編程界面，你在寫內存 讀取內存不需要對每一個機器做一個特殊的指令，而是用和單機讀寫形式上相似的通用指令。它使用了比較巧妙的所謂半同步的協調機制，這樣可以顯著降低使用在 通訊上的時間，而加強在計算上的時間，所以你可以看到隨著我們半同步參數的調整，我們這個通訊時間會顯著下降，降到了以至于比計算時間還要少，這樣使計算 機的資源得到最大量的利用。
在調度器方面我們也用了基于機器學習考量的設計，調度機自動發現機器學習模型里面的一些結構，找出哪些參數是相關，哪些參數是不相關，然后對它們做相應分布，他們在分布運行的時候并不違反正確性、約束性，這樣也會造成更快的收斂。
為 什么這樣做產生這樣好的結果？這里邊有一些比較深層的技術和科學原理，時間允許，我可以再講幾分鐘。并行系統是沒有理想的，我們當有好幾臺機器，顯然不能 希望它同步運算同步通訊，即使相同的多臺機器放在機房里面溫度不一樣，行為都是不一樣的，最后結果就是我們看到這樣的情形。我們怎么來協調這樣的一個缺陷 呢？通常對編程高手，當然這不是問題，他可以對每一臺機器做深層操作，可以避開所有的陷阱，對于普通程序員和低端用戶，這種非常昂貴而且耗時開發過程并不 見得能負擔得起，我們需要還是非常簡單的界面，讓界面下面的支持框架做了通訊上的決定，這個決定在數據并行過程中可以被總結成一個所謂的叫做協調或者是同 步協議。這個同步協議我們大家都知道，這一端包括Spark或者Hadoop協議完全協同，然后往下走，這個東西在數學上可證明是對的，但是造成有效性的 損失。
另外一種比較骯臟的結果，我不同步了，讓自己跑，對程序收斂性和正確性沒有任何保障。我們采取的方法是走一個中間路線，做一個半同 步，讓機器在有限的窗口里做局部的運算，用參數值的局部版本做一個運算，不跟其它東西通訊，當這個窗口被突破的時候，我就必須停下來等，每一個線程到達窗 口邊界的時間是隨機的，所以最后結果是所有線程都可以在最大程度上使用窗口做運算。我們關心的是，這東西顯然變得更快，就像非同步的東西，但能不能保證正 確性？結果是這樣的，因為我們是有限的非同步或者半同步，你可以產生一個證明，產生的收斂結果跟同步結果是一樣的。這是我目前知道的第一個對于這類操作系 統做一個理論證明正確性的結果，這個系統有一定的理論價值甚至也是一個好的應用價值。
然后它的編程界面是相當普通的界面，你把不同的機器學 習算法，像話題模型、矩陣分割或者是像線性或者邏輯回歸都表示成參數服務器這樣的表示，用這樣一個很簡單的高級語言來進行操作。結果如何呢？我們發現在不 同的程序上面我們都獲得了比這個同步或者是完全非同步的方法更好更快和更佳的收斂結果。
再講模型并行，在數學上有一個更強烈的所謂的協調性 的要求，這塊我想用一個線性回歸做一個簡單的闡述。通常我們做線性回歸需要估計參數，這個參數矢量是很高維的，也許100億維，在普通存儲機器里面放不 下，或者放下以后用串行的方法來算很慢，所以你需要并行，那亂放行不行？最后發覺不行。在數學上可以獲得這樣一個形式：當你隨機取兩個參數，當你動用了其 中一個參數，另一個參數，它的值和前面那個值相關，所以有一前一后要求，當你把這兩個東西做并行，相關性就被破壞，而且無法收斂，這兩個相關度在數據上有 關系所以可以做定量計算，所以當兩個參數非常相關我們需把它們放在同一個機器上面，這是相當昂貴的操作，理論上可通過畫出一個節點圖我們對每一對參數對做 這樣的預估，100億維是很大的圖，是不可操作的。
我們在這兩種選擇里面，純粹圖分割或者隨機分割采取中間路線，我們可以想像參數里邊并不 是所有參數都是同樣重要，有些東西重要，有些東西不重要，有些東西快收斂了，我們采用一種方法對參數進行大致評估，只對重要的東西進行處理，這是基于結構 的并行化叫SAP，也可以用簡單的編程界面。這是一個操作，從某一個方程里面取樣，取一部分重要參數，對它結構進行分析，把它們向各個機器上做分布。
在第二個迭代里面，有可能結構會出現變化，可以再重新做這一步，這是用戶之間的選擇。分布策略有很多可能性，剛才說優先度的考量，哪些參數重要哪些參數不重要，你也可以做模塊化考量，把參數分成幾個塊，也可以做有保障的同步。
實 驗結果，我們做了良好動態并行實現很快良性收斂，不然如果用隨機并行就是不收斂或很慢的收斂，我們也有理論和實驗證明，不光在均值，在方差上都有很好的收 斂的保障。時間正好讓我講完了科學原理，我們也見到了結果，在不同算法上得到了很大的提升。我最后用幾張圖總結一下，現在大規模機器學習平臺整個環境地 貌，這是相當挑戰但是相當讓人激動的領域，有很多家在玩，我們是后來者。
現在在講大數據大模型你要是沒有幾十個億的參數就不用再談的。看看 最近達到了什么結果，你可以看到有人用一萬臺機器達到一百億參數，做了話題模型的估計，你會看到其它的數據、神經網絡或者對于話題模型都達到了類似的量 級，大家的目標是，我的機器越來越多，把模型可以做得越來越大，這是一個趨勢，有所投入有所收獲。把大量機器協同起來跑一個分布程序，是很了不起的成果。 但同時你也希望把效率進一步提高，這是我們匯報的結果，我們在最近做了話題模型和矩陣分解和卷機神經網絡，看到他們的大小都已經超過了現在目前在文獻里邊 所匯報最大的結果，但是所使用的機器比現在的機器少一個數量級。下面還有展示速度上的提升。
我們跟微軟做了一個合作，他們用了24臺比較高端的機器，實現了10的12次方參數的話題模型，有一百萬個話題，每一個話題有一百萬個詞，這是目前所知道最大的話題模型，比非常有名的騰訊的那個peakcock還要大了大概10到50倍，但我們用的機器比他們少很多。
最 后總結：對于平臺或框架設計如果既考慮了操作系統原理，也考慮機器學習原理，你會得到很好的收獲。Petuum是開源項目，基于目前的觀察可以說，它不光 可以達到很龐大的模型體積，基本上等價或優于現在最好的系統，而且在對機器集群大小和硬件指標的要求，我們極大的降低了要求。講話前，剛剛收到學生最新從 NIPS大會送來的結果，很讓我們驚喜：還有一個組知道了我們的系統，用這個系統跟Spark和GraphLab做了獨立比較，我很高興看到我們的收斂曲 線達到最低最快，我想用這個結果來結束我的講座。最后大家可能會希望知道，到底Petuum系統到了什么程度，我們愿景既包含上層軟件，底層軟件，和生態 界面的支持，成為目前在Hadoop生態系統一個分子，你們可以把它下載以后做自己的開發，也可以使用我們庫中的軟件。這個項目我最后要感謝我的同事和學 生們在這兩年里面的支持，也感謝各位的關注，謝謝！
來自：csdn.net