它怎麼就大了呢？

20年前，386電腦上200MB的硬碟是主流配置，現在筆記本上的硬碟主流配置是500GB。大了 5*1024/2=2560倍。500GB大嗎？一部高清電影的大小在20GB左右，不過是25部高清，所以在家看高清的都是用1TB的硬碟，2塊。

做資料倉儲一般不會在系統裡處理高清電影，而是業務資料。電信運營商1.5億使用者每天的資料大概在90GB左右，資料倉儲各層合計的儲存規劃不到30TB。 而淘寶推出的資料產品，資料魔方，據說每天處理的資料有幾百TB，用將近200臺PC server搭成的Greenplum叢集來處理這些資料。幾百TB大嗎？

“大”是個相對的概念，沒有止境。現在之所以提大資料，是因為技術上出現了瓶頸，相對已有的技術來說，資料大了。是在用Oracle、DB2搭資料倉儲搭的很無奈，等報表等的很惆悵之後，才恍然發現資料大了。大就有問題，而且問題很多，但最主要的問題是慢！資料髒，資料假，領導一時都反映不過來，但如果讓領導等，領導開會前拿不到報告，他就會拍桌子罵人！或者乾脆不給錢.....

慢是因為如今的商業智慧（BI）架構不能有效的管理資料。資料處理再次進入了一個群雄割據、各顯其能的激烈競爭時代（上一次還是在關係型資料庫一紙定江山之前），是要為幾年後流淌著蜂蜜和牛奶的幸福生活流汗流血拼命搶地盤的時代。所以，大資料熱了。

當然，那是大廠商們的戰爭，大資料的歷史也是由他們譜寫的。作為一名只能喝湯度日的有志青年，怎麼搭上這班車？是很多IT屌絲午夜夢迴時都曾考慮過的問題吧。既然改變不了資料變大的事實，我們只好看看它大在哪裡了吧，想解決問題，總得知道問題是什麼。

它大在哪了呢？

程式設計師們做事務處理系統，或者叫業務系統已經做了很多年了。Oracle一直表現的挺好，系統實在太大了就搭RAC，也沒什麼大不了的。當然DB2也不錯，mysql也沒問題。用誰都能順利走完業務流程（資料庫免責宣告：賣票慢和我無關）。

商業智慧系統（分析系統）和業務系統不同，為了得到一個統計分析結果，要處理很多資料（包括各種關聯關係），做非常複雜的查詢和分析操作。如果直接處理細粒度的原始業務資料，相關資料的範圍會很大，甚至可能對應業務系統中幾十張表裡的全表資料。或者說，要從上億條記錄裡找出一條記錄不是大資料問題；而給上億條記錄分類，找出其中的規律就是大資料問題。因為需求變大了，範圍和複雜性變大了，所以資料變大了。

前面所說的資料都是很規整的關係型資料，不管按行儲存還是按列儲存，都是結構化資料。要想做到真正的智慧，只關注結構化資料是不行的。最好的例子就是搜尋引擎，它處理非結構化資料，產生半結構化甚至結構化資料，加快搜尋查詢的速度。這些非結構化資料非常多，email，系統日誌，系統事件，多媒體檔案，分析起來也更復雜。或者說，發微博不是大資料問題，但輿情監控是。因為需求變大了，資料來源變大了，所以資料變大了。

綜上所述，大資料和尺寸無關，和需求相連。

更快，更快，更快

耐心是一種美德，可忍耐也是有限度的。那麼好的機器跑兩個小時也不給個結果。當硬體不再是效能的救命稻草，怎麼辦？召喚新架構。

圖 1. 充門面的架構圖，不解釋

為適應大資料的處理需求，要在架構中整合新技術、新產品，渡過大資料難關。

大規模並行處理系統

解決大問題的終極辦法就是大事化小小事化了。分而治之，蓋無能出其右者。

MPP (Massively Parallel Processing)，大規模並行處理系統，由許多鬆耦合的處理單元組成的。每個單元都有自己私有的資源，有獨立的作業系統和管理資料庫例項。它最大的特點在於不共享資源。Greenplum，Sybase IQ，Elasticsearch 都支援這種結構。

Hadoop

Hadoop 專案開始於 2005 年秋天，當初是作為 Lucene的子專案 Nutch的一部分。受到 Google Lab 開發的 Map/Reduce 和 Google File System(GFS) 的啟發。2006 年 3 月份，Map/Reduce 和 Nutch Distributed File System (NDFS) 分別被納入Hadoop 的專案中。

MapReduce

MapReduce是由Google提出的軟體架構，包括兩個概念，“Map（對映）”和“Reduce（化簡）”，用於指導大規模資料集的並行運算。如果你瞭解函數語言程式設計的概念，應該對這兩個概念很熟悉。

對映函式對一個列表中的每個元素進行指定的操作。但它不會修改原始列表，而是建立一個新列表來儲存操作結果。不變的原始列表，元素上的獨立操作，所以Map操作是可以併發執行的。

化簡操作對一個列表的元素進行適當的合併。可以把列表拆成幾部分，各部分併發計算，然後遞迴。

Hadoop的架構

Hadoop 有許多元素構成。其最底部是 Hadoop Distributed File System（HDFS），它儲存 Hadoop 叢集中所有儲存節點上的檔案。HDFS（對於本文）的上一層是 MapReduce 引擎，該引擎由JobTrackers 和 TaskTrackers 組成。

對外部客戶機而言，HDFS 就像一個傳統的分級檔案系統。可以建立、刪除、移動或重新命名檔案，等等。但是 HDFS 的架構是基於一組特定的節點構建的，這是由它自身的特點決定的。這些節點包括 NameNode（僅一個），它在 HDFS 內部提供後設資料服務；DataNode，它為 HDFS 提供儲存塊。由於僅存在一個 NameNode，因此這是 HDFS 的一個缺點（單點失敗）。

儲存在 HDFS 中的檔案被分成塊，然後將這些塊複製到多個計算機中（DataNode）。這與傳統的 RAID 架構大不相同。塊的大小（通常為 64MB）和複製的塊數量在建立檔案時由客戶機決定。NameNode 可以控制所有檔案操作。HDFS 內部的所有通訊都基於標準的 TCP/IP 協議。

MapReduce則是JobTracker節點為主，分配工作以及負責和使用者程式通訊。使用者只要繼承MapReduceBase，提供分別實現Map和Reduce的兩個類，並註冊Job即可自動分散式執行。HDFS和MapReduce實現是完全分離的，並不是沒有HDFS就不能MapReduce運算。

基於語義計算系統

非結構化資訊的形式包括文件、電子郵件、電話錄音以及多媒體內容。基於語義計算技術使計算機能夠理解各中非結構化資訊之間的聯絡，進而執行復雜的分析操作。其中的關鍵技術是文字挖掘技術 。

基於語義計算技術與關鍵詞搜尋這些只能進行資料查詢與檢索的傳統方法不同。舉例而言，關鍵詞搜尋引擎不能理解資訊的含義，因此這些產品只能用於找出帶某個字詞的文件。然而由於無法理解含義，所以那些使用了不同字詞但主題卻相同（即有相關性）的文件將被忽略。而那些主題與使用者期望搜尋的內容完全不同的文件卻經常被返回，從而使得使用者必須修改查詢方式來適應這種搜尋引擎。

除此之外，基於語義的計算還能提供關鍵詞搜尋引擎無法提供的許多功能，例如自動形成超連結以及聚類。舉例而言，自動形成超連結可以向使用者提供眾多在語境上與原有的文件相互聯絡的文件、服務和產品，這就要求計算機能夠完全理解原有文件的含義。與此類似，要使計算機能夠自動收集、分析並組織資訊，就必須賦予其提取語義的能力。只有擁有基於語義計算技術的系統才能做到這一點。

R語言

R是一套完整的資料處理、計算和製圖軟體系統。其功能包括：資料儲存和處理系統；陣列運算工具（其向量、矩陣運算方面功能尤其強大）；完整連貫的統計分析工具；優秀的統計製圖功能；簡便而強大的程式語言：可操縱資料的輸入和輸出，可實現分支、迴圈，使用者可自定義功能 貝爾實驗室。

與其說R是一種統計軟體，還不如說R是一種數學計算的環境，因為R並不是僅僅提供若干統計程式、使用者只需指定資料庫和若干引數便可進行一個統計分析。R的思想是：它可以提供一些整合的統計工具，但更大量的是它提供各種數學計算、統計計算的函式，從而使使用者能靈活機動的進行資料分析，甚至創造出符合需要的新的統計計算方法。

該語言的語法表面上類似 C，但在語義上是函式設計語言的（functional programming language）的變種並且和Lisp 以及 APL有很強的相容性。特別的是，它允許在“語言上計算”（computing on the language）。這使得它可以把表示式作為函式的輸入引數，而這種做法對統計模擬和繪圖非常有用。

R是一個免費的自由軟體，它有UNIX、LINUX、MacOS和WINDOWS版本，都是可以免費下載和使用的。在那兒可以下載到R的安裝程式、各種外掛程式和文件。在R的安裝程式中只包含了8個基礎模組，其他外在模組可以通過CRAN獲得。

什麼最重要？

不管資料怎麼大，也是為了業務服務的。不管是要做精準營銷還是維繫挽留，或者瞭解市場上對公司品牌的認知度如何，歸根結底都是通過分析業務資料來促進業務。

商業智慧要為商業服務，就要對業務有更加深入透徹的瞭解，所以學會分析業務模型很重要，要能對企業架構建模和分析。比如電信行業的eTOM，通用的TOGAF等。如果你還恰好懂一點兒營銷和管理，那就太棒了。

此外還要對量化管理知識體系有所瞭解，知道該從哪裡入手，如何設定目標，要規避哪些風險（包括政治風險）。

各種統計分析知識及常用資料探勘演算法，知道怎麼做聚類、分類、迴歸、關聯規則分析。

熟悉資料視覺化，知道各種圖表的用法，關注新的資料視覺化方式。

參考資料

1. Lars Wriedt訪談
2. 基於語義計算技術
3. 全文搜尋引擎
4. MPP,SMP,NUMA概念介紹