在機(jī)器學(xué)習(xí)方面使用 R + Hadoop 方案真的有那么好2

第3、4步，這里雖然舉了很簡單的例子，但這些是在數(shù)學(xué)模型和數(shù)據(jù)模型上是最沒有開發(fā)壓力的，需要關(guān)心的只是資深程序員的功底了。舉例說明，文本挖掘（NLP）統(tǒng)計(jì)完詞頻你還是得會(huì)空間里做PCA（或者其他形式的大矩陣加工）；如果不然，只引入HMM模型和基礎(chǔ)字典樹的話，學(xué)習(xí)成本就只有學(xué)習(xí)貝葉斯理論了，并且仍然可以高效并行的解決NLP問題，有興趣的可以參考Viterbi算法和CRF算法。

大數(shù)據(jù)的幻覺：存儲(chǔ)和計(jì)算的沖突

大數(shù)據(jù)處理，多大算大？像我說的，在3,4步出來的數(shù)據(jù)，原始數(shù)據(jù)很大，加工匯總完了很小，或者處理起來是高度獨(dú)立的。分布式存儲(chǔ)不影響分析，說是大數(shù)據(jù)，其實(shí)和小數(shù)據(jù)處理沒差別。

需要隨時(shí)交換資源的聚類，回歸，SVD，PCA，QR，LU等關(guān)系到矩陣分解的計(jì)算甚至是高效訪問，更進(jìn)一步還有熱數(shù)據(jù)在內(nèi)存上而不是物理存儲(chǔ)上的多次迭代，這才是大數(shù)據(jù)真正的挑戰(zhàn)。

那些有監(jiān)督的分類樹，把數(shù)據(jù)集切成1000份并且有冗余的給500臺(tái)機(jī)器每臺(tái)3-5份數(shù)據(jù)最后得到集成的分類結(jié)果，我很難稱其為“大數(shù)據(jù)計(jì)算技術(shù)”，它的本質(zhì)和挖礦機(jī)每秒能做無數(shù)個(gè)高度同質(zhì)化的hash計(jì)算一樣，不需要資源交換，不需要大量通信，它只是“小數(shù)據(jù)+獨(dú)立運(yùn)算后直接能夠整合結(jié)果”的范圍內(nèi)打轉(zhuǎn)。

數(shù)據(jù)在物理存儲(chǔ)、內(nèi)存、甚至顯存的原地迭代會(huì)帶來數(shù)據(jù)重分布；在傳統(tǒng)數(shù)倉領(lǐng)域數(shù)據(jù)，重分布其實(shí)是對(duì)未來效率提高預(yù)期的妥協(xié)，且里面含有比較多對(duì)傳統(tǒng)業(yè)務(wù)穩(wěn)定數(shù)據(jù)架構(gòu)的理解。

大數(shù)據(jù)時(shí)代明顯不存在什么數(shù)據(jù)倉庫ER模型穩(wěn)定性，不知道大家有沒有這種體驗(yàn)：一個(gè)新需求，一個(gè)全新的不著邊際的研究性問題的場景下，就能建個(gè)新庫來進(jìn)行探索與數(shù)據(jù)加工整理，數(shù)據(jù)挖掘。各自為政，實(shí)驗(yàn)容易，落地與整合困難?！?這個(gè)情況下如果要頻繁走物理存儲(chǔ)的話，基于key的重新分布會(huì)讓數(shù)據(jù)像煮沸的一鍋粥大量占用網(wǎng)絡(luò)與IO寫入帶寬，與傳統(tǒng)數(shù)據(jù)庫性能的巨大鴻溝是無法回避的問題。因此在這個(gè)場景下，Spark、Storm、GPU計(jì)算火起來，如Scala、Clojure、Python等含有FP概念的語言走得越來越靠近開發(fā)工程師的視線，較高級(jí)的封裝工具如圖模型計(jì)算的GraphSQL等組件也浮出水面。而且說句實(shí)話，Map（映射）和Reduce（規(guī)約）在這些語言中，已經(jīng)是老的掉了好多年牙的概念了。（FP：Functional Programming我反對(duì)翻譯成函數(shù)式編程，這明明是泛函編程）

大數(shù)據(jù)概念引入這件事兒是大炮打蚊子——內(nèi)存內(nèi)的分析和數(shù)據(jù)探索，展現(xiàn)（單節(jié)點(diǎn)）：

*從數(shù)據(jù)記錄條數(shù)講：

百萬級(jí)，R的上限；

千萬級(jí)-億級(jí)，SAS的上限；

千萬級(jí)，Python的上限；

*我的使用經(jīng)驗(yàn)，從數(shù)據(jù)占用內(nèi)存的效率講：加載400M數(shù)據(jù)會(huì)使得

Python（Numpy列存）占用內(nèi)存500M

R（我謹(jǐn)慎猜測是行存列存和二維表三樣都存一份）加載占內(nèi)存2G

SAS（行存）占用600M，經(jīng)過表級(jí)壓縮（依然是行存）150M

*后續(xù)的原始處理

尤其是字符串操作這種數(shù)據(jù)清洗，R幾乎不能做，精通shell及regexp的人又做的太容易。

若想用R，這就需要你輸入到R的數(shù)據(jù)幾乎就能直接開始跑分析了。若不信邪，我推薦你用readLines加上strsplit來操作讀入R的文件，看看他數(shù)據(jù)清洗的效率和read.delim，和SAS proc import 以及 Python的with as語法相差多少。

*展現(xiàn)方案：

只要數(shù)據(jù)量低于剛才提到的限度，R又提供了最好的展現(xiàn)方案，因?yàn)椤罢宫F(xiàn)方案是專用而非泛用”的：

a. Hadley最著名的R包之一ggplot2未來會(huì)引入SVG等可交互元素。一個(gè)具有d3.js可視化特性的繪圖包還不讓你震驚嗎？

b. 百度echarts團(tuán)隊(duì)項(xiàng)目被taiyun包裝成recharts放在了github上

c. 已經(jīng)加入RStudio的R統(tǒng)計(jì)達(dá)人Yihui Xie的作品knitr，能夠使用markdown語法動(dòng)態(tài)將數(shù)據(jù)挖掘結(jié)果，圖片，視頻生成打包放進(jìn)html或者pdf文檔。

說說對(duì)手：

a. R要比Python現(xiàn)有的可視化包（以matplotlib和pygame為主）更友好，更易于操作。

b. 雖然讓從來沒接觸過前端的人沉浸在用Chrome即可調(diào)試的JavaScript里面不太科學(xué)，但我愛不釋手，而且其核心的展現(xiàn)方式確實(shí)未來會(huì)加入R。

c. Java風(fēng)格的Processing，無縫調(diào)用java庫，封裝大量java圖形函數(shù)、視頻相關(guān)API、鼠標(biāo)響應(yīng)API，可以導(dǎo)出java applet或port成js代碼；搞大數(shù)據(jù)的人必然熟悉java開發(fā)，可以幾乎0成本又高效快速的使用它。

這幾種工具確實(shí)各有所長，我個(gè)人無法取舍，但平心而論，R是學(xué)習(xí)門檻、編碼效率和產(chǎn)出效果同時(shí)最出色的（個(gè)人經(jīng)歷原因無法對(duì)SAS VA，Tableau，F(xiàn)lex或更一般的BI展現(xiàn)工具置評(píng)，其受眾因?yàn)檐浖杀?，落地性不夠等原因，我缺乏使用它們的?jīng)驗(yàn)，它們也缺乏對(duì)我的吸引力）

歸納下我的理解，R的產(chǎn)出報(bào)告類似html+javascript+CSS一樣，是適合輕量分析，輕量展現(xiàn)的。

大數(shù)據(jù)干這件事兒是正道——非結(jié)構(gòu)化大數(shù)據(jù)批量或者迭代處理：

你的算法已經(jīng)走到了“萬事俱備，只差跑全量” 這樣一個(gè)對(duì)手中的數(shù)據(jù)很了解的地步了。Wiki 對(duì)Revolution Analytics的介紹講：R didn’t natively handle datasets larger than main memory，這么靈活小巧的工具做個(gè)抽樣數(shù)據(jù)分析明明是很好的。

非結(jié)構(gòu)化大數(shù)據(jù)應(yīng)用的場景只能是：

-你很懂?dāng)?shù)據(jù)分布的細(xì)節(jié)（也許是項(xiàng)目經(jīng)驗(yàn)，也許是R上已經(jīng)做過抽樣探索）

-問題適合的算法你了然于胸；增量算法存在；暴力并行計(jì)算（矩陣計(jì)算，圖迭代）沒問題

-你覺得把類似Mahout計(jì)算的步驟經(jīng)過代碼包裝交付給R來做沒問題

-你完全不care交互式探索

這是你需要的R應(yīng)用場景么？或者換一種說法，這種應(yīng)用場景R有什么優(yōu)勢？調(diào)用編譯好的cpp庫，fortran庫是R發(fā)揮優(yōu)勢的地方嗎？要知道算法效率排名上R<java<C++。算法月內(nèi)要上線，自己看著辦。

說下前鄙team（一個(gè)不是專業(yè)做數(shù)據(jù)挖掘的數(shù)據(jù)部門）的經(jīng)驗(yàn)：

講了半天R+Hadoop，不上Mahout，隨便搞搞RSnow，準(zhǔn)備買SAS。

因?yàn)槲視?huì)SAS（少量用Macro，沒用過矩陣，因?yàn)闆]必要）和R（沒有學(xué)習(xí)成本），Python的并行包pp使用中，考慮mahout。

更新：當(dāng)大數(shù)據(jù)平臺(tái)用戶不滿足于存儲(chǔ)，簡單加工以及成型算法實(shí)施，也開始關(guān)注最小查詢、交互式探索效率了，諸如Spark的內(nèi)存解決方案將會(huì)更合適。

現(xiàn)team是一個(gè)同事至少是碩士（統(tǒng)計(jì)/金融/計(jì)算機(jī)），專做金融行業(yè)數(shù)據(jù)挖掘的小團(tuán)隊(duì)。能力和業(yè)務(wù)場景可以供參考。

* SAS能力覆蓋面95%（具備核心價(jià)值的數(shù)據(jù)在服務(wù)器上能夠處理的量很少超過上億，主推SAS）

* Python和R覆蓋面都在70%+

* Hadoop/大數(shù)據(jù)概念淡：客戶有足夠的Teradata、Oracle、SAS服務(wù)器

* Hive/Spark：Hive做輔助、靈活倉儲(chǔ)，PySpark作為一個(gè)可以預(yù)期、穩(wěn)定的數(shù)據(jù)挖掘平臺(tái)的接點(diǎn)

結(jié)束語：

順便也給數(shù)學(xué)系、統(tǒng)計(jì)系的數(shù)據(jù)分析師，以及他們的領(lǐng)導(dǎo)們提醒一句：如果員工A有員工B沒有的代碼開發(fā)能力，R又完全替員工B把數(shù)學(xué)的事情做完了，形成了依賴，那員工B存在的意義是什么？強(qiáng)調(diào)數(shù)學(xué)理論這么一點(diǎn)點(diǎn)優(yōu)勢也都不復(fù)存在了。

機(jī)器學(xué)習(xí)算法在不同的階段適合使用不同的工具，研究和使用接不上也就算了，千萬別連工具適合的環(huán)境都不懂，作為互聯(lián)網(wǎng)從業(yè)者，這就太盲從了。

精英的研究者是自己做開發(fā)的——這話也可以這么說，精英的開發(fā)者們自己做研究。每一個(gè)模型都不完美，何況新問題涌現(xiàn)的越來越快，現(xiàn)存的模型很可能不滿足你的分析需要。所以才要一邊扎實(shí)理論，以最少的嘗試嗅到最適合問題的算法，一邊以開放的心態(tài)接納和理解新技術(shù)的應(yīng)用場景，深入發(fā)展數(shù)據(jù)挖掘研究，從代碼優(yōu)化改造（山寨）走向技術(shù)原創(chuàng)。

一個(gè)不好的消息是，不管是從indeed.com職位Post、搜索還是行業(yè)生命周期研究看，大數(shù)據(jù)這幾個(gè)字正在迅速退掉金色，其名字的價(jià)值泡沫正在逐步被擠出。抓住技術(shù)的重點(diǎn)與技術(shù)適合的場景，對(duì)個(gè)人以及對(duì)行業(yè)都是磨刀不誤砍柴工的事情。