R語言企業(yè)級大數(shù)據(jù)挖掘應用

為什么要使用R語言

在互聯(lián)網(wǎng)企業(yè)，在分析端使用閉源的商用軟件幾乎是不可能的，原因很簡單：成本太高，不管是使用，還是研發(fā)及維護。 但我個人覺得這可能還不是最主要的原因，對于互聯(lián)網(wǎng)企業(yè)來說，數(shù)據(jù)雖然獲取更容易，但環(huán)境更為復雜。開源軟件可以根據(jù)業(yè)務的變化 進行調整，但商業(yè)的閉源軟件則很難做到。

好多人問過我這個問題，我會說你有多大內存就能處理多大數(shù)據(jù)，這話顯然不負責任。這個問題確實不太好回答，因為每個人心中的大數(shù)據(jù)是不一樣的。 比如有人覺得幾百萬就是大數(shù)據(jù)，有些人覺得沒個幾億就不算大數(shù)據(jù)，甚至有人說你處理不了的就是大數(shù)據(jù)（擦！？）。這些還只是從記錄 數(shù)（數(shù)據(jù)存儲）的角度來看的，我們換個角度想想：建模工程師要做的事情無非是將用戶和產(chǎn)品進行合理匹配，那最細粒度就是用戶維（或產(chǎn)品維）。 試問你有超過千萬的用戶數(shù)據(jù)分析建模么？對于一般的分析（工程）師來說，常見的情況還是幾十萬甚或百萬級別。這個量級對于R來說就很容易了， 比如我剛剛的工作就是在自己的PC上載入了一個50000000×3的數(shù)據(jù)框。

接著我們在說說速度，曾經(jīng)有太多的人抱怨R的運行速度太慢，甚至堂而皇之的公開表明觀點。但我發(fā)現(xiàn)大部分人是因為不熟悉R語言的編程， 而是直接套用C或Java的編程方式，因而導致無法快速得到結果。舉兩個例子：

有次在微博上一位朋友抱怨說R做了一個幾千乘幾千的相關矩陣花了他1天時間，我當時就愕然了，然后默默地給了一個幾秒鐘搞定的腳本。
還有一次更具有代表性：我的項目組有個R的項目需要上線，于是直接把原始代碼交予了一位項目成員，囑咐他稍作改動即可上線。 但他發(fā)現(xiàn)需要3個小時才能將線上的數(shù)據(jù)計算完畢，于是又找到我?guī)兔?yōu)化。我看了一下，果不其然，Java風格的R代碼，向量化編程的思想 一點都沒有用。改之，3分鐘結束計算。

R語言的向量化運算幾乎可以和底層語言的速度一較高下，并且向量化是天然的并行化方式，如果條件允許，R的向量化編程可以很方便的轉化為并行框架， 這也就是為什么說R + Hadoop是大數(shù)據(jù)的發(fā)展方向的理由之一。

再說個例子：試問100萬行，20萬列的數(shù)據(jù)是大數(shù)據(jù)么（你沒看錯，是200000維）？恩，R能夠處理，而且可以在這類數(shù)據(jù)上構建模型。

對于管理者來說，合適的人出現(xiàn)合適的崗位是衡量管理者是否合格的重要標準之一。對于數(shù)據(jù)分析人員，合適的工具匹配合適的數(shù)據(jù)則是是否勝任工作的 基本素質之一。R并不是通吃所有的數(shù)據(jù)場景，它只是在出現(xiàn)在該出現(xiàn)的分析建模環(huán)節(jié)。

R的位置在哪里？先讓我們看看所謂的大數(shù)據(jù)是如何從企業(yè)中傳遞的：

• 從最底層的原始數(shù)據(jù)來看，PB級數(shù)據(jù)確實不是R所擅長，但這些數(shù)據(jù)有Hadoop或者其他高性能存儲和處理系統(tǒng)；
• 向上是針對于不同業(yè)務場景的數(shù)據(jù)集市，經(jīng)過清洗后，數(shù)據(jù)的規(guī)模則下降到了TB級；
• 再向上則是針對于特定任務的分析和挖掘模塊，數(shù)據(jù)已經(jīng)被整理到了GB級，這時候R的處理則是非常方便
• R分析的結果則是MB級的輸出，比如圖表、得分，或者是規(guī)則。比如規(guī)則很容易在數(shù)據(jù)集市這段做并行化計算
  

我的團隊在大量使用R作為分析建模工具，看似比較另類，但其實Google、Facebook、Linkedin等公司已經(jīng)有大量的直接使用R做分析挖掘的應用， 只是大家不太留意罷了。

一句話總結：R并不是在象牙塔里供科研人員玩耍的玩具，而是實實在在工業(yè)界使用的便捷環(huán)境。

當然，這里還有很多問題沒有展開，比如：

• R語言的數(shù)據(jù)挖掘應該在并行化環(huán)境完成還是在單臺機器的計算環(huán)境完成？
• 抽樣可否解決大數(shù)據(jù)挖掘問題？
• 生產(chǎn)中直接實施R環(huán)境是否可行？