卡耐基梅隆大學教授邢波：Petuum，大資料分散式機器學習平臺

【CSDN現場報導】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 Da ta」的主題演講。 期間，邢波表示，著眼當下大資料處理平臺，大量資源都都浪費在集群的通訊同步上。 即使比較優秀的平臺，計算時間也只有20%，通訊時間占到80%，就比如Hadoop的通訊時間占到90%甚至更高。

卡耐基梅隆大學教授、ICML 2014程式主席  邢波

以下為演講實錄：

邢波：

我首先感謝大會組委會邀請我來給這兒做一個報告。 我這個報告風格可能跟以前幾個不一樣，乾貨比較多，比較枯燥，有一些正規的實驗結果，甚至有一些數學公式，另外我也很樂意分享一下剛剛從學生那得出的結果。

我想討論一下用於大資料的分散式機器學習運算的平臺。 當我們面對大資料，大家首先問到的問題通常是，我們從大資料裡面能挖到什麼東西，大資料到底有什麼用？ 這個問題大家已經看到了很多展示，這塊就不再重複或者追加。

我這兒希望能夠講一個更加看似無趣但是基本的問題，如何來進行大規模的大資料運算，如何把它做對。 這個原因是？ 現在資料量如此之大，隨之而來關鍵的問題會是對資料的正確理解，而這裡邊的工具到底是什麼呢？ 至少在我們電腦學家目前的經歷來看，很多人同意機器學習和它代表的統計學習的演算法可能是一個對資料進行有效挖掘的途徑。

我這裡就要探討一下如何把這個工具過渡到大資料的平臺上，而這個「大」字對以前的研究產生什麼影響？ 有必要強調一下這個問題的重要性。 現在有很多對大資料的忽悠，很多文章都會說資料就是金錢，有很多資料的話你就變得很有財富，甚至你變得非常聰明。 但如果沒有一個很好有效體系對這個資料作分析，其實資料不等於知識：就像森林裡面倒下一棵樹，你沒看到的話，它倒沒倒下，你並不知道。 今天我就講這些技術型的問題。

為什麼大資料的機器學習挖掘比較困難，首先資料量變大，挑戰了存儲、通訊，甚至處理的極限，所以你要把它分佈到一個大的多機的資料中心去而不再僅是單機上。 但是其實挑戰不僅僅是這一些，當資料變得很大的時候，你的問題變得很複雜，需要聰明大腦和聰明的模型理解。

大家在大型公司裡面用到的模型有幾百幾千個億的參數，從單機裡面溢出需要並行處理，想把這步做對並不是簡單的問題，這就涉及到第三個問題，這些套裝軟體工具到底在哪兒？ 你可能看到剛才講解者展示IBM的系統，余凱先生下面會展示百度的系統，大資料的問題目前都是大型企業他們專屬權利，而比較屌絲級別的公司或非IT公司就沒有辦法處理，是不是這樣的局面無法撼動？ 我想大資料工具庫普及變得非常好用情況就會改觀。

大資料工具庫不能僅包括簡單的工具諸如決策樹，kNN，這些工具都有20、30年的歷史還在用但並不是很有效；我們要的高大上的工具，深度學習、話題模型、協同過濾這些東西在很現代的文獻裡面出現，開始被很高級的公司積極使用， 他們到底有什麼樣的一些技術上的挑戰，防止普通人或者更多大公司使用？

我這裡要提出一個問題：當你這個資料或者是模型大到了從一個機器記憶體裡面溢出，大家希望顯然是這麼一張曲線：我不斷加機器，越加越多能力越高，這是大家的期望。 如果各位開發人員尤其工程人員有實際經歷，我想你會告訴我，當我給你一千台機器後你的能力並沒有增加一千倍；機器有很多的時候，你的資源中各種各樣的時間浪費在沒有用處計算上，比如說通訊、等待、協調這些方面。 因此我們看到的一個曲線是這樣的一個曲線－－我們實際收穫的計算能力並不隨機器增加而增加，而是很快封頂了，甚至跌落了。 對於電腦學家來說，固然去拿大資料來做挖掘，提供資訊，親自做一個資料採礦選手很重要，但是我覺得電腦學家另外一個很重要的任務是提供方法論和工具，把這個曲線從這兒提到這兒，這就是我待會講話中心內容。

我為什麼說現在已有的系統不足以實現我們剛才所希望的功能呢？ 這塊我舉幾個例子。 比如說有很多機器學習的學者，他們顯然對大資料很感興趣，由於本身訓練局限或者是習慣思維緣故，他們對系統知識通常並不瞭解，他們看到一百個機器跟一台機器的差別只不過乘了一百，中間的代價或者是機器的失效幾率他們可以都不太考慮， 所以他們的演算法主要是針對數學上的正確性或者是反覆運算演算法反覆運算次數減少性，但是他們不會鑽研這個演算法到底在一個真實的機器群上怎麼運作；他們會寫這麼一個程式，中間有一句話：「並行運算」，然後就天真的假設這個就開始發生了， 把這些演算法程式放在很多機器上它們就能算好。

實際過程中，我至少看到是這樣一個情況，你去做一個小實驗，去測量用在計算上的時間和用在通訊上的時間，最好結果也無非如此：至少20%的時間花在機器上面，80%的時間花在等待，經常更糟，上面提到那種理想狀態不存在， 所以這些演算法實際上通常無法應用。

另一方面，系統工程師對機器學習或者統計學習原理或者技術並不見得非常精通，他們所需要實現的目標是盡可能實現極高的反覆運算的輸出，修正由於機器造成的一些損耗，所以他們會發展一些非常可靠、非常高通的技術。 但是他們對於機器學習的演算法通常是做了一個非常簡單的假設：我只要把它能夠跑起來，它肯定能跑對，肯定會收斂。 如果系統中還有一個特殊程式設計模型，比如Spark裡面有一個RDD，GraphLab中有一個節點模型，他們就會假設，無論什麼機器學習的演算法都可以轉換成這麼一個模型，這是工程師的任務。 我就不知道各位工程師有沒有試過把話題模型變成RDD或節點模型，這是很困難的，需要對機器學習原理有深刻掌握才能做到。 因此你看不到複雜機器學習在這些系統上的普及應用。

所以系統方面的工作通常簡化了在機器學習理論上的工作，把它變得理想化，最起碼會造成一些資源上的浪費，但更嚴重會造成演算法本身的失敗會發散，你得到結果並沒有用處。 所以總結一下，由於兩方面領域間的隔閡，通常我們在開發已知系統對對方的框架都產生了比較簡單化的假設，實際工作中你喪失了很多機會，也造成了很多錯誤。

理想狀況下有這麼一個途徑，你有很多工和各種硬體設備，咱們中間有一個普世的演算法或者框架，然後這個框架上能夠來支援所有這些機器學習的軟體，然後使用所有已知的硬體，中間這層機器之間的協調、 通訊或者是錯誤處理應該是被抽象化被自動化，作為一個程式師我們不應該掌握去觸碰這些東西。

這個問題到底是在什麼層面上能夠獲得解決呢？ 我首先想指出這絕對不是一個軟體的問題，在設計打造這樣的一個介面的過程中，你不僅要懂得系統設計也要懂得機器學習的理論，而且還要懂得演算法的設計，所以整個需要的技能是相當龐大的一個技術支援。 所以這也就造成了這種問題的困難性，而且它就說明並不是所有人去碰這個問題，風險很大，回報率並不是很高，但總有人在做這樣的事情，有人開發類似的操作平臺或者框架。 我們CMU的團隊正在開展這樣的工作，我待會想跟大家分享一下開發框架中比較有意思的思路和得到的經驗教訓。

這裡首先要研究設計分散式的策略，怎麼做分佈。 當你有多台機器的時候，顯然把任務分佈到每個機器上去，每個機器往前走，把中間結果存在局部的存儲空間，他們完成的時間並不是一樣，保證程式正確性你需要設置等待集合點， 每一臺端點工作機和那個叫做伺服器頭領機握手協同後可以接著往下走。 機器學習演算法有這麼一個特點，不是一次性，需要反復進行反覆運算，這樣就造成困難，在你選擇對於系統的行為採取不同的措施的時候，它會產生不同的結果，有些結果就是像這樣，很多時間浪費在通訊上面，或等待所有端點完成協同， 這能保證你的結果很對，它很慢，但是對。 另一種方法我把通訊協定可以簡單化，讓它不必等待彼此，有時候會得到一個很快的結果，但這種結果經常是一個發散的不正確的一個結果。

Hadoop，在過去被大家認為是一個適合寫並行程式的平臺，但是Hadoop對機器學習的演算法是不是真正適合呢？ 我不知道各位在自己開發過程中有這樣的經歷，我自己在學校裡面或者Facebook做訪問教授的這方面的經歷是相當悲慘：你在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生態系統一個分子，你們可以把它下載以後做自己的開發，也可以使用我們庫中的軟體。 這個專案我最後要感謝我的同事和學生們在這兩年裡面的支援，也感謝各位的關注，謝謝！

更多精彩內容，請關注直播專題 2014中國大資料技術大會(BDTC)  ，新浪微博 @CSDN雲計算 ，訂閱CSDN大資料微信號。