背景介紹

由于R語言本身是單線程的，所以可能從性能方面對比Spark和R并不是很明智的做法。即使這種比較不是很理想，但是對于那些曾經(jīng)遇到過這些問題的人，下文中的一些數(shù)字一定會讓你很感興趣。

你是否曾把一個機器學(xué)習(xí)的問題丟到R里運行，然后等上好幾個小時？而僅僅是因為沒有可行的替代方式，你只能耐心地等。所以是時候去看看Spark的機器學(xué)習(xí)了，它包含R語言大部分的功能，并且在數(shù)據(jù)轉(zhuǎn)換和性能上優(yōu)于R語言。

曾經(jīng)我嘗試過利用不同的機器學(xué)習(xí)技術(shù)——R語言和Spark的機器學(xué)習(xí)，去解決同一個特定的問題。為了增加可比性，我甚至讓它們運行在同樣的硬件環(huán)境和操作系統(tǒng)上。并且，在Spark中運行單機模式，不帶任何集群的配置。

在我們討論具體細(xì)節(jié)之前，關(guān)于Revolution R 有個簡單的說明。作為R語言的企業(yè)版，Revolution R試圖彌補R語言單線程的缺 陷。但它只能運行在像Revolution Analytics這樣的專有軟件上，所以可能不是理想的長期方案。如果想獲得微軟 Revolution Analytics軟件的擴展，又可能會讓事情變得更為復(fù)雜，比方說牽扯到許可證的問題。

因此，社區(qū)支持的開源工具，像是Spark，可能成為比R語言企業(yè)版更好的選擇。

數(shù)據(jù)集和問題

分析采用的是Kaggle網(wǎng)站 [譯者注：Kaggle是一個數(shù)據(jù)分析的競賽平臺，網(wǎng)址：https://www.kaggle.com/]上的數(shù)字識別器的數(shù)據(jù)集，其中包含灰度的手寫數(shù)字的圖片，從0到9。

每張圖片高28px，寬28px，大小為784px。每個像素都包含關(guān)于像素點明暗的值，值越高代表像素點越暗。像素值是0到255之間的整數(shù)，包括0和255。整張圖片包含***列在內(nèi)共有785列數(shù)據(jù)，稱為“標(biāo)記”，即用戶手寫的數(shù)字。

分析的目標(biāo)是得到一個可以從像素數(shù)值中識別數(shù)字是幾的模型。

選擇這個數(shù)據(jù)集的論據(jù)是，從數(shù)據(jù)量上來看，實質(zhì)上這算不上是一個大數(shù)據(jù)的問題。

對比情況

針對這個問題，機器學(xué)習(xí)的步驟如下，以得出預(yù)測模型結(jié)束：

• 在數(shù)據(jù)集上進(jìn)行主成分分析和線性判別式分析，得到主要的特征。（特征工程的步驟）[譯者注：百度百科傳送門，主成分分析、線性判別式分析]。

• 對所有雙位數(shù)字進(jìn)行二元邏輯回歸，并且根據(jù)它們的像素信息和主成分分析以及線性判別式分析得到的特征變量進(jìn)行分類。

• 在全量數(shù)據(jù)上運行多元邏輯回歸模型來進(jìn)行多類分類。根據(jù)它們的像素信息和主成分分析以及線性判別式分析的特征變量，利用樸素貝葉斯分類模型進(jìn)行分類。利用決策樹分類模型來分類數(shù)字。

在上述步驟之前，我已經(jīng)將標(biāo)記的數(shù)據(jù)分成了訓(xùn)練組和測試組，用于訓(xùn)練模型和在精度上驗證模型的性能。

大部分的步驟都在R語言和Spark上都運行了。詳細(xì)的對比情況如下，主要是對比了主成分分析、二元邏輯模型和樸素貝葉斯分類模型的部分。

主成分分析

主成分分析的主要計算復(fù)雜度在對成分的打分上，邏輯步驟如下：

• 通過遍歷數(shù)據(jù)以及計算各列的協(xié)方差表，得到KxM的權(quán)重值。（K代表主成分的個數(shù)，M代表數(shù)據(jù)集的特征變量個數(shù)）。

• 當(dāng)我們對N條數(shù)據(jù)進(jìn)行打分，就是矩陣乘法運算。

• 通過NxM個維度數(shù)據(jù)和MxK個權(quán)重數(shù)據(jù)，***得到的是NxK個主成分。N條數(shù)據(jù)中的每一條都有K個主成分。

在我們這個例子中，打分的結(jié)果是42000 x 784的維度矩陣與784 x 9的矩陣相乘。坦白說，這個計算過程在R中運行了超過4個小時，而同樣的運算Spark只用了10秒多

矩陣相乘差不多是3億次運算或者指令，還有相當(dāng)多的檢索和查找操作，所以Spark的并行計算引擎可以在10秒鐘完成還是非常令人驚訝的。

我通過查看前9個主成分的方差，來驗證了所產(chǎn)生的主成分的精度。方差和通過R產(chǎn)生的前9個主成分的方差吻合。這一點確保了Spark并沒有犧牲精度來換取性能和數(shù)據(jù)轉(zhuǎn)換上的優(yōu)勢。

邏輯回歸模型

與主成分分析不同的是，在邏輯回歸模型中，訓(xùn)練和打分的操作都是需要計算的，而且都是極其密集的運算。在這種模型的通用的數(shù)據(jù)訓(xùn)練方案中包含一些對于整個數(shù)據(jù)集矩陣的轉(zhuǎn)置和逆運算。

由于計算的復(fù)雜性，R在訓(xùn)練和打分都需要過好一會兒才能完成，準(zhǔn)確的說是7個小時，而Spark只用了大概5分鐘。

這里我在45個從0到9的雙位數(shù)字上運行了二元邏輯回歸模型，打分/驗證也是在這45個測試數(shù)據(jù)上進(jìn)行的。

我也并行執(zhí)行了多元邏輯回歸模型，作為多類分類器，大概3分鐘就完成了。而這在R上運行不起來，所以我也沒辦法在數(shù)據(jù)上進(jìn)行對比。

對于主成分分析，我采用AUC值 [譯者注： AUC的值就是計算出ROC曲線下面的面積，是度量分類模型好壞的一個標(biāo)準(zhǔn)。] 來衡量預(yù)測模型在45對數(shù)據(jù)上的表現(xiàn)，而Spark和R兩者運行的模型結(jié)果的AUC值差不多。

樸素貝葉斯分類器

與主成分分析和邏輯回歸不一樣的是，樸素貝葉斯分類器不是密集計算型的。其中需要計算類的先驗概率，然后基于可用的附加數(shù)據(jù)得到后驗概率。[譯者注：先驗概率是指根據(jù)以往經(jīng)驗和分析得到的概率，它往往作為”由因求果”問題中的”因”出現(xiàn)的概率；后驗概率是指在得到“結(jié)果”的信息后重新修正的概率，是“執(zhí)果尋因”問題中的”果”。]

如上圖所示，R大概花了45余秒完成，而Spark只用了9秒鐘。像之前一樣，兩者的精確度旗鼓相當(dāng)。

同時我也試著用Spark機器學(xué)習(xí)運行了決策樹模型，大概花了20秒，而這個在R上完全運行不起來。

Spark機器學(xué)習(xí)入門指南

對比已經(jīng)足夠，而這也成就了Spark的機器學(xué)習(xí)。 ***是從編程指南開始學(xué)習(xí)它。不過，如果你想早點嘗試并從實踐中學(xué)習(xí)的話，你可能要痛苦一陣子才能將它運行起來吧。

為搞清楚示例代碼并且在數(shù)據(jù)集上進(jìn)行試驗，你需要先去弄懂Spark的RDD [譯者注：RDD，Resilient Distributed Datasets，彈性分布式數(shù)據(jù)集] 支持的基本框架和運算。然后也要弄明白Spark中不同的機器學(xué)習(xí)程序，并且在上面進(jìn)行編程。當(dāng)你的***個Spark機器學(xué)習(xí)的程序跑起來的時候，你可能就會意興闌珊了。

以下兩份資料可以幫你避免這些問題，同時理順學(xué)習(xí)的思路：

• Spark機器學(xué)習(xí)所有的源代碼，可提供任何人拿來與R語言作對比：

https://github.com/vivekmurugesan/experiments/tree/master/spark-ml

• Docker容器的源代碼，Spark和上述項目的包已預(yù)置在內(nèi)，以供快速實施：

https://hub.docker.com/r/vivekmurugesan/spark-hadoop/ Docker容器中已事先安裝Apache Hadoop，并且在偽分布式環(huán)境下運行。這可以將大容量文件放進(jìn)分布式文件系統(tǒng)來測試Spark。通過從分布式文件系統(tǒng)加載記錄，可以很輕松地來創(chuàng)建RDD實例。

產(chǎn)能和精度

人們會使用不同的指標(biāo)來衡量這些工具的好壞。對我來說，精準(zhǔn)度和產(chǎn)能是決定性的因素。

大家總是喜歡R多過于Spark機器學(xué)習(xí)，是因為經(jīng)驗學(xué)習(xí)曲線。他們最終只能選擇在R上采用少量的樣本數(shù)據(jù)，是因為R在大數(shù)據(jù)量的樣本上花了太多時間，而這也影響了整個系統(tǒng)的性能。

對我來說，用少量的樣本數(shù)據(jù)是解決不了問題的，因為少量樣本根本代表不了整體（至少在大部分情況下是這樣）。所以說，如果你使用了少量樣本，就是在精度上選擇了妥協(xié)。

一旦你拋棄了少量樣本，就歸結(jié)到了生產(chǎn)性能的問題。機器學(xué)習(xí)的問題本質(zhì)上就是迭代的問題。如果每次迭代都花費很久的話，那么完工時間就會延長?？墒?，如果每次迭代只用一點時間的話，那么留給你敲代碼的時間就會多一些了。

結(jié)論

R語言包含了統(tǒng)計計算的庫和像ggplot2這樣可視化分析的庫，所以它不可能被完全廢棄，而且它所帶來的挖掘數(shù)據(jù)和統(tǒng)計匯總的能力是毋庸置疑的。

但是，當(dāng)遇到在大數(shù)據(jù)集上構(gòu)建模型的問題時，我們應(yīng)該去挖掘一些像Spark ML的工具。Spark也提供R的包，SparkR可以在分布式數(shù)據(jù)集上應(yīng)用R。

***在你的“數(shù)據(jù)軍營”中多放點工具，因為你不知道在“打仗”的時候會遇到什么。因此，是時候從過去的R時代邁入Spark ML的新時代了。

原文：Tools in the data armoury: R vs Spark