“大數(shù)據(jù)”現(xiàn)在可謂越來越火了，不管是什么行業(yè)，也不敢是不是搞計算機的，都要趕個集，借著這股熱潮，亦或炒作，亦或大干一番。尤其是從事IT行業(yè)的，不跟“大數(shù)據(jù)”沾點邊，都不好意思出去說自己是干IT的。

“大數(shù)據(jù)”一詞，已無從考證具體是什么時候興起的，只是隱約記得大概火了三四年了吧。多大的數(shù)據(jù)算“大數(shù)據(jù)”哪？麥肯錫研究中心給出的定義是“超過一般計算機處理能力”的數(shù)據(jù)。好吧，這個概念真是投機取巧，讓人難以攻擊。因為大數(shù)據(jù)的界限真的難以定義。只能說我們平時自己保存和處理的數(shù)據(jù)都不是大數(shù)據(jù)。有些人以為自己電腦里有個特別大的Excel文件就是大數(shù)據(jù)；還有些人覺得有個數(shù)據(jù)庫裝了些數(shù)據(jù)就是大數(shù)據(jù)；有些悶騷男們說了：我專門買了個盤存了好幾T的片片那，看我有這么大的數(shù)據(jù)……這些都不是大數(shù)據(jù)。

按照麥肯錫的定義，既然大數(shù)據(jù)是一般的計算機都處理不了的數(shù)據(jù)，那么肯定不是幾個尺寸大點兒的文件就可以被稱之為大數(shù)據(jù)。筆者斗膽總結(jié)一下大數(shù)據(jù)的幾個特性：

首先，大數(shù)據(jù)肯定是存儲量很大的數(shù)據(jù)。

這是前提條件。業(yè)界沒有給出明確的數(shù)量定義，但肯定不能低于TB級。否則一般的個人電腦就可以輕松處理，就沒有多大的研究價值了。

其次，大數(shù)據(jù)一定是沒有明確組織規(guī)律的。

雖然局部可能有些規(guī)律可循，但總體上一定是沒有統(tǒng)一的規(guī)律了。否則也沒有多大的研究價值?？赡芗骖櫫吮砀?、圖片、日志等多種類型的數(shù)據(jù)，甚至可能會有各種格式的視頻和音頻流。

第三，大數(shù)據(jù)一定是不容易分析的。

接著第二點來說，大數(shù)據(jù)肯定不會是單純的存儲和組織方式，不會像我們平時自己造的表格那樣簡單明了。而且，我們無法從中分析出一個簡單統(tǒng)一的公式，使得所有數(shù)據(jù)都可以滿足這個公式。即便是可以分析出某些公式來，也會形成成百上千個公式。所以，大數(shù)據(jù)的分析一定不是一蹴而就的，而是分布開展的?？赡芟葧玫揭恍┳钤嫉囊?guī)律，再從這些原始規(guī)律中去分析出更高級的規(guī)律……不知會經(jīng)過多少步才會得到最終有些價值的信息。

第四、大數(shù)據(jù)一般是動態(tài)的。

大數(shù)據(jù)一般不會是死或一成不變的數(shù)據(jù)，而是會不斷追加新的數(shù)據(jù)，從而其尺寸不斷變大。比如常見的就是操作日志、監(jiān)測數(shù)據(jù)……等等。常見的大數(shù)據(jù)包括大型機場的訂票或飛行數(shù)據(jù)、大型超市的用戶購物記錄、證券公司股民的股票交易記錄、化工廠的設(shè)備運行監(jiān)測數(shù)據(jù)、城市出租車起止位置數(shù)據(jù)、煤礦等作業(yè)區(qū)域的人員定位數(shù)據(jù)……等等。這些數(shù)據(jù)除了數(shù)據(jù)量很大外，還會實時產(chǎn)生海量的新數(shù)據(jù)。所以進行大數(shù)據(jù)分析時要充分考慮到數(shù)據(jù)的變化因素。

第五、大數(shù)據(jù)一般是用于預(yù)測的。

正如上段內(nèi)容中介紹的，大數(shù)據(jù)環(huán)境一定是海量的數(shù)據(jù)環(huán)境，并且增量都有可能是海量的。大數(shù)據(jù)分析的價值就是從已有的數(shù)據(jù)中分析出固有的一些規(guī)律，從而能夠與未來新產(chǎn)生的數(shù)據(jù)相吻合，從而可以提前預(yù)測未來會發(fā)生的一些事件，或提供一些有價值的信息，提前進行決策和處置。

忽然想起了多年前大學(xué)期間學(xué)過一門課程，叫《數(shù)據(jù)挖掘》，里面提到了數(shù)據(jù)挖掘針對的對象是“數(shù)據(jù)倉庫”，指的就是數(shù)據(jù)量很大的數(shù)據(jù)。為此還提出了鉆取、抽析等多種分析方法和理論?，F(xiàn)在看來個人感覺大數(shù)據(jù)應(yīng)該就是從數(shù)據(jù)挖掘的基礎(chǔ)上發(fā)展起來的，只不過大數(shù)據(jù)面對的數(shù)據(jù)量比數(shù)據(jù)挖掘理論盛行時還要大很多個數(shù)量級吧。

正因為大數(shù)據(jù)的特殊性，所以已經(jīng)不能用通常的理論和方法來處理了。

首先是大數(shù)據(jù)的存儲。前面說了，大數(shù)據(jù)面對的數(shù)據(jù)量異常大，不是幾塊幾個TB的硬盤就可以隨隨便便容納得了的。而且個人電腦上的存儲設(shè)備一般也無法容納如此大量的數(shù)據(jù)。為了能夠提供快速、穩(wěn)定地存取這些數(shù)據(jù)，至少得依賴于磁盤陣列。同時還得通過分布式存儲的方式將不同區(qū)域、類別、級別的數(shù)據(jù)存放于不同的磁盤陣列中。

以往的關(guān)系型數(shù)據(jù)庫受限于設(shè)計模式的限制，一般只考慮到了單機的數(shù)據(jù)存儲方式，即不管數(shù)據(jù)量大與小，一定會讓一臺機器存儲和管理所有數(shù)據(jù)（即便是做集群，集群中的每個節(jié)點實際上也是要把所有的數(shù)據(jù)再存儲一遍）。而每臺機器上可以承載的存儲設(shè)備是有限的，一般也不會超過幾個TB。而且一旦某個數(shù)據(jù)庫的數(shù)據(jù)量和文件的尺寸暴增到一定程度后，數(shù)據(jù)的檢索速度就會急劇下降。

為了應(yīng)對這個問題，很多主流的數(shù)據(jù)庫紛紛提出了一些解決方案。如MySQL提供了MySQL proxy組件，實現(xiàn)了對請求的攔截，結(jié)合分布式存儲技術(shù)，從而可以將一張很大的表中的記錄拆分到不同的節(jié)點上去進行查詢。對于每個節(jié)點來說，數(shù)據(jù)量不會很大，從而提升了查詢效率。

而Oracle針對大數(shù)據(jù)公開可查詢的資料是“大數(shù)據(jù)機X3-2+Hadoop+NoSQL”的解決方案。在這套方案中，Oracle提供了擁有288個CPU、1152G內(nèi)存、648T硬盤的無比豪華的服務(wù)器配置，同時結(jié)合Hadoop和NoSQL等技術(shù)對其中存儲的大數(shù)據(jù)進行分析：

怎么說那，個人感覺Oracle完全是土豪策略：有錢你才能玩大數(shù)據(jù)，而有了錢你就買個特別?！恋臋C器，這樣你就不怕數(shù)據(jù)大了。實際上Oracle并沒有從根兒上專門為大數(shù)據(jù)而動過手術(shù)。

而對于像MongoDB、HBase等非關(guān)系型數(shù)據(jù)庫，由于擺脫了表的存儲模式，再加上起步較晚，所以對大數(shù)據(jù)的響應(yīng)要比關(guān)系型數(shù)據(jù)庫快的多。

MongoDB和HBase天生都支持分布式存儲，即將一份大的數(shù)據(jù)分散到不同的機器上進行存儲，從而降低了單個節(jié)點的存取壓力。

所以在實際應(yīng)用中，如果是針對老的系統(tǒng)尤其是老的數(shù)據(jù)庫進行大數(shù)據(jù)存儲及分析，那么只能考慮橫向拆分關(guān)系型數(shù)據(jù)庫中的數(shù)據(jù)了；如果是準(zhǔn)備建設(shè)新的系統(tǒng)，那么最好采用MongoDB，并使用分片集特性來存儲大數(shù)據(jù)。HBase也可以，但入門學(xué)習(xí)成本可能稍微有一些高。