在機器學習方面使用 R + Hadoop 方案真的有那么好2

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

大數據的幻覺：存儲和計算的沖突

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

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

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

數據在物理存儲、內存、甚至顯存的原地迭代會帶來數據重分布；在傳統數倉領域數據，重分布其實是對未來效率提高預期的妥協，且里面含有比較多對傳統業務穩定數據架構的理解。

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

大數據概念引入這件事兒是大炮打蚊子——內存內的分析和數據探索，展現（單節點）：

*從數據記錄條數講：

百萬級，R的上限；

千萬級-億級，SAS的上限；

千萬級，Python的上限；

*我的使用經驗，從數據占用內存的效率講：加載400M數據會使得

Python（Numpy列存）占用內存500M

R（我謹慎猜測是行存列存和二維表三樣都存一份）加載占內存2G

SAS（行存）占用600M，經過表級壓縮（依然是行存）150M

*后續的原始處理

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

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

*展現方案：

只要數據量低于剛才提到的限度，R又提供了最好的展現方案，因為“展現方案是專用而非泛用”的：

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

b. 百度echarts團隊項目被taiyun包裝成recharts放在了github上

c. 已經加入RStudio的R統計達人Yihui Xie的作品knitr，能夠使用markdown語法動態將數據挖掘結果，圖片，視頻生成打包放進html或者pdf文檔。

說說對手：

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

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

c. Java風格的Processing，無縫調用java庫，封裝大量java圖形函數、視頻相關API、鼠標響應API，可以導出java applet或port成js代碼；搞大數據的人必然熟悉java開發，可以幾乎0成本又高效快速的使用它。

這幾種工具確實各有所長，我個人無法取舍，但平心而論，R是學習門檻、編碼效率和產出效果同時最出色的（個人經歷原因無法對SAS VA，Tableau，Flex或更一般的BI展現工具置評，其受眾因為軟件成本，落地性不夠等原因，我缺乏使用它們的經驗，它們也缺乏對我的吸引力）

歸納下我的理解，R的產出報告類似html+javascript+CSS一樣，是適合輕量分析，輕量展現的。

大數據干這件事兒是正道——非結構化大數據批量或者迭代處理：

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

非結構化大數據應用的場景只能是：

-你很懂數據分布的細節（也許是項目經驗，也許是R上已經做過抽樣探索）

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

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

-你完全不care交互式探索

這是你需要的R應用場景么？或者換一種說法，這種應用場景R有什么優勢？調用編譯好的cpp庫，fortran庫是R發揮優勢的地方嗎？要知道算法效率排名上R<java<C++。算法月內要上線，自己看著辦。

說下前鄙team（一個不是專業做數據挖掘的數據部門）的經驗：

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

因為我會SAS（少量用Macro，沒用過矩陣，因為沒必要）和R（沒有學習成本），Python的并行包pp使用中，考慮mahout。

更新：當大數據平臺用戶不滿足于存儲，簡單加工以及成型算法實施，也開始關注最小查詢、交互式探索效率了，諸如Spark的內存解決方案將會更合適。

現team是一個同事至少是碩士（統計/金融/計算機），專做金融行業數據挖掘的小團隊。能力和業務場景可以供參考。

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

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

* Hadoop/大數據概念淡：客戶有足夠的Teradata、Oracle、SAS服務器

* Hive/Spark：Hive做輔助、靈活倉儲，PySpark作為一個可以預期、穩定的數據挖掘平臺的接點

結束語：

順便也給數學系、統計系的數據分析師，以及他們的領導們提醒一句：如果員工A有員工B沒有的代碼開發能力，R又完全替員工B把數學的事情做完了，形成了依賴，那員工B存在的意義是什么？強調數學理論這么一點點優勢也都不復存在了。

機器學習算法在不同的階段適合使用不同的工具，研究和使用接不上也就算了，千萬別連工具適合的環境都不懂，作為互聯網從業者，這就太盲從了。

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

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