基于MongoDB的文本分類研究

陳德森　楊祖元

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

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

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

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

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

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

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

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

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

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

1.2Spark結(jié)合Mong0DB

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

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

1.3實驗數(shù)據(jù)集

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

在文本分析實驗中，按照評論的星級，將打1～2星的評論認為是差評，4～5星的評論認為是好評，以此來對短評進行文本分類。

1.4文本分類算法度量

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

準確率（以下簡稱P）；召回率（以下簡稱R）。

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

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

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

1.5實驗結(jié)果

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

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

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

2.結(jié)語

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