陳德森　楊祖元

摘要：文章基于流行的非關(guān)系型數(shù)據(jù)庫(kù)MongoDB，結(jié)合spark機(jī)器學(xué)習(xí)庫(kù)中的樸素貝葉斯分類器和支持向量機(jī)，對(duì)豆瓣影評(píng)及京東商評(píng)進(jìn)行情感分類，并采用準(zhǔn)確率、召回率、F-Measure等指標(biāo)對(duì)分類效果進(jìn)行評(píng)價(jià)，最后測(cè)試了spark-MongoDB平臺(tái)的擴(kuò)展性能。

關(guān)鍵詞：文本分類；Spark；MongoDB；MLlib

互聯(lián)網(wǎng)發(fā)展促進(jìn)了社交媒體、在線交易等新興媒介的發(fā)展，這些網(wǎng)站每天都會(huì)產(chǎn)生數(shù)以億計(jì)的數(shù)據(jù)。其中文本數(shù)據(jù)占據(jù)了重要位置，有80%的數(shù)據(jù)以文本形式存在的。如何有效利用這些文本數(shù)據(jù)去創(chuàng)造價(jià)值，是亟待解決的問題。

文本挖掘（Text Mining，TM）是指從非結(jié)構(gòu)化文本中獲取用戶有用信息的過(guò)程。文本挖掘是從數(shù)據(jù)挖掘發(fā)展而來(lái)，但與傳統(tǒng)的數(shù)據(jù)挖掘相比，文本挖掘有其獨(dú)特之處，主要表現(xiàn)在：文檔本身是半結(jié)構(gòu)化或非結(jié)構(gòu)化的，無(wú)確定形式并且缺乏機(jī)器可理解的語(yǔ)義；而一般數(shù)據(jù)挖掘的對(duì)象以數(shù)據(jù)庫(kù)中的結(jié)構(gòu)化數(shù)據(jù)為主，并利用關(guān)系表等存儲(chǔ)結(jié)構(gòu)來(lái)發(fā)現(xiàn)知識(shí)。

針對(duì)上述問題，本文將結(jié)合MongoDB和Spark，在文本存儲(chǔ)及文本分類效果兩方面進(jìn)行研究。

1.文本數(shù)據(jù)的存儲(chǔ)

上文所述產(chǎn)生的數(shù)據(jù)，通常是由關(guān)系數(shù)據(jù)庫(kù)管理系統(tǒng)來(lái)處理。實(shí)踐證明，關(guān)系模型是非常適合于客戶服務(wù)器編程，它是今天結(jié)構(gòu)化數(shù)據(jù)存儲(chǔ)在網(wǎng)絡(luò)和商務(wù)應(yīng)用的主導(dǎo)技術(shù)。然而在數(shù)據(jù)爆炸的互聯(lián)網(wǎng)時(shí)代，傳統(tǒng)的關(guān)系型數(shù)據(jù)在應(yīng)對(duì)大規(guī)模和高并發(fā)訪問時(shí)顯得力不從心，因此一批NoSQL數(shù)據(jù)庫(kù)開始涌現(xiàn)，如MongoDB，Redis，Cassandra，HBase，CouchDB等。這些非關(guān)系型數(shù)據(jù)庫(kù)旨在解決大規(guī)模集合以及多重?cái)?shù)據(jù)類型帶來(lái)的挑戰(zhàn)，尤其適合大數(shù)據(jù)處理。

1.1MongoDB數(shù)據(jù)庫(kù)

MongoDB是最近幾年非?；鸬囊豢頝oSQL數(shù)據(jù)庫(kù)，由c++語(yǔ)言編寫，是一個(gè)基于分布式文件存儲(chǔ)的開源數(shù)據(jù)庫(kù)系統(tǒng)。在高負(fù)載的情況下，MongoDB可以通過(guò)添加更多的節(jié)點(diǎn)，來(lái)保證服務(wù)器性能。MongoDB旨在為Web應(yīng)用提供可擴(kuò)展的高性能數(shù)據(jù)存儲(chǔ)解決方案。（1）內(nèi)存充足。MongoDB性能非常好，它將熱數(shù)據(jù)存儲(chǔ)在物理內(nèi)存中，使得數(shù)據(jù)讀取十分快速。（2）高擴(kuò)展性。MongoDB的高可用集群擴(kuò)展性非常好，通過(guò)物理機(jī)的增加和在數(shù)據(jù)庫(kù)中配置Sharding，集群擴(kuò)展簡(jiǎn)單、高效。（3）Failover機(jī)制。MongoDB集群的主節(jié)點(diǎn)宕機(jī)后，通過(guò)選舉方式自動(dòng)在從節(jié)點(diǎn)中選出新的主節(jié)點(diǎn)提供服務(wù)，不需要人工參與。（4）BSon的存儲(chǔ)格式。類JSon的存儲(chǔ)格式，使得MongoDB十分適合文檔的存儲(chǔ)與查詢。

基于MongoDB的特點(diǎn)，本文嘗試用MongoDB結(jié)合Spark做文本分析研究。MongoDB支持3種部署方式，分別是單機(jī)模式、復(fù)制集模式、分片模式，本文采用的是分片模式。

1.2Spark結(jié)合Mong0DB

Spark是加州大學(xué)伯克利分校的AMP實(shí)驗(yàn)室（UC Berkeley AMP lab），Matei Zaharia博士在2009年所創(chuàng)立的大數(shù)據(jù)處理和計(jì)算框架，是一個(gè)類Hadoop MapReduce的開源通用并行框架。不同于傳統(tǒng)的數(shù)據(jù)處理框架，Spark基于內(nèi)存的基本類型（primitive）為一些應(yīng)用程序帶來(lái)了100倍的性能提升。Spark允許用戶程序?qū)?shù)據(jù)加載到集群的內(nèi)存中，用于反復(fù)查詢，非常適用于大數(shù)據(jù)和機(jī)器學(xué)習(xí)，已經(jīng)成為最廣泛采用的大數(shù)據(jù)模塊之一。在本文中程序中，通過(guò)添加mongo-java-driver-3.3.0.jar.mongo-hadoo-core-2.0.1.jar實(shí)現(xiàn)MongoDB和Spark的連接，使用ANSJ中文分詞工具對(duì)讀入的短評(píng)進(jìn)行中文分詞，最后使用Spark MLlib中的樸素貝葉斯分類器與支持向量機(jī)進(jìn)行文本分析。

Spark-MongoDB結(jié)合的形式如圖1所示，其中MongoDB采用的是分片模式。

1.3實(shí)驗(yàn)數(shù)據(jù)集

本文采用基于Java的網(wǎng)絡(luò)爬蟲獲取互聯(lián)網(wǎng)上的短評(píng)數(shù)據(jù)，共采集大概60萬(wàn)條評(píng)論，涉及了《瘋狂動(dòng)物城》《蝙蝠俠大戰(zhàn)超人》《木星上行》（Honor8》等豆瓣、京東的評(píng)論。將影評(píng)和手機(jī)銷售評(píng)論數(shù)據(jù)合并后，經(jīng)過(guò)初步的清洗（去雙引號(hào)，清除空數(shù)據(jù)，編碼轉(zhuǎn)換utf-8等），將數(shù)據(jù)導(dǎo)入MongoDB數(shù)據(jù)庫(kù)中。在數(shù)據(jù)庫(kù)中查看數(shù)據(jù)：

在文本分析實(shí)驗(yàn)中，按照評(píng)論的星級(jí)，將打1～2星的評(píng)論認(rèn)為是差評(píng)，4～5星的評(píng)論認(rèn)為是好評(píng)，以此來(lái)對(duì)短評(píng)進(jìn)行文本分類。

1.4文本分類算法度量

在二分類問題中，通常使用的評(píng)價(jià)方法包括準(zhǔn)確率，錯(cuò)誤率，召回率，F(xiàn)-Measure，ROC曲線，準(zhǔn)確率一召回率曲線下方面積，ROC曲線的下方面積以及等。在本文中，使用準(zhǔn)確率、召回率、F值評(píng)估文本分類效果。其中，A，B，C所代表的含義如表1所示。

準(zhǔn)確率（以下簡(jiǎn)稱P）；召回率（以下簡(jiǎn)稱R）。

由于P值和R值出現(xiàn)矛盾的時(shí)候，還可以考慮用另外一種方法去分析，那就是F-Measure（又稱F-Score）。F-Measure是P值和10值的加權(quán)和平均。

當(dāng)參數(shù)a取1時(shí)，就是常見的值，即：可見綜合P值和R值；當(dāng)值較高時(shí)，說(shuō)明分類方法有效。

接下來(lái)使用豆瓣數(shù)據(jù)集，驗(yàn)證文本分析情感分析在各種部署環(huán)境下的算法準(zhǔn)確度。

1.5實(shí)驗(yàn)結(jié)果

從表2中可以看到，在單機(jī)本地，單機(jī)MongoDB，集群MongoDB集中模式中，樸素貝葉斯和支持向量機(jī)的分類效果相差無(wú)幾。算法準(zhǔn)確度并沒有因?yàn)閿?shù)據(jù)分散在各個(gè)不同節(jié)點(diǎn)而下降，可知分布式存儲(chǔ)是適合做機(jī)器學(xué)習(xí)的?；赟parkMLlib的機(jī)器學(xué)習(xí)庫(kù)的算法效率也比較高，可見已經(jīng)可以適應(yīng)一般的實(shí)際應(yīng)用場(chǎng)景。

通過(guò)自我復(fù)制的方式對(duì)數(shù)據(jù)進(jìn)行擴(kuò)大，驗(yàn)證Spark-MongoDB分布式計(jì)算能力。使用分詞工具分詞，分別在單節(jié)點(diǎn)、雙節(jié)點(diǎn)、三節(jié)點(diǎn)做分詞和統(tǒng)計(jì)總詞數(shù)的操作，通過(guò)運(yùn)行時(shí)間比較他們之間的處理效率。其中單節(jié)點(diǎn)（主節(jié)點(diǎn)）是雙核6G內(nèi)存，單節(jié)點(diǎn)（從節(jié)點(diǎn)）是單核3G內(nèi)存。

從圖3中可以看出，分布式與單節(jié)點(diǎn)的運(yùn)行時(shí)間比較中，在數(shù)據(jù)量達(dá)到一定程度后，加速比是大于1的，證明MongoDB集群在大數(shù)據(jù)處理方面確實(shí)比單機(jī)的效率要高。但由于數(shù)據(jù)量大小的原因以及內(nèi)存的限制，它們之間的差別并不是很明顯，甚至還出現(xiàn)了雙節(jié)點(diǎn)速度比三節(jié)點(diǎn)快的尷尬，造成這種現(xiàn)象的原因是因?yàn)閱?dòng)多個(gè)節(jié)點(diǎn)，在通信和資源調(diào)度方面會(huì)花費(fèi)一定的時(shí)間。但總體而言依舊可以看出分布式平臺(tái)比單節(jié)點(diǎn)操作具有更平緩的時(shí)間增長(zhǎng)曲線。如果在更大規(guī)模的數(shù)據(jù)量以及性能更好的機(jī)器集群上，相信它們之間會(huì)有比較明顯區(qū)別。由此可知，在實(shí)際應(yīng)用中，如果需要處理的數(shù)據(jù)量很大的話，應(yīng)用Spark-MongoDB分布式平臺(tái)處理大數(shù)據(jù)將是一個(gè)很好的解決方案。

2.結(jié)語(yǔ)

由上述實(shí)驗(yàn)可知，spark自帶的機(jī)器學(xué)習(xí)庫(kù)，對(duì)一般文本的分類準(zhǔn)確率已經(jīng)比較高，結(jié)合文檔型MongoDB做文本分析，將會(huì)是分布式環(huán)境下大數(shù)據(jù)分析的不錯(cuò)選擇，具有實(shí)際應(yīng)用價(jià)值。