大數(shù)據(jù)和云計算關系

關于大數(shù)據(jù)和云計算的關系人們通常會有誤解。而且也會把它們混起來說，分別做一句話直白解釋就是：云計算就是硬件資源的虛擬化；大數(shù)據(jù)就是海量數(shù)據(jù)的高效處理。

　　雖然上面的一句話解釋不是非常的貼切，但是可以幫助你簡單的理解二者的區(qū)別。另外，如果做一個更形象的解釋，云計算相當于我們的計算機和操作系統(tǒng)，將大量的硬件資源虛擬化之后再進行分配使用，在云計算領域目前的老大應該算是Amazon，可以說為云計算提供了商業(yè)化的標準，另外值得關注的還有VMware（其實從這一點可以幫助你理解云計算和虛擬化的關系），開源的云平臺最有活力的就是Openstack了；

　　大數(shù)據(jù)相當于海量數(shù)據(jù)的“數(shù)據(jù)庫”，而且通觀大數(shù)據(jù)領域的發(fā)展也能看出，當前的大數(shù)據(jù)處理一直在向著近似于傳統(tǒng)數(shù)據(jù)庫體驗的方向發(fā)展，Hadoop的產(chǎn)生使我們能夠用普通機器建立穩(wěn)定的處理TB級數(shù)據(jù)的集群，把傳統(tǒng)而昂貴的并行計算等概念一下就拉到了我們的面前，但是其不適合數(shù)據(jù)分析人員使用（因為MapReduce開發(fā)復雜），所以PigLatin和Hive出現(xiàn)了（分別是Yahoo！和facebook發(fā)起的項目，說到這補充一下，在大數(shù)據(jù)領域Google、facebook、twitter等前沿的互聯(lián)網(wǎng)公司作出了很積極和強大的貢獻），為我們帶來了類SQL的操作，到這里操作方式像SQL了，但是處理效率很慢，絕對和傳統(tǒng)的數(shù)據(jù)庫的處理效率有天壤之別，所以人們又在想怎樣在大數(shù)據(jù)處理上不只是操作方式類SQL，而處理速度也能“類SQL”，Google為我們帶來了Dremel/PowerDrill等技術，Cloudera（Hadoop商業(yè)化最強的公司，Hadoop之父cutting就在這里負責技術領導）的Impala也出現(xiàn)了。

　　整體來看，未來的趨勢是，云計算作為計算資源的底層，支撐著上層的大數(shù)據(jù)處理，而大數(shù)據(jù)的發(fā)展趨勢是，實時交互式的查詢效率和分析能力，借用Google一篇技術論文中的話，“動一下鼠標就可以在秒級操作PB級別的數(shù)據(jù)”難道不讓人興奮嗎？（田原）

　　在談大數(shù)據(jù)的時候，首先談到的就是大數(shù)據(jù)的4V特性，即類型復雜，海量，快速和價值。IBM原來談大數(shù)據(jù)的時候談3V，沒有價值這個V。而實際我們來看4V更加恰當，價值才是大數(shù)據(jù)問題解決的最終目標，其它3V都是為價值目標服務。在有了4V的概念后，就很容易簡化的來理解大數(shù)據(jù)的核心，即大數(shù)據(jù)的總體架構包括三層，數(shù)據(jù)存儲，數(shù)據(jù)處理和數(shù)據(jù)分析。類型復雜和海量由數(shù)據(jù)存儲層解決，快速和時效性要求由數(shù)據(jù)處理層解決，價值由數(shù)據(jù)分析層解決。

　　數(shù)據(jù)先要通過存儲層存儲下來，然后根據(jù)數(shù)據(jù)需求和目標來建立相應的數(shù)據(jù)模型和數(shù)據(jù)分析指標體系對數(shù)據(jù)進行分析產(chǎn)生價值。而中間的時效性又通過中間數(shù)據(jù)處理層提供的強大的并行計算和分布式計算能力來完成。三層相互配合，讓大數(shù)據(jù)最終產(chǎn)生價值。

　　數(shù)據(jù)存儲層

　　數(shù)據(jù)有很多分法，有結構化，半結構化，非結構化；也有元數(shù)據(jù)，主數(shù)據(jù)，業(yè)務數(shù)據(jù)；還可以分為GIS，視頻，文件，語音，業(yè)務交易類各種數(shù)據(jù)。傳統(tǒng)的結構化數(shù)據(jù)庫已經(jīng)無法滿足數(shù)據(jù)多樣性的存儲要求，因此在RDBMS基礎上增加了兩種類型，一種是hdfs可以直接應用于非結構化文件存儲，一種是nosql類數(shù)據(jù)庫，可以應用于結構化和半結構化數(shù)據(jù)存儲。

　　從存儲層的搭建來說，關系型數(shù)據(jù)庫，NoSQL數(shù)據(jù)庫和hdfs分布式文件系統(tǒng)三種存儲方式都需要。業(yè)務應用根據(jù)實際的情況選擇不同的存儲模式，但是為了業(yè)務的存儲和讀取方便性，我們可以對存儲層進一步的封裝，形成一個統(tǒng)一的共享存儲服務層，簡化這種操作。從用戶來講并不關心底層存儲細節(jié)，只關心數(shù)據(jù)的存儲和讀取的方便性，通過共享數(shù)據(jù)存儲層可以實現(xiàn)在存儲上的應用和存儲基礎設置的徹底解耦。

　　數(shù)據(jù)處理層

　　數(shù)據(jù)處理層核心解決問題在于數(shù)據(jù)存儲出現(xiàn)分布式后帶來的數(shù)據(jù)處理上的復雜度，海量存儲后帶來了數(shù)據(jù)處理上的時效性要求，這些都是數(shù)據(jù)處理層要解決的問題。

　　在傳統(tǒng)的云相關技術架構上，可以將hive，pig和hadoop-mapreduce框架相關的技術內(nèi)容全部劃入到數(shù)據(jù)處理層的能力。原來我思考的是將hive劃入到數(shù)據(jù)分析層能力不合適，因為hive重點還是在真正處理下的復雜查詢的拆分，查詢結果的重新聚合，而mapreduce本身又實現(xiàn)真正的分布式處理能力。

　　mapreduce只是實現(xiàn)了一個分布式計算的框架和邏輯，而真正的分析需求的拆分，分析結果的匯總和合并還是需要hive層的能力整合。最終的目的很簡單，即支持分布式架構下的時效性要求。

　　數(shù)據(jù)分析層

　　最后回到分析層，分析層重點是真正挖掘大數(shù)據(jù)的價值所在，而價值的挖掘核心又在于數(shù)據(jù)分析和挖掘。那么數(shù)據(jù)分析層核心仍然在于傳統(tǒng)的BI分析的內(nèi)容。包括數(shù)據(jù)的維度分析，數(shù)據(jù)的切片，數(shù)據(jù)的上鉆和下鉆，cube等。

　　數(shù)據(jù)分析我只關注兩個內(nèi)容，一個就是傳統(tǒng)數(shù)據(jù)倉庫下的數(shù)據(jù)建模，在該數(shù)據(jù)模型下需要支持上面各種分析方法和分析策略；其次是根據(jù)業(yè)務目標和業(yè)務需求建立的KPI指標體系，對應指標體系的分析模型和分析方法。解決這兩個問題基本解決數(shù)據(jù)分析的問題。

　　傳統(tǒng)的BI分析通過大量的ETL數(shù)據(jù)抽取和集中化，形成一個完整的數(shù)據(jù)倉庫，而基于大數(shù)據(jù)的BI分析，可能并沒有一個集中化的數(shù)據(jù)倉庫，或者將數(shù)據(jù)倉庫本身也是分布式的了，BI分析的基本方法和思路并沒有變化，但是落地到執(zhí)行的數(shù)據(jù)存儲和數(shù)據(jù)處理方法卻發(fā)生了大變化。

　　談了這么多，核心還是想說明大數(shù)據(jù)兩大核心為云技術和BI，離開云技術大數(shù)據(jù)沒有根基和落地可能，離開BI和價值，大數(shù)據(jù)又變化為舍本逐末，丟棄關鍵目標。簡單總結就是大數(shù)據(jù)目標驅(qū)動是BI，大數(shù)據(jù)實施落地式云技術。