這篇內(nèi)容基于我去年的一些感悟?qū)懙?，但是今年才在Stuq 的微信群做的分享。從技術(shù)角度而言，對(duì)Spark的掌握和使用還是顯得很手生的。但是今天一位做數(shù)據(jù)分析相關(guān)的朋友說，受這篇內(nèi)容影響，他接受了Spark-Shell作為數(shù)據(jù)分析的工具，簡單幾個(gè)命令，輕松處理幾千萬行數(shù)據(jù)。于是我就重新整理了下這篇文章。
Hi，大家好！我是祝威廉，本來微博也想叫祝威廉的，可惜被人占了，于是改名叫·祝威廉二世。然后總感覺哪里不對(duì)。目前在樂視云數(shù)據(jù)部門里從事實(shí)時(shí)計(jì)算，數(shù)據(jù)平臺(tái)、搜索和推薦等多個(gè)方向。曾從事基礎(chǔ)框架，搜索研發(fā)四年，大數(shù)據(jù)平臺(tái)架構(gòu)、推薦三年多，個(gè)人時(shí)間現(xiàn)專注于集群自動(dòng)化部署，服務(wù)管理，資源自動(dòng)化調(diào)度等方向。
今天會(huì)和大家分享三個(gè)主題。 不過限于時(shí)間，第三個(gè)只是會(huì)簡單提及下， 等未來有機(jī)會(huì)可以更詳細(xì)的分享。
** 1.如何基于Spark做機(jī)器學(xué)習(xí)（Spark-Shell其實(shí)也算的上即席查詢了）**
** 2.基于Spark做新詞發(fā)現(xiàn)（依托Spark的強(qiáng)大計(jì)算能力）**
** 3.基于Spark做智能問答（Spark上的算法支持）**
其中這些內(nèi)容在我之前寫的一篇描述工作經(jīng)歷的文章 我的工作 都有提及到，當(dāng)然，可能不如今天分享的這么詳細(xì)。
如何基于spark做機(jī)器學(xué)習(xí)
Spark發(fā)展到1.5版本，算是全平臺(tái)了，實(shí)時(shí)批計(jì)算，批處理，算法庫，SQL，hadoop能做的，基本他都能做，而且做的比Hadoop好。
當(dāng)然，這里我要提及的是，Spark依然是Hadoop生態(tài)圈的一員，他替換的也僅僅是MR的計(jì)算模型而已。資源調(diào)度依賴于Yarn，存儲(chǔ)則依賴于HDFS，是hadoop生態(tài)圈的一顆新星（其實(shí)算是老星啦）。
我之前寫文章說，Spark-Shell 是個(gè)偉大的創(chuàng)新，加上牛逼的Scala語言，寫spark程序就和寫普通的shell腳本（或者類似python程序）一樣容易。問題是，原來的shell，python只能在單機(jī)工作，現(xiàn)在你寫的每一行代碼，都被放到了一個(gè)幾百臺(tái)，幾千臺(tái)的規(guī)模上去做了。
以前的統(tǒng)計(jì)/機(jī)器學(xué)習(xí)依賴于數(shù)據(jù)抽樣，抽樣從統(tǒng)計(jì)的角度來看，如果足夠隨機(jī)，其實(shí)可以很精準(zhǔn)的反應(yīng)全集的結(jié)果，但事實(shí)上往往很難做好隨機(jī)，所以通常做出來也會(huì)很不準(zhǔn)?，F(xiàn)在大數(shù)據(jù)解決了這個(gè)問題，但不是通過優(yōu)化抽樣的隨機(jī)來解決，而是通過全量數(shù)據(jù)來解決。
要解決全量的就需要有強(qiáng)大的處理能力，spark首先具備強(qiáng)大的處理能力，其次SparkShell帶來了傳說中的即席查詢。做算法的工程師，以前經(jīng)常是在小數(shù)據(jù)集上跑個(gè)單機(jī)，然后看效果不錯(cuò)，一到全量上，就歇菜了，和單機(jī)效果很不一樣。雖然是小數(shù)據(jù)，但是在你的筆記本上跑你幾個(gè)小時(shí)，也是很正常的。
但是有了spark后，不一樣了，尤其是有了spark-shell。 我后面的兩個(gè)例子，都完全是在spark-shell上寫就的。邊寫代碼，邊運(yùn)行，邊看結(jié)果。我研究的CSDN幾百萬博文的時(shí)候，就是直接拿全量數(shù)據(jù)跑，直接看效果。spark 抽樣也很方便，一個(gè)sample函數(shù)，你想要多少就多少。
幾十個(gè)G的博文數(shù)據(jù)，count一下 也就十幾秒，cache了之后 幾秒就count完了。所以說，如果docker顛覆了部署，那么spark-shell 也應(yīng)該顛覆算法工程師的日常工作。我現(xiàn)在會(huì)和一個(gè)百度的朋友比，哇，最近我們spark集群內(nèi)存有9個(gè)T了，對(duì)方鄙視的看我一眼：百T的飄過.....
目前Spark已經(jīng)提供的算法，我用的最多的是貝葉斯，word2vec，線性回歸等。所以這里，作為算法工程師，或者分析師，一定要學(xué)會(huì)用spark-shell。
基于Spark做新詞發(fā)現(xiàn)
新詞發(fā)現(xiàn)是一個(gè)非常有意思的領(lǐng)域，用途非常多。譬如可以構(gòu)建垂直領(lǐng)域詞庫，自動(dòng)發(fā)現(xiàn)新熱門詞匯。詞庫的重要性我不用強(qiáng)調(diào)了?；赟park強(qiáng)大的計(jì)算能力，我直接對(duì)200萬+的博文進(jìn)行了分析，得到大概八萬詞，包含中文、英文、中英文混合詞。通過凝固度、自由度、詞頻、idf以及重合子串（比如 c1c2c3..cN c2c3..cN-1 這種形態(tài)的，我們認(rèn)為是重合子串，如果詞頻一樣，則都過濾掉，否則留詞頻高的）五個(gè)維度進(jìn)行閾值設(shè)置和過濾。事實(shí)上，中間結(jié)果可以到幾百億，一個(gè)不小心就可以把Spark跑死，但是也在這個(gè)過程中慢慢對(duì)Spark有了更深的理解。 最終效果還是不錯(cuò)的，現(xiàn)在它已經(jīng)作為我們的基礎(chǔ)詞庫了。
基本上就是用spark計(jì)算出詞的五個(gè)屬性： 凝固度、自由度、詞頻、idf以及重合子串。算法自然是參考論文的，凝固度、自由度的概念來源于這里(http://www.matrix67.com/blog/archives/5044) 重合子串能修正一類的問題，但我感觸比較深的是，通常某篇論文只會(huì)在一個(gè)視角去focus 某件事情，所以你需要參考多篇，從不同角度去理解這件事情的解決方式，最后通過實(shí)驗(yàn)綜合，得到一個(gè)更好解決方案。我參考了兩篇論文，比如凝固度，自由度是出自一篇論文，而重合子串則來自另外一篇論文，然后自己觀察實(shí)際數(shù)據(jù)，添加了很多規(guī)則，才得到最后的結(jié)果。
一說到算法，大概很多人心里就是想著，恩，我把數(shù)據(jù)轉(zhuǎn)化為算法需要的格式，然后丟給現(xiàn)成的算法跑，跑著就出結(jié)果，或者出模型，然后反復(fù)嘗試，直到得到你認(rèn)為能接受的或者最優(yōu)的結(jié)果。我一開始也是這么想的，可是如果你真的做這件事情，就發(fā)現(xiàn)完全不是那樣子啊，需要注意的細(xì)節(jié)太多了。
新詞發(fā)現(xiàn)沒有現(xiàn)成的工具包，所以完全自己寫了。第一步，你要獲取語料。這容易，基于現(xiàn)有的平臺(tái)，我從我們資源中心挑出了200萬篇文章id，然后根據(jù)id到數(shù)據(jù)網(wǎng)關(guān)獲取title，body字段。這個(gè)基于現(xiàn)有的平臺(tái)，也就一個(gè)SQL + 幾行Scala代碼就搞定的事情。
SQL 其實(shí)就是用Hive 生成一個(gè)200萬博文id列表。Scala代碼也就幾行。
因?yàn)槲覀兊男略~發(fā)現(xiàn)是沒有詞典的，需要枚舉所有組合，然后通過一定的規(guī)則判定這是不是一個(gè)詞。比如 ‘我是天才’，就這四個(gè)字， 組合有，‘我是’，‘我是天’，‘我是天才’，‘是天’，‘是天才’，‘天才’ 。你想想，200萬篇文章，這種組合得多夸張，問題是你還要接著給這些組合做計(jì)算呢。這個(gè)算法可沒告訴你怎么處理的，你只能自己去想辦法?？吹搅耍嬲阕鏊惴ǖ倪^程中，不只是實(shí)現(xiàn)，你需要面對(duì)的問題特別多，我是怎么做的呢？
- 將所有html標(biāo)簽替換成空格。
- 通過小空格將一個(gè)大文本切分成無數(shù)小文本塊。
- 我們認(rèn)為一個(gè)詞的長度最長不能超過5個(gè)字。
- 對(duì)每個(gè)小文本塊再抽取出中文，中英文，英文。
- 將一些特殊字符，類似“?。ぁǎ?｛｝【】的呀啊阿哎吧和與兮呃唄咚咦喏啐喔唷嗬嗯噯你們我他她，這是由于” 這些不可能成詞的字符先去掉。處理的過程中，你可能需要寫中文，英文，中英文的抽取方法。
通過上面的五個(gè)處理，你計(jì)算規(guī)模會(huì)小非常多。如果不這樣處理，估計(jì)再大內(nèi)存都能讓你歇菜。接著就是按論文里的規(guī)則做計(jì)算了，比如算詞的凝固度，算重合子串。這里面還會(huì)遇到很多性能，或者內(nèi)存的坑，比如Spark里的groupByKey，reduceByKey。 我一開始省事，用了groupByKey，歇菜了，內(nèi)存直接爆了，為啥，你要去研究groupByKey到底是怎么實(shí)現(xiàn)的，一個(gè)詞出現(xiàn)幾十萬次，幾百萬次都很正常啊，groupByKey受不了這種情況。所以你得用reduceByKey。
在spark 1.5里，已經(jīng)支持動(dòng)態(tài)調(diào)整worker數(shù)目了。我之前做這個(gè)的時(shí)候，會(huì)開的比較大，如果集群規(guī)模比較小，可能會(huì)影響別人，而且用完要趕緊釋放，但釋放了重新再起，也還是很麻煩的，現(xiàn)在好很多了。
很好，實(shí)現(xiàn)了算法后得到了結(jié)果，可人家沒告訴你，他貼出來的結(jié)果都是好看的，那是因?yàn)樗前搭l次排的，但如果你拉到最后看，結(jié)果就不太好看了。這個(gè)時(shí)候你就需要觀察數(shù)據(jù)了，然后提出新的規(guī)則，比如最后得到的中文詞結(jié)果，我用了一些簡單規(guī)則過濾下，都是哪些呢？凡是詞里面包含‘或’的，或者'就'的或者上面羅列的，我都認(rèn)為這個(gè)詞是沒有意義的，經(jīng)過這個(gè)簡單規(guī)則一過濾，效果好非常多，很多沒什么意義的生活詞，或者不成詞的詞就被去掉了。中文，英文，中英文混合，我都加了很多這種規(guī)則，最終才過濾出了八萬計(jì)算機(jī)詞匯。
我在做上面的方案時(shí)，基本上就是在spark-shell中完成的。其實(shí)有點(diǎn)像ngram，就是對(duì)所有字符串做所有枚舉，只是會(huì)限制最終成詞的長度。我這里中文是最長五個(gè)字，英文是四個(gè)字，中英文一塊的 是五個(gè)字，接著要算出每個(gè)詞左右連接字。具體的算法大家可以參考http://www.matrix67.com/blog/archives/5044 這篇文章。而且如果有spark環(huán)境的，也可以嘗試自己實(shí)現(xiàn)一把。
重合子串，是這個(gè)算法的一個(gè)比較大的問題，比如 c1c2c3...cN c2c3...cN-1，因?yàn)槭菑慕y(tǒng)計(jì)的方案做的，c1c2c3…cN c2c3...cN-1 他們兩算出來的分?jǐn)?shù)可能就是一樣的，所以如果我們發(fā)現(xiàn)他們的分值或者出現(xiàn)頻率是一樣的，就可以直接排除掉了。
基于Spark做智能問答
其實(shí)我做的智能問答算不上智能問答，但是內(nèi)部一開始這么叫的，所以也就這么順帶叫下來了。 其實(shí)做的事情非常簡單：
****比較兩個(gè)標(biāo)題的相似度****
如果我們能知道兩個(gè)句子說的其實(shí)是一件事情，那么就能打通各產(chǎn)品的互通鴻溝了。之前試水的項(xiàng)目是打通問答到博客的通道。具體效果大家可以看看CSDN的問答產(chǎn)品，里面的機(jī)器人，背后用的算法就是這套。當(dāng)用戶問一個(gè)問題，機(jī)器人就會(huì)到博客里去找有沒有這個(gè)問題的答案，或者有沒有可以做參考的。 比較神奇的是，之前有個(gè)在問答活躍的人也特別喜歡貼博客鏈接作為回答，我們對(duì)比了機(jī)器人和他的結(jié)果，發(fā)現(xiàn)機(jī)器人和他貼的差不多。
對(duì)于擁有內(nèi)容的網(wǎng)站來說，這個(gè)技術(shù)還是非常重要的，比如CSDN，有論壇，博客，資訊，雜志等等，都是內(nèi)容的載體。用戶在問答頻道里問的一個(gè)問題，其實(shí)在博客，在論壇早就已經(jīng)有答案了。具體做法是透過word2vec解決一意多詞的問題。接著將詞轉(zhuǎn)換為句子向量。這樣任何一個(gè)問題都可以轉(zhuǎn)換為一個(gè)向量。同理任何一篇博文的標(biāo)題也可以轉(zhuǎn)化為一個(gè)向量。
word2vec，采用的數(shù)據(jù)來源，我是用的搜索引擎的數(shù)據(jù)。大部分內(nèi)容類的網(wǎng)站，他的PV應(yīng)該有相當(dāng)一部分來自搜索引擎，其實(shí)搜索引擎對(duì)這些網(wǎng)站來說，就是一個(gè)大的寶藏。因?yàn)樗阉鞯膓uery串，都是用戶遇到的問題，然后指向到解決這些問題的內(nèi)容上。內(nèi)容上，所以我直接拿用戶的query作為word2vec的語料，得到一些常用的提問詞，每個(gè)詞用一個(gè)50維度的向量表示。當(dāng)然，我們不可能真的讓一個(gè)問題和幾百萬內(nèi)容直接做比較，一個(gè)簡單有效的方式是，先通過搜索引擎去搜，然后將搜索得到top100結(jié)果做向量計(jì)算得到新的得分。 基本相似度大于0.9 的可以算作答案。大于0.7的就可以作為參考答案了。站內(nèi)搜索服務(wù)應(yīng)該是標(biāo)配了，所以對(duì)大部分網(wǎng)站應(yīng)該不是問題。
對(duì)了，這里有個(gè)問題是：word2vec計(jì)算出來的是用一個(gè)稠密的定長向量表示詞，我的做法是直接把一個(gè)句子的里的詞的向量按位做加法，重新得到一個(gè)新的向量作為句子的向量。當(dāng)然，這種方式也是有缺陷，也就是句子越長，信息損耗越大。但是做這種標(biāo)題性質(zhì)的相似度，效果出奇的好，那種句子里很多詞匯不相同的，它都能算出他們很相似來，這是因?yàn)閣ord2vec可以算出不同詞匯之間關(guān)系。
好了，具體的內(nèi)容就分享到這里。
總結(jié)
下面是我的幾個(gè)觀點(diǎn)：
作為數(shù)據(jù)分析師，算法工程師，請(qǐng)好好利用spark-shell。 Spark社區(qū)為了滿足數(shù)據(jù)分析師，算法工程師，其實(shí)也做了非常多的工作，包括Python, R語言的支持。15年社區(qū)努力做的DataFrame其實(shí)就是從R里借鑒過來的，也方便R數(shù)據(jù)科學(xué)家方便的遷移過來。我覺得大家都應(yīng)該與時(shí)俱進(jìn)，不要只玩單機(jī)了。
機(jī)器學(xué)習(xí)平臺(tái)的構(gòu)建，可以參考我這篇文章從內(nèi)容/用戶畫像到如何做算法研發(fā) 里面有我對(duì)平臺(tái)方面一些看法。
課程Q&A
Q： 如何從0開始系統(tǒng)學(xué)習(xí)spark，最后轉(zhuǎn)行？
A： 學(xué)會(huì)scala就行，scala是一門具有學(xué)院派氣息的語言，你可以把它寫的像python，ruby那樣，也可以寫的想java那樣方方正正，也可以學(xué)習(xí)python，spark支持python但是可能有些功能用不了，用了一天的時(shí)間把Scala的官方教程看了，基本就能上手了。
Q：建議不做RAID的原因是什么？
A： 比如我例子提到的默認(rèn)HDFS的所有數(shù)據(jù)都會(huì)存三份，可以保證數(shù)據(jù)位于不同的服務(wù)器上，不同的磁盤上，所以無需RAID。
**Q：很多沒什么意義的生活詞，或者不成詞的詞，這些詞是怎樣得到的？也是分析出來的？ **
A： 因?yàn)橛玫亩际墙y(tǒng)計(jì)的一些方式，所以肯定會(huì)有很多無意義的詞匯，假設(shè)我們現(xiàn)在得到的詞匯幾何是A,接著我去爬了一些新聞和生活的類的博客，然后用程序去跑一遍得到一批詞匯B，然后A-B 就能得到一拼更純正的計(jì)算機(jī)詞匯。
Q：內(nèi)存要調(diào)到多大才能不會(huì)爆掉？是不是有什么比例？
A： 你不管調(diào)到多大，如果用的不好 也都有可能，groupByKey這個(gè)會(huì)有很大的內(nèi)存問題，他形成的結(jié)構(gòu)式 key-> value1，value2，value3…...valuen，這種是非常消耗存儲(chǔ)空間的額，大家使用spark的時(shí)候，序列化最好使用kyro，性能確實(shí)好太多，一個(gè)worker 會(huì)同時(shí)配置可以使用的內(nèi)存和cpu，這個(gè)時(shí)候一定要搭配好。比如你允許work使用5個(gè)cpu，那內(nèi)存最好能配到10G，如果內(nèi)存過小，你的cpu會(huì)大量浪費(fèi)在GC上，我一般是單個(gè)worker 12G內(nèi)存 ，可使用4核。
Q：直接把一個(gè)句子的里的詞的向量按位做加法，這是如何加？能舉個(gè)例子不？
A：比如 考慮一個(gè)三維向量： A[1，3，5] B[1，3，7]，現(xiàn)在有個(gè)句子 是AB兩個(gè)詞組成，則對(duì)應(yīng)的向量為A+B=[2,6,12]
Q：還有中文分詞是用的什么方法?可否分享代碼不啊？
A：這里是無監(jiān)督分詞，所以不用中文分詞，按維度疊加，才能保證都是相同長度的向量，而且中文分詞這塊，我推薦我一個(gè)同事的 ansj分詞，還是做的不錯(cuò)的。
Q：一些分詞方法具有新詞發(fā)現(xiàn)的功能，比如crf，樓主是比較過效果么？而且我記得matrix67這個(gè)算法復(fù)雜度還是很高的？
A：matrix67 這個(gè)算法復(fù)雜度還是非常高的，你實(shí)際操作就會(huì)發(fā)現(xiàn)計(jì)算量，內(nèi)存使用量都很大，crf等據(jù)我所知，還都是需要依賴詞表的，matrix67的這個(gè)方式，完全不需要任何先驗(yàn)的東西。
**Q：為什么一個(gè)詞要用50維度表示？ 這能舉個(gè)例子不？ 這里不太明白。 **
A：理論上維度越長越好，我當(dāng)時(shí)是隨意試了一個(gè)值。發(fā)現(xiàn)效果其實(shí)已經(jīng)可以了，這是一個(gè)可以調(diào)整的值，比如你可以分別生成50，150，300維度的，然后試試那個(gè)效果好。
