用機器學習的方法來處理大數據，是直接學 Spark，還是重點學習 Hadoop，了解 Spark？

11-26

眾所周知，spark確實有很多方面要優於Hadoop，但是畢竟還不太成熟，我現在（2014-10-13）是研一，兩年後找工作，方向是用機器學習的方法來處理大數據，以後是往工程師的方向發展。那麼問題來了，我是應該直接學習Spark，還是重點學習Hadoop，了解Spark?請分析下這兩種學習方式的利弊。謝謝。

看大家都沒看到機器學習這個關鍵字來答一下
如果是做機器學習的話 hadoop了解點會搭集群知道幾個組件之間的關係，能編寫mr 能用hql語言 pig什麼的都了解點就好今年早些時候mahout已經宣布以後不再提供hadoop支持了轉向spark陣營了而且spark的機器學習庫mllib什麼的也是很強悍的如果是搞機器學習的話重點學spark吧

作者：祝威廉 @ 樂視雲數據，已得到作者的授權。

1.如何基於Spark做機器學習（Spark-Shell其實也算的上即席查詢了）
2.基於Spark做新詞發現（依託Spark的強大計算能力）
3.基於Spark做智能問答（Spark上的演算法支持）

如何基於spark做機器學習

Spark發展到1.5版本，算是全平台了，實時批計算，批處理，演算法庫，SQL，hadoop能做的，基本他都能做，而且做的比Hadoop好。

當然要提及的是，Spark依然是Hadoop生態圈的一員，他替換的也僅僅是MR的計算模型而已。資源調度依賴於Yarn，存儲則依賴於HDFS，是hadoop生態圈的一顆新星（其實算是老星啦）。

Spark-Shell 是個偉大的創新，加上牛逼的Scala語言，寫spark程序就和寫普通的shell腳本（或者類似python程序）一樣容易。問題是，原來的shell，python只能在單機工作，現在你寫的每一行代碼，都被放到了一個幾百台，幾千台的規模上去做了。

以前的統計/機器學習依賴於數據抽樣，抽樣從統計的角度來看，如果足夠隨機，其實可以很精準的反應全集的結果，但事實上往往很難做好隨機，所以通常做出來也會很不準。現在大數據解決了這個問題，但不是通過優化抽樣的隨機來解決，而是通過全量數據來解決。

要解決全量的就需要有強大的處理能力，spark首先具備強大的處理能力，其次SparkShell帶來了傳說中的即席查詢。做演算法的工程師，以前經常是在小數據集上跑個單機，然後看效果不錯，一到全量上，就歇菜了，和單機效果很不一樣。雖然是小數據，但是在你的筆記本上跑你幾個小時，也是很正常的。

但是有了spark後，不一樣了，尤其是有了spark-shell。後面的兩個例子，都完全是在spark-shell上寫就的。邊寫代碼，邊運行，邊看結果。CSDN幾百萬博文就是直接拿全量數據跑，直接看效果。spark 抽樣也很方便，一個sample函數，你想要多少就多少。

幾十個G的博文數據，count一下也就十幾秒，cache了之後幾秒就count完了。所以說，如果docker顛覆了部署，那麼spark-shell 也應該顛覆演算法工程師的日常工作。現在會和一個百度的朋友比，哇，最近spark集群內存有9個T了，對方鄙視的看我一眼：百T的飄過.....

目前Spark已經提供的演算法，用的最多的是貝葉斯，word2vec，線性回歸等。所以這裡，作為演算法工程師，或者分析師，一定要學會用spark-shell。

基於Spark做新詞發現

新詞發現是一個非常有意思的領域，用途非常多。譬如可以構建垂直領域詞庫，自動發現新熱門辭彙。詞庫的重要性不用強調了。基於Spark強大的計算能力，直接對200萬+的博文進行了分析，得到大概八萬詞，包含中文、英文、中英文混合詞。通過凝固度、自由度、詞頻、idf以及重合子串（比如 c1c2c3..cN c2c3..cN-1 這種形態的，我們認為是重合子串，如果詞頻一樣，則都過濾掉，否則留詞頻高的）五個維度進行閾值設置和過濾。事實上，中間結果可以到幾百億，一個不小心就可以把Spark跑死，但是也在這個過程中慢慢對Spark有了更深的理解。最終效果還是不錯的，現在它已經作為我們的基礎詞庫了。

基本上就是用spark計算出詞的五個屬性：凝固度、自由度、詞頻、idf以及重合子串。演算法自然是參考論文的，凝固度、自由度的概念來源於這裡(http://www.matrix67.com/blog/archives/5044) 重合子串能修正一類的問題，但感觸比較深的是，通常某篇論文只會在一個視角去focus 某件事情，所以你需要參考多篇，從不同角度去理解這件事情的解決方式，最後通過實驗綜合，得到一個更好解決方案。參考了兩篇論文，比如凝固度，自由度是出自一篇論文，而重合子串則來自另外一篇論文，然後自己觀察實際數據，添加了很多規則，才得到最後的結果。

一說到演算法，大概很多人心裡就是想著，把數據轉化為演算法需要的格式，然後丟給現成的演算法跑，跑著就出結果，或者出模型，然後反覆嘗試，直到得到你認為能接受的或者最優的結果。可是如果你真的做這件事情，就發現完全不是那樣子啊，需要注意的細節太多了。

新詞發現沒有現成的工具包，所以完全自己寫了。第一步，你要獲取語料。這容易，基於現有的平台，資源中心挑出了200萬篇文章id，然後根據id到數據網關獲取title，body欄位。這個基於現有的平台，也就一個SQL + 幾行Scala代碼就搞定的事情。

SQL 其實就是用Hive 生成一個200萬博文id列表。Scala代碼也就幾行。
因為我們的新詞發現是沒有詞典的，需要枚舉所有組合，然後通過一定的規則判定這是不是一個詞。比如『我是天才』，就這四個字，組合有，『我是』，『我是天』，『我是天才』，『是天』，『是天才』，『天才』。你想想，200萬篇文章，這種組合得多誇張，問題是你還要接著給這些組合做計算呢。這個演算法可沒告訴你怎麼處理的，你只能自己去想辦法。看到了，真正你做演算法的過程中，不只是實現，你需要面對的問題特別多，是怎麼做的呢？

將所有html標籤替換成空格。
通過小空格將一個大文本切分成無數小文本塊。
我們認為一個詞的長度最長不能超過5個字。
對每個小文本塊再抽取出中文，中英文，英文。
將一些特殊字元，類似「！￥……（）+｛｝【】的呀啊阿哎吧和與兮呃唄咚咦喏啐喔唷嗬嗯噯你們我他她，這是由於」這些不可能成詞的字元先去掉。處理的過程中，你可能需要寫中文，英文，中英文的抽取方法。

通過上面的五個處理，你計算規模會小非常多。如果不這樣處理，估計再大內存都能讓你歇菜。接著就是按論文里的規則做計算了，比如算詞的凝固度，算重合子串。這裡面還會遇到很多性能，或者內存的坑，比如Spark里的groupByKey，reduceByKey。一開始用了groupByKey，歇菜了，內存直接爆了，為啥，你要去研究groupByKey到底是怎麼實現的，一個詞出現幾十萬次，幾百萬次都很正常啊，groupByKey受不了這種情況。所以你得用reduceByKey。

在spark 1.5里，已經支持動態調整worker數目了。之前做這個的時候，會開的比較大，如果集群規模比較小，可能會影響別人，而且用完要趕緊釋放，但釋放了重新再起，也還是很麻煩的，現在好很多了。

很好，實現了演算法後得到了結果，可人家沒告訴你，他貼出來的結果都是好看的，那是因為他是按頻次排的，但如果你拉到最後看，結果就不太好看了。這個時候你就需要觀察數據了，然後提出新的規則，比如最後得到的中文詞結果，用了一些簡單規則過濾下，都是哪些呢？凡是詞裡面包含『或』的，或者"就"的或者上面羅列的，都認為這個詞是沒有意義的，經過這個簡單規則一過濾，效果好非常多，很多沒什麼意義的生活詞，或者不成詞的詞就被去掉了。中文，英文，中英文混合，加了很多這種規則，最終才過濾出了八萬計算機辭彙。

在做上面的方案時，基本上就是在spark-shell中完成的。其實有點像ngram，就是對所有字元串做所有枚舉，只是會限制最終成詞的長度。這裡中文是最長五個字，英文是四個字，中英文一塊的是五個字，接著要算出每個詞左右連接字。具體的演算法大家可以參考http://www.matrix67.com/blog/archives/5044 這篇文章。而且如果有spark環境的，也可以嘗試自己實現一把。

重合子串，是這個演算法的一個比較大的問題，比如 c1c2c3...cN c2c3...cN-1，因為是從統計的方案做的，c1c2c3…cN c2c3...cN-1 他們兩算出來的分數可能就是一樣的，所以如果我們發現他們的分值或者出現頻率是一樣的，就可以直接排除掉了。

基於Spark做智能問答

其實做的事情非常簡單：

比較兩個標題的相似度

如果我們能知道兩個句子說的其實是一件事情，那麼就能打通各產品的互通鴻溝了。之前試水的項目是打通問答到博客的通道。具體效果大家可以看看CSDN的問答產品，裡面的機器人，背後用的演算法就是這套。當用戶問一個問題，機器人就會到博客里去找有沒有這個問題的答案，或者有沒有可以做參考的。比較神奇的是，之前有個在問答活躍的人也特別喜歡貼博客鏈接作為回答，我們對比了機器人和他的結果，發現機器人和他貼的差不多。

對於擁有內容的網站來說，這個技術還是非常重要的，比如CSDN，有論壇，博客，資訊，雜誌等等，都是內容的載體。用戶在問答頻道里問的一個問題，其實在博客，在論壇早就已經有答案了。具體做法是透過word2vec解決一意多詞的問題。接著將詞轉換為句子向量。這樣任何一個問題都可以轉換為一個向量。同理任何一篇博文的標題也可以轉化為一個向量。

word2vec，採用的數據來源用的搜索引擎的數據。大部分內容類的網站，他的PV應該有相當一部分來自搜索引擎，其實搜索引擎對這些網站來說，就是一個大的寶藏。因為搜索的query串，都是用戶遇到的問題，然後指向到解決這些問題的內容上。內容上直接拿用戶的query作為word2vec的語料，得到一些常用的提問詞，每個詞用一個50維度的向量表示。當然，我們不可能真的讓一個問題和幾百萬內容直接做比較，一個簡單有效的方式是，先通過搜索引擎去搜，然後將搜索得到top100結果做向量計算得到新的得分。基本相似度大於0.9 的可以算作答案。大於0.7的就可以作為參考答案了。站內搜索服務應該是標配了，所以對大部分網站應該不是問題。

對了，這裡有個問題是：word2vec計算出來的是用一個稠密的定長向量表示詞，做法是直接把一個句子的里的詞的向量按位做加法，重新得到一個新的向量作為句子的向量。當然，這種方式也是有缺陷，也就是句子越長，信息損耗越大。但是做這種標題性質的相似度，效果出奇的好，那種句子里很多辭彙不相同的，它都能算出他們很相似來，這是因為word2vec可以算出不同辭彙之間關係。

好了，具體的內容就分享到這裡。

總結

作為數據分析師，演算法工程師，請好好利用spark-shell。 Spark社區為了滿足數據分析師，演算法工程師，其實也做了非常多的工作，包括Python, R語言的支持。15年社區努力做的DataFrame其實就是從R里借鑒過來的，也方便R數據科學家方便的遷移過來。大家都應該與時俱進，不要只玩單機了。
機器學習平台的構建，可以參考這篇文章從內容/用戶畫像到如何做演算法研發裡面對平台方面一些看法。

課程QA

Q：如何從0開始系統學習spark，最後轉行？
A：學會scala就行，scala是一門具有學院派氣息的語言，你可以把它寫的像python，ruby那樣，也可以寫的想java那樣方方正正，也可以學習python，spark支持python但是可能有些功能用不了，用了一天的時間把Scala的官方教程看了，基本就能上手了。

Q：建議不做RAID的原因是什麼？
A：比如例子提到的默認HDFS的所有數據都會存三份，可以保證數據位於不同的伺服器上，不同的磁碟上，所以無需RAID。

Q：很多沒什麼意義的生活詞，或者不成詞的詞，這些詞是怎樣得到的？也是分析出來的？
A：因為用的都是統計的一些方式，所以肯定會有很多無意義的辭彙，假設我們現在得到的辭彙幾何是A,接著去爬了一些新聞和生活的類的博客，然後用程序去跑一遍得到一批辭彙B，然後A-B 就能得到一拼更純正的計算機辭彙。

Q：內存要調到多大才能不會爆掉？是不是有什麼比例？
A：你不管調到多大，如果用的不好也都有可能，groupByKey這個會有很大的內存問題，他形成的結構式 key-&> value1，value2，value3…...valuen，這種是非常消耗存儲空間的額，大家使用spark的時候，序列化最好使用kyro，性能確實好太多，一個worker 會同時配置可以使用的內存和cpu，這個時候一定要搭配好。比如你允許work使用5個cpu，那內存最好能配到10G，如果內存過小，你的cpu會大量浪費在GC上，一般是單個worker 12G內存，可使用4核。

Q：直接把一個句子的里的詞的向量按位做加法，這是如何加？能舉個例子不？
A：比如考慮一個三維向量： A[1，3，5] B[1，3，7]，現在有個句子是AB兩個片語成，則對應的向量為A+B=[2,6,12]

Q：還有中文分詞是用的什麼方法?可否分享代碼不啊？
A：這裡是無監督分詞，所以不用中文分詞，按維度疊加，才能保證都是相同長度的向量，而且中文分詞這塊，一個同事的 ansj分詞，還是做的不錯的。

Q：一些分詞方法具有新詞發現的功能，比如crf，樓主是比較過效果么？而且我記得matrix67這個演算法複雜度還是很高的？
A：matrix67 這個演算法複雜度還是非常高的，你實際操作就會發現計算量，內存使用量都很大，crf等據我所知，還都是需要依賴詞表的，matrix67的這個方式，完全不需要任何先驗的東西。

Q：為什麼一個詞要用50維度表示？這能舉個例子不？這裡不太明白。
A：理論上維度越長越好，當時是隨意試了一個值。發現效果其實已經可以了，這是一個可以調整的值，比如你可以分別生成50，150，300維度的，然後試試那個效果好。

Hadoop只不過是Google放出來的一種分散式計算模型而已，旨在使用廉價的機器搭建起可線性擴展的分散式計算框架，沒有任何神秘之處，我想如果你想成為一流的大數據專家，這不應該成為你的障礙。
首先，分散式計算的實現方式有N種，Hadoop和Spark本質上都是為了解決一個分散式計算效率問題而誕生的兩種計算框架，適用於不同應用場景。Hadoop其實效率很低，Google內部現在已經逐漸有新的替代方案了。Hadoop適合用於數據密集型但對時間要求不高的場景（長時間的大規模離線計算，如log分析），而機器學習裡面常常面臨迭代問題，Hadoop在這種迭代演算法面前十分力不從心（主要受到網關帶寬和磁碟IO瓶頸限制），於是有了Spark這種RDD全內存式的計算模型。Spark適合於機器學習的迭代計算場景（當然它底層也是可以配合Hadoop的HDFS的），計算效率較高，但是是以吃內存為代價的。
說到這裡，當然還有其他很多分散式框架了。比如在CPU計算密集型的分散式場景中，MPI就是一個很好的選擇。很多大公司一般也會根據自己的業務場景的來設計自己的分散式框架，像百度少帥李沐在研究的一個項目Parameter Server http://parameterserver.org/，也是一個不錯的分散式框架啊，也是解決機器學習的分散式計算問題。
所以，歸根到底不要拘束於所謂各種流行的框架，工程學的精髓是基礎紮實、隨機應變、根據不同場景創新性的解決問題。大公司的技術精英都是可以帶隊伍寫自己的分散式框架的。從我個人的經歷來看，你還是先專註於演算法，搞清楚各種演算法的本質和適用條件，為以後實戰做基礎，當然可以先學習Hadoop的MapReduce模型，然後進階學習Spark。等你牛逼了，這些工具都是浮雲，你可以開發自己的分散式框架來秒殺這些工具。

很難理解這為什麼是個異或關係的選擇題，hadoop也好spark也好，如果只是跑起來演算法的話，根本不需要很長的學習時間，除非你要深入弄懂底層機制和原理，但是目測你是要做機器學習，所以這就不是個問題。
其實我個人更建議把機器學習學紮實一些，多看書多讀論文，而不是花時間在深入學習hadoop、spark上面。如果我能重新回到學生時代，我要做的事就是把icml、nips的近幾年論文都認真讀一遍。
另外從我個人面試的喜好來說，我偏向於聰明、基礎紮實、邏輯清晰的應聘同學。至於會不會用spark，會用是加分項，如果不會，我不減分。就算再精通spark，如果不聰明或基礎不紮實或邏輯不清晰我也不要。什麼是基礎紮實？舉個栗子，機器學習方向，如果你能說清楚Logistic Regression的前世今生來龍去脈，就是基礎紮實。spark什麼的，我教你用兩次你就會了。但是能說清楚Logistic Regression的人，可很難得！

都得學，題主是網工程方向而不是數據科學家方向發展，所以更應該注重工程實現。

Spark和Hadoop本質都是batch process，很難做model distribution，適用場景是data distribution。
Parameter server比較適用於model distribution

都得會

上手直接spark 看到有人拿mapreduce來說事我2天就寫一個mapreduce workflow好么，這種基本簡單的東西不應該和hadoop /spark混為一談不是一個數量級的樓主問的是架構，學架構無非是看那個community 大以及發展趨勢好至於學習成本都是一樣的現在spark絕對要比hadoop有前途的多。題主學什麼架構一定要看中架構的所處生態環境，當年學windowsphone 的和學IOS的幾年後工資差一倍好么。。有些人居然說hadoop是基礎因為要學他的分散式計算和分散式存儲？那你還不如學slurm 呢人家那才是鼻祖好么並且這些東西都只要掌握概念就好根本不需要深挖每家公司的實現都可能不一樣但是大體思路是一樣的。大神都用slurm自己寫mapreduce和分散式計算架構好么。
並且如果題注要做learning的話現在最好的learning 是deeplearning spark 做deep的比hadoop去強多了好么。
總結：讀幾遍bigData 或者large-scale machine learning 的論文，找那些review studies 和大神寫的survey。了解架構的思路和設計初衷，具體實現直接上手spark，忽略noobs的回答謝謝。
你要是足夠牛我建議你用slurm自己寫，這些技術真的沒啥難的好么，比deep-learning的演算法簡單太多了。。

樓主前半句意思是要學習Machine Learning的意思
後半句就要在Spark和Hadoop里做選擇
不知道為何你覺得Machine Learning方向非要在這兩個里選一個呢？
Spark和Hadoop是兩個軟體或者說工具，可以用來處理比較大規模的數據。但這個本質上不是機器學習的核心。

如果說機器學習是寫文章，你可以用Notepad寫，也可以用Word寫。但如果你說，
我想要學習寫文章，我是先研究Notepad呢，還是重點研究Word呢？這是不是有點奇怪？

我覺得要寫文章，先得練好文筆吧。

謝邀，題主方向是數據工程師還是數據科學家？科學家的話研究什麼平台什麼意義不大，主要是掌握機器學習各種演算法，到底怎麼處理不是科學家關心的，懂些優化方式，了解為什麼這樣對大數據處理性能好。數據工程師的話工作要掌握的比較多，主要基本功要紮實，java, python要熟悉，我建議還從hadoop學起，hdfs,hive是重點，對數據工程師來說部署什麼，pipeline，etl什麼是重點

我覺得都要學，先學hadoop，再學spark。現在做大數據的機器學習，不管存儲還是計算都要用分散式技術，spark雖然快，但它還主要是分散式計算框架，數據存儲還是要靠hadoop的dfs。另外，spark也可以運行在hadoop的yarn之上。很多地方都給出了hdfs&>yarn&>&>spark&>spark mllib這樣的技術路線。至於hadoop的mapreduce需不需要學習的問題，我覺得雖然spark的rdd是mapreduce模型的超集，但hadoop的mapreduce還是要學習一下，不然你怎麼理解rdd的精髓呢？還有把hadoop的dfs和yarn搞清楚了，它的mapreduce就沒剩多少內容了，yarn本身就是從老的mapreduce中分離出來的，mapreduce的計算向數據移動也是基於dfs實現的。

從大數據領域來看, 兩者不是替代關係, 有幾個基礎的組件都得學, hdfs, yarn, hbase, spark core, mapreduce

搞機器學習重點是機器學習演算法和它背後的數學，底下分散式框架一波一波換，機器學習演算法原理變化不大；其次是分散式計算模型下如何實現這些演算法，有什麼限制；再其次是hadoop和spark這些分散式框架本身的設計和實現。

我想你是指mapreduce而不是hadoop吧，hadoop包括yarn mapreduce2 和HDFS。
Hadoop已經被spark所取代這句話其實並不準確，應該說是Hadoop中是mapreduce逐漸被淘汰，因為一個比他更靈活的框架spark的出現。
換句話說就是spark和Hadoop不是一個level上的東西。而且雖然你現在不用在去寫MR，但是好多技術本質上還是用的MR，比如sqoop從sql中取數據到HDFS中或者把HDFS中的數據傳到SQL中，它本質還是幫你寫一個MR然後在Hadoop中運行。還有另外一種對HDFS中存儲的數據進行應用的技術叫Hive，雖然你操作Hive是時候不用寫一句Java代碼，但是他這個框架還是把你的HiveQL轉換成Java用mapreduce實現。
被Hive，pig這些技術所用存儲載體還是HDFS，而HDFS是Hadoop的一部分。所以Hadoop是一定要了解的。
對於mapreduce我覺得可以不用了解的很清楚他的各個配置各個函數比如resourcemanager怎麼分配任務和shuffle實現原理這些吊東西，但是Wordcount和findingfriends這種mapreduce helloWord程序還是要寫一寫。

好奇題主工作找的怎麼樣了啊？

spark吧，hadoop了解下就行，現在各大互聯網公司，機器學習這類迭代運算大多都在用spark了，spark的mlib發展的非常快的。

Spark vs Hadoop 就好比 Nginx vs Linux，Nginx 粉絲跟 Apache &< 2.4 測試一把欣喜若狂，大呼 Linux 已死，然後不明真相的群眾跟著喊「烏拉！」。

先學hadoop，再學spark。說到底這些都只是工具而已，關鍵是利用工具來解決問題的能力。

學yarn

spark是建立在hadoop這個巨人的肩膀上的產物，建議先學習hadoop,對於學習spark有幫助！spark有自帶機器學習演算法庫，可以直接調用！