“大資料”現在可謂越來越火了，不管是什麼行業，也不敢是不是搞計算機的，都要趕個集，藉著這股熱潮，亦或炒作，亦或大幹一番。尤其是從事IT行業的，不跟“大資料”沾點邊，都不好意思出去說自己是幹IT的。

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

按照麥肯錫的定義，既然大資料是一般的計算機都處理不了的資料，那麼肯定不是幾個尺寸大點兒的檔案就可以被稱之為大資料。筆者斗膽總結一下大資料的幾個特性：

首先，大資料肯定是儲存量很大的資料。

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

其次，大資料一定是沒有明確組織規律的。

雖然區域性可能有些規律可循，但總體上一定是沒有統一的規律了。否則也沒有多大的研究價值。可能兼顧了表格、圖片、日誌等多種型別的資料，甚至可能會有各種格式的視訊和音訊流。

第三，大資料一定是不容易分析的。

接著第二點來說，大資料肯定不會是單純的儲存和組織方式，不會像我們平時自己造的表格那樣簡單明瞭。而且，我們無法從中分析出一個簡單統一的公式，使得所有資料都可以滿足這個公式。即便是可以分析出某些公式來，也會形成成百上千個公式。所以，大資料的分析一定不是一蹴而就的，而是分佈開展的。可能先會得到一些最原始的規律，再從這些原始規律中去分析出更高階的規律……不知會經過多少步才會得到最終有些價值的資訊。

第四、大資料一般是動態的。

大資料一般不會是死或一成不變的資料，而是會不斷追加新的資料，從而其尺寸不斷變大。比如常見的就是操作日誌、監測資料……等等。常見的大資料包括大型機場的訂票或飛行資料、大型超市的使用者購物記錄、證券公司股民的股票交易記錄、化工廠的裝置執行監測資料、城市計程車起止位置資料、煤礦等作業區域的人員定位資料……等等。這些資料除了資料量很大外，還會實時產生海量的新資料。所以進行大資料分析時要充分考慮到資料的變化因素。

第五、大資料一般是用於預測的。

正如上段內容中介紹的，大資料環境一定是海量的資料環境，並且增量都有可能是海量的。大資料分析的價值就是從已有的資料中分析出固有的一些規律，從而能夠與未來新產生的資料相吻合，從而可以提前預測未來會發生的一些事件，或提供一些有價值的資訊，提前進行決策和處置。

忽然想起了多年前大學期間學過一門課程，叫《資料探勘》，裡面提到了資料探勘針對的物件是“資料倉庫”，指的就是資料量很大的資料。為此還提出了鑽取、抽析等多種分析方法和理論。現在看來個人感覺大資料應該就是從資料探勘的基礎上發展起來的，只不過大資料面對的資料量比資料探勘理論盛行時還要大很多個數量級吧。

正因為大資料的特殊性，所以已經不能用通常的理論和方法來處理了。

首先是大資料的儲存。前面說了，大資料面對的資料量異常大，不是幾塊幾個TB的硬碟就可以隨隨便便容納得了的。而且個人電腦上的儲存裝置一般也無法容納如此大量的資料。為了能夠提供快速、穩定地存取這些資料，至少得依賴於磁碟陣列。同時還得通過分散式儲存的方式將不同區域、類別、級別的資料存放於不同的磁碟陣列中。

以往的關係型資料庫受限於設計模式的限制，一般只考慮到了單機的資料儲存方式，即不管資料量大與小，一定會讓一臺機器儲存和管理所有資料(即便是做叢集，叢集中的每個節點實際上也是要把所有的資料再儲存一遍)。而每臺機器上可以承載的儲存裝置是有限的，一般也不會超過幾個TB。而且一旦某個資料庫的資料量和檔案的尺寸暴增到一定程度後，資料的檢索速度就會急劇下降。

為了應對這個問題，很多主流的資料庫紛紛提出了一些解決方案。如MySQL提供了MySQL proxy元件，實現了對請求的攔截，結合分散式儲存技術，從而可以將一張很大的表中的記錄拆分到不同的節點上去進行查詢。對於每個節點來說，資料量不會很大，從而提升了查詢效率。

而Oracle針對大資料公開可查詢的資料是“大資料機X3-2+Hadoop+NoSQL”的解決方案。在這套方案中，Oracle提供了擁有288個CPU、1152G記憶體、648T硬碟的無比豪華的伺服器配置，同時結合Hadoop和NoSQL等技術對其中儲存的大資料進行分析：

怎麼說那，個人感覺Oracle完全是土豪策略：有錢你才能玩大資料，而有了錢你就買個特別牛×的機器，這樣你就不怕資料大了。實際上Oracle並沒有從根兒上專門為大資料而動過手術。

而對於像MongoDB、HBase等非關係型資料庫，由於擺脫了表的儲存模式，再加上起步較晚，所以對大資料的響應要比關係型資料庫快的多。

MongoDB和HBase天生都支援分散式儲存，即將一份大的資料分散到不同的機器上進行儲存，從而降低了單個節點的存取壓力。

所以在實際應用中，如果是針對老的系統尤其是老的資料庫進行大資料儲存及分析，那麼只能考慮橫向拆分關係型資料庫中的資料了；如果是準備建設新的系統，那麼最好採用MongoDB，並使用分片集特性來儲存大資料。HBase也可以，但入門學習成本可能稍微有一些高。