為什麼有些公司在機器學習業務方面傾向使用 R + Hadoop 方案？

12-26

眾所周知,R 在解決統計學問題方面無與倫比。但是 R 在數據量達到 2G 以上速度就很慢了，於是就催生出了與 Hadoop 相結合跑分散式演算法這種解決方案，但是，python+Hadoop 這樣的解決方案有沒有團隊在使用？R 這樣起源於統計學的計算機包與 Hadoop 相結合會不會出問題？

因為他們在不懂R和Hadoop的特徵應用場景的情況下，恰好抓到了一根免費，開源的稻草。

R：

R的應用場景不在於無與倫比的統計學習能力，而在於結構化數據下無與倫比的單位代碼產出量。神經網路，決策樹等基於結構化數據的演算法一行代碼搞定，預測又只是一行代碼。這樣，商業資料庫（如包括Oracle，Netezza，Teradata，SAP HANA等）提供了R介面供統計分析人員進行高效實施。同樣的，SAS和IBM SPSS也做到了一部分高效實施能力，他們沒有的是R獨有的龐大cran packages群。但相似的一點是，R的package群也把它的用戶慣壞了，慣壞到這些人只是覺得這是一個SAS或者SPSS的免費版，而不是去通過代碼學習如何做機器學習哪怕一點點核心原理。你要做的，就是高效的最新結構化數據演算法的實施。

最重要的是，從Hadoop上的數據載入到這些庫，不僅保證了數據本身的正確性和結構化，也已經保證了數據模型的第二、第三範式化（CAErwin的第一課），想做任何一個分析，你手邊的資料庫簡單的join就形成了你需要的分析寬表。想想SQL里sum over的設計含義：為什麼它要製造數據的冗餘？那一定是為了BI或者分析存在的。

Hadoop：

Hadoop的應用場景不在於給統計分析軟體提供強力的支持，而只是提供了一個分散式數據的泛用免費框架，基於鍵值對（key value pair）高效的對原始非結構化數據進行存儲。
傳統方式下目測可以做到對連續型數值、離散型數值、字元串、大型字元串BLOB、地理信息（二維點，多邊形）的存儲，Hadoop相當於直接把很多功能擴展：比如Hive作為一個基本工具，直接提供了更廣泛的數據類型存儲方案：數組(array)，結構體(struct)，鍵值對(map)等。
業務場景：我存儲一篇文章不再需要一坨文字灌進去，先做NLP解析，然後形成 (詞,詞性)的元組，再組成長數組(Array)即可方便的存儲、分析，以及利用內置UDF、自寫UDF對複雜結構行轉列，提取信息。（當然，將NLP解析本身整合在UDF甚至演算法中都是可行的，如PySpark）

------------------------
*2014.8改進說明：
如果你至今覺得非結構化數據，鍵值對是一種賣弄概念，我就換一個至簡的說法：一個只有兩列的數據表。兩列的mn*2和多列m*n數據表是可以在一定加工代價下互轉的。這種數據結構被大量應用於Java，C++，Python甚至JavaScript中，當你看見類似Hashmap，Hashtable，dict，map等字眼，那就是這貨沒跑了：經過設計，用於存儲的鍵(key)被散列後決定了它能夠被均勻地分散式存儲，值(value)是鍵的跟班，隨著鍵被存儲。
對於非結構化數據而言，元數據和數據不像方表，極其容易抽象出來（無非就是列名和方表的內容）。初看一個半結構化的Json/XML，元數據出現在鍵(key)中，數據出現在值(value)中，容易理解。但在解析其他類型數據，(如網路日誌Url)，鍵里的所謂元數據才是要分析的對象(一個用戶反覆的使用price=xxx做查詢條件，說明價格敏感，有可能xxx取了好多值甚至所有可能值，key卻很少，可能只有price和brand；此時用戶行為模式出現在key里了。)
------------------------

結構化和非結構化資料庫結合的R+Hadoop看起來很美，實則困難重重。我的看法是，任何一家在數據分析領域（文本挖掘暫時除外，理由在業務場景里描述過）決定以一個穩健的態度涉足的企業，都無一例外的基於數據強一致性的考慮，選擇傳統的結構化資料庫作為後續結構化分析的依託—— 哪怕他們是收費的。如果習慣代碼開發，Hadoop+python自己做初步的數據處理，而後使用基於java的Mahout是一個很自然的選擇：其提供的矩陣計算（SVD），迭代式聚類演算法(如Kmeans)，基於圖的迭代模型（一個例子是PageRank演算法，值中存的也是Key），以及集成決策樹等模型，在分散式場景下是順理成章完成的，而R則會像一個跟班，很難找到它的應用場景。一樣具有較高編碼效率的Python可以更加靈活、優美（縮進的意義上）的繼承mrjob類完成相應功能，在數據嘗試性探索這一步，matplotlib產出報告恐怕是不如R+knitr+ggplot2更能取悅老闆，但一旦需要階段性的測試，Python這種膠水語言或者一步到位的使用Java開發顯得更接地氣，更容易落地。

（關於落地性，再小小吐槽一下R在Windows和Linux兩個平台下能夠使用的包範圍是不同的，尤其是使用Rcpp或者並行包的時候。Python和Java則不常見到這種問題）

R+Hadoop的幻覺：

不管什麼和Hadoop結合，都喜歡以word count這種典型的鍵值對開始。事實上R可以做這件事，但是覺得R做的無與倫比，就有點進入誤區。還是那句R的美在於結構化數據下無與倫比的單位代碼產出量。一旦你發現你作為專註於數據的分析師，同時也是一個並不骨灰的代碼開發者，開始用R操作列表和數據結構，開始用R重寫Mapper和Reducer，你就會產生一個疑問：

為嘛不學Java、Python？這種分析「不傳統」，就算你不想學吧，為嘛不找懂它們的人來干？

Python基於鍵值對存儲，也具有相當高的單位代碼產出量，也有很多科學計算包。從這個意義上你可以做出一個白箱，單機縮水版的mahout，而且適合處理有增量演算法的大數據學習（看看NumPy,SciPy,）。一樣免費。

數據挖掘的幻覺：

數據挖掘是什麼，很難嗎？
廣義的數據挖掘，包括數據分析和機器學習，只說最核心的數學概念的話，估計就幾句話；恰好R的簡潔性也是能用幾句話做完這幾句話的：

0 數據清洗，標準化。和1-4，理解真實世界是相輔相成的
1 最先學的數學技巧是空間分解：LL"，PCA，SVD，一般回歸以及L2/L0懲罰變種；從資訊理論角度講信息流壓縮（有名如LZ及變種LZO）；SVM用到的RBF也算基提取技巧。
2 再學最優化演算法：L1懲罰回歸，SVM（使用的Newton-Raphson/Gauss-Newton/Levenberg-Marquadt（還是1的內容！）；MonteCarlo Markov Chain
3 數據結構：決策樹（列表類），詞頻統計（鍵值對或者字典類），FP-growth（一個樹的加強版）。學到這，所謂「貝葉斯」根本就不能叫演算法，只能叫一個無處不在的指導思想。
4 模型集成：Adaboost，神經網路，bootstrap。集成時，權重技巧和懲罰技巧我的理解是不可割裂。但這個思想對方法，對模型參數都能集成，大雜燴。1個超級精妙的模型不如200個良好理解了問題性質的土鱉模型更實用。

任何一個聽起來很裝逼的演算法，逃不過被解析成這4類方法組合的命運。參數調優這種不提綱挈領的問題，確實需要結合時間成本人力成本看（研究者，學生，碼農的成本和投入量完全不一樣）

可以看到，大數據分析的瓶頸在哪？
第0步，和曾經的大Boss討論過，傳統行業數據倉庫實施起碼還能打10年，而"實體-關係"概念和"鍵-值"概念這兩種抽象起碼還能打30年，數據的組織，過濾，元數據維護都是數據產生價值的必經之路，這方面的工作很枯燥但是很基礎，大數據和傳統數據都需要；
第1步是最基本最重要的分析手段，也最容易在大數據語境下導致單機無法分析的億階稀疏大矩陣產生：例1，用戶User對商品SKU的購買記錄；例2，在特定的經緯度，特定的時間，特定的用戶發生了動作；這兩個例子是典型的「查詢簡單分析難，匯總還不如不匯總」的情況，必須要有分散式稀疏矩陣處理技術；
第2步，序貫MCMC的串列性可以通過並行集成方法模擬，但是收斂性還仍然較低，需要暴力並行堆FLOPS；對應的，因為SVM/Lasso都有增量演算法、分散式演算法方案，核心思想在於「世界的真實，模型的本質，都是稀疏的」，鎖少量資源，分散式地更新模型係數或者是梯度，這些演算法在理論上得到突破後，往往依賴分析型資料庫或者大數據平台靈活的並發調度，靈活的行列混合存儲模式，這一點是單機、小集群、傳統資料庫難以企及的；
第3、4步，這裡雖然舉了很簡單的例子，但這些是在數學模型和數據模型上是最沒有開發壓力的，需要關心的只是資深程序員的功底了。舉例說明，文本挖掘（NLP）統計完詞頻你還是得會空間里做PCA（或者其他形式的大矩陣加工）；如果不然，只引入HMM模型和基礎字典樹的話，學習成本就只有學習貝葉斯理論了，並且仍然可以高效並行的解決NLP問題，有興趣的可以參考Viterbi演算法和CRF演算法。

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

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

需要隨時交換資源的聚類，回歸，SVD，PCA，QR，LU等關係到矩陣分解的計算甚至是高效訪問，更進一步還有熱數據在內存上而不是物理存儲上的多次迭代，這才是大數據真正的挑戰。
那些有監督的分類樹，把數據集切成1000份並且有冗餘的給500台機器每台3-5份數據最後得到集成的分類結果，我很難稱其為「大數據計算技術」，它的本質和挖礦機每秒能做無數個高度同質化的hash計算一樣，不需要資源交換，不需要大量通信，它只是「小數據+獨立運算後直接能夠整合結果」的範圍內打轉。

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

大數據時代明顯不存在什麼數據倉庫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&

說下前鄙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存在的意義是什麼？強調數學理論這麼一點點優勢也都不復存在了。

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

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

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

*2015.11改進說明：

2年左右的時間裡並沒有新技術的湧現，但是有成熟技術的沉澱以及輪子化。我之前認為的Spark只管分發數據，啟動Python跑腳本（跑CUDA C程序或者別的什麼東西方法大同小異）的這種我一開始認為其實有些不倫不類，追求速度的嘗試模式，現在竟然已經繞過了Hadoop自成一種模式了。而且，Spark的功能進一步從分發數據退化到了分發演算法參數？！（有個例外，Spark跑圖模型演算法無法僅僅分發參數）

PySpark機制：https://cwiki.apache.org/confluence/display/SPARK/PySpark+Internals

這幾乎已經說明了數據科學只要快。幾乎無法容忍I/O，勉強容忍大量的分散式內存數據交換，要是拿到GPU上去，數據頻繁的通過PCIE交換，早晚也是要被否。

伴隨著我個人在數據科學上的認知逐漸脫離淺薄、Follow很多深度學習大神（我認為DL已經形成了新的框架了，本文所述的機器學習就當作基礎入門來討論吧）的工作以及對架構設計更有興趣之後，我覺得現在大家可以直接看Continuum Analytics這家公司Anaconda的平台產品布局了。自行觀看 Learn more about Anaconda 這個鏈接中的Platform Data Sheet。

反過來看我這篇回答其實很可笑，2年的時間就能夠讓當時不少我認為存在迷霧的東西變得清晰很多。 R現在的定位是什麼？科學計算領域好玩的玩具Julia,Lua滿地都是，願意砸時間的人隨時隨地都能用輪子搞出東西來。—— 但你別忘了很多提供輪子的大神是寫著C++給你們造玩具的。

玩具對技術模式變革的作用就是拉動性的，能不能拉動那要看老闆玩心重不重。

脫離好玩上升到企業戰略發展層面，大量草根初創的CTO帶著最守舊的方案和最守舊的那一批開發者受到動蕩的新業務衝擊，舊有模式其不經濟性逐漸被發現，並且有了模塊化的替代方案。身邊有很多並不大神，但接地氣兒的開發者。這裡面，很難有人Python/JavaScript/GoLang 三者都一竅不通。

追求經濟性對技術模式變革的作用是推動性的。大家都在沉澱，玩票都在失去空間。不推就死。

參考內容：

Revolution Analytics
Apache Mahout: Scalable machine learning and data mining
Continuum Analytics的Learn more about Anaconda中Platform Data Sheet鏈接。
《Program Clojure》
《R ggplot2：數據分析與圖形藝術》
《Machine Learning in Action》

首先一點就是SAS太貴。
其次，R的圖形展示比Java、python都更方便好用而且效果很不錯，對於給不懂數據挖掘又想沾上大數據光的領導作報告比較方便忽悠。
再次，現在互聯網公司帶領著各行各業的IT技術，但是說實話，BAT的數據挖掘優勢在於可以處理的數據量更大，傳統金融行業既沒那麼大的數據量也沒精力去折騰，而且傳統金融企業更加在意對數據的分析、對數據挖掘結論的分析，R可以直接生成各種各樣的分析指標和圖表，在同樣的精力下直觀性比mahout高出很多。
再補充一個因素，技術實力不怎麼強的公司不想自己寫演算法也不想用mahout（mahout本身還不完善、很多演算法未實現），甚至很多情況下經過ETL處理過的數據需要用分散式演算法的可能性微乎其微，用R是一個很有性價比的選擇

沒啥神秘的

Hadoop用來Aggregate數據，然後扔給R去運行就好了。根據你自己的口味，你也可以扔給python去做，都是可以的。其實去瞅瞅那些大公司發的paper，這個思路其實相當普遍，內存白菜價的現在，何必勞什子在沒有摸清狀況之前搞什麼分散式。

同意最高票答案，數據量大並不意味著你的計算量很大。現在所謂的大數據，狹義一點Hadoop相關的東西，還很初級，不過是傳統關係型資料庫的撐不下去的之後的替代品，最後炒作半天發現原來還是在Hadoop上面又搭了一個SQL，還不見得比原來方便，真是胸悶。這不，列存儲的關係型資料庫來勢洶洶，大數據繞了一轉，發現其實也沒怎麼前進。

如果是老闆，投資在電腦設別的配置上哪怕多花點錢，也是算在固定資產折舊的，如果買SAS，尤其是小公司，沒有規模效應的話，軟體的購買費用相當可觀。對搞數學的人，學校教matlab最多了，其次是r，教python的少。綜合起來看r和python的創業成本低一點。

應該是非計算機行業用的比較多吧，計算機行業內除了拿來玩玩的基本沒怎麼見過，c++, python, java + hadoop見過不少，大些的公司都有自己改造過或是完全重做的替代系統。

根據我的了解，應該是可以操作stdin/stdout的編程語言都可以。愛用哪個用哪個。。。

scala spark 或者pyspark 解決互動式任務
hive+mapreduce之類的解決離線T+1的任務

SAS 猴貴。

學習成本問題，大多數數據分析方法例如時間序列分析在R上比較成熟，可以參考東西比較多，R與MATLAB語法相似，在MATLAB上建立的模型能很快移植到R上面，而且大部分數據集的分析文件都不是很大，基於內存感覺足夠了

開源，活躍的社區。

正在學習