??????既然大數(shù)據(jù)有價值，那么就先將數(shù)據(jù)存起來。要發(fā)揮數(shù)據(jù)的價值，我們先要有數(shù)據(jù)。

• 網(wǎng)站瀏覽點擊行為日志存儲每個人都有潛在的能量，只是很容易被習(xí)慣所掩蓋，被時間所迷離，被惰性所消磨。
• 簡單的PV與UV統(tǒng)計，滿足基本需求
• 更注重存儲能力、集群規(guī)模、擴(kuò)展能力

開始注重對大數(shù)據(jù)的整合，構(gòu)成全角度的數(shù)據(jù)。

Hive技術(shù)的興起，目前阿里騰訊的萬臺規(guī)模以上的集群80%以上的都是類Hive任務(wù)。

• 先將內(nèi)部將數(shù)據(jù)用起來，發(fā)揮數(shù)據(jù)的價值。
• 內(nèi)部員工畢竟挖掘手段比較片面，進(jìn)一步的將數(shù)據(jù)開放出去，讓外部的用戶參與進(jìn)來，幫忙挖掘數(shù)據(jù)，雙方均得利。

數(shù)據(jù)的時效性與響應(yīng)時間，變得越來越重要，誰的快，誰就能爭奪商業(yè)上的先機(jī)。

Hadoop生態(tài)圈里的新技術(shù)?Spark、Impala、Kylin、Druid、Storm等技術(shù)，無不在快上下功夫。

• 支付寶黃金策海量多維數(shù)據(jù)2秒即席分析
• 騰訊廣告系統(tǒng)，海量人群即席創(chuàng)建、即席廣告推送

??????大數(shù)據(jù)如今已經(jīng)不再是什么新的名詞，五中全會大數(shù)據(jù)上升為國家戰(zhàn)略，BAT巨頭早已布局多年，大數(shù)據(jù)時代已經(jīng)真正來臨，但我們真的準(zhǔn)備好了么？

大家都知道大數(shù)據(jù)中蘊(yùn)含大量的數(shù)據(jù)價值，比如說淘寶與天貓的用戶消費(fèi)行為、滴滴打車可以知道用戶每天去了哪里、用戶在優(yōu)酷上都看了那些視頻、移動運(yùn)營商的海量客戶終端信息以及上網(wǎng)行為 、大型零售商每天的銷售數(shù)據(jù)、訂餐網(wǎng)上用戶每天吃了什么，等等大數(shù)據(jù)金礦無處不在。但淘出來的才是金子，否則只是一堆土而已，即占用場地，還要花錢去保管和維護(hù)這堆土。

大數(shù)據(jù)時代金礦已經(jīng)有了，如何利用好這個金礦，某種意義上取決于我們手上的工具。熟話說“沒有那金剛鉆，就別攬瓷器活”，工具是否適用，直接決定著我們能否進(jìn)行挖金，以及挖金的速度與效率。適合用鐵鍬還是挖掘機(jī)，對挖金來說有著質(zhì)的不同。

大數(shù)據(jù)本身是個很寬泛的概念，Hadoop生態(tài)圈（或者泛生態(tài)圈）基本上都是為了處理超過單機(jī)尺度的數(shù)據(jù)處理而誕生的。你可以把它比作一個廚房所以需要的各種工具，鍋碗瓢盆，各有各的用處，互相之間又有重合。你可以用湯鍋直接當(dāng)碗吃飯喝湯，你可以用小刀或者刨子去皮。但是每個工具有自己的特性，雖然奇怪的組合也能工作，但是未必是最佳選擇。

????????大數(shù)據(jù)，首先你要能存的下大數(shù)據(jù)。

傳統(tǒng)的文件系統(tǒng)是單機(jī)的，不能橫跨不同的機(jī)器。HDFS（Hadoop Distributed FileSystem）的設(shè)計本質(zhì)上是為了大量的數(shù)據(jù)能橫跨成百上千臺機(jī)器，但是你看到的是一個文件系統(tǒng)而不是很多文件系統(tǒng)。比如你說我要獲取/hdfs/tmp/file1的數(shù)據(jù)，你引用的是一個文件路徑，但是實際的數(shù)據(jù)存放在很多不同的機(jī)器上。你作為用戶，不需要知道這些，就好比在單機(jī)上你不關(guān)心文件分散在什么磁道什么扇區(qū)一樣。HDFS為你管理這些數(shù)據(jù)。

??????存的下數(shù)據(jù)之后，你就開始考慮怎么處理數(shù)據(jù)。雖然HDFS可以為你整體管理不同機(jī)器上的數(shù)據(jù)，但是這些數(shù)據(jù)太大了。一臺機(jī)器讀取成T上P的數(shù)據(jù)（很大的數(shù)據(jù)哦，比如整個東京熱有史以來所有高清電影的大小甚至更大），一臺機(jī)器慢慢跑也許需要好幾天甚至好幾周。對于很多公司來說，單機(jī)處理是不可忍受的，比如微博要更新24小時熱博，它必須在24小時之內(nèi)跑完這些處理。那么我如果要用很多臺機(jī)器處理，我就面臨了如何分配工作，如果一臺機(jī)器掛了如何重新啟動相應(yīng)的任務(wù)，機(jī)器之間如何互相通信交換數(shù)據(jù)以完成復(fù)雜的計算等等。這就是MapReduce / Tez /?Spark的功能，MapReduce是第一代計算引擎，Tez和Spark是第二代。MapReduce的設(shè)計，采用了很簡化的計算模型，只有Map和Reduce兩個計算過程（中間用Shuffle串聯(lián)），使用這個模型，已經(jīng)可以處理大數(shù)據(jù)領(lǐng)域很大一部分問題了。

那什么是Map，什么是Reduce？

考慮如果你要統(tǒng)計一個巨大的文本文件（存儲在類似HDFS上），你想要知道這個文本里各個詞的出現(xiàn)頻率。你啟動了一個MapReduce程序。Map階段，幾百臺機(jī)器同時讀取這個文件的各個部分，分別把各自讀到的部分分別統(tǒng)計出詞頻，產(chǎn)生類似（hello, 12100次），（world，15214次）等等這樣的Pair（這里把Map和Combine放在一起說以便簡化）；這幾百臺機(jī)器各自都產(chǎn)生了如上的集合，然后又有幾百臺機(jī)器啟動Reduce處理。Reducer機(jī)器A將從Mapper機(jī)器收到所有以A開頭的統(tǒng)計結(jié)果，機(jī)器B將收到B開頭的詞匯統(tǒng)計結(jié)果（當(dāng)然實際上不會真的以字母開頭做依據(jù)，而是用函數(shù)產(chǎn)生Hash值以避免數(shù)據(jù)串化。因為類似X開頭的詞肯定比其他要少得多，而你不希望數(shù)據(jù)處理各個機(jī)器的工作量相差懸殊）。然后這些Reducer將再次匯總，如（hello，12100）＋（hello，12311）＋（hello，345881）= （hello，370292）。每個Reducer都如上處理，你就得到了整個文件的詞頻結(jié)果。

這看似是個很簡單的模型，但很多算法都可以用這個模型描述了。

Map＋Reduce的簡單模型很直接很暴力，雖然好用，但是很笨重。第二代的Tez和Spark除了內(nèi)存Cache之類的新feature，本質(zhì)上來說，是讓Map/Reduce模型更通用，讓Map和Reduce之間的界限更模糊，數(shù)據(jù)交換更靈活，更少的磁盤讀寫，以便更方便地描述復(fù)雜算法，取得更高的吞吐量。

??????有了MapReduce、Tez和Spark之后，程序員發(fā)現(xiàn)，MapReduce的程序?qū)懫饋碚媛闊Ｍ芎喕@個過程。這就好比你有了匯編語言，雖然你幾乎什么都能干了，但是你還是覺得繁瑣，希望有個更高層更抽象的語言層來描述算法和數(shù)據(jù)處理流程。于是就有了Pig和Hive，Pig是接近腳本方式去描述MapReduce，Hive則用的是SQL。它們把腳本和SQL語言翻譯成MapReduce程序，丟給計算引擎去計算，而你就從繁瑣的MapReduce程序中解脫出來，用更簡單更直觀的語言去寫程序了。

有了Hive之后，人們發(fā)現(xiàn)SQL對比Java有巨大的優(yōu)勢。一個是它太容易寫了，剛才詞頻的東西，用SQL描述就只有一兩行，而MapReduce寫起來大約要幾十上百行。更重要的是，非計算機(jī)背景的用戶終于感受到了愛：我也會寫SQL！于是數(shù)據(jù)分析人員終于從乞求工程師幫忙的窘境解脫出來，工程師也從寫奇怪的一次性的處理程序中解脫出來，大家都開心了。Hive逐漸成長成了大數(shù)據(jù)倉庫的核心組件。甚至很多公司的流水線作業(yè)集完全是用SQL描述，因為易寫易改，一看就懂，容易維護(hù)。

????????自從數(shù)據(jù)分析人員開始用Hive分析數(shù)據(jù)之后，它們發(fā)現(xiàn)Hive在MapReduce上跑，慢如流水！流水線作業(yè)集也許沒啥關(guān)系，比如24小時更新的推薦，反正24小時內(nèi)跑完就算了。但是數(shù)據(jù)分析時，人們總是希望能跑更快一些。比如我希望看過去一個小時內(nèi)多少人在天線寶寶頁面駐足，分別停留了多久，對于一個巨型網(wǎng)站的海量數(shù)據(jù)，這個處理過程也許要花幾十分鐘甚至很多小時。而這個分析也許只是萬里長征的第一步，你還要看多少人瀏覽了游戲，多少人看了拉赫曼尼諾夫的CD，以便跟老板匯報，我們的用戶是宅男更多還是文藝青年／少女更多。你無法忍受等待的折磨，只能跟帥帥的工程師蟈蟈說，快，快，再快一點！

于是Impala，Presto，Drill誕生了（當(dāng)然還有無數(shù)非著名的交互SQL引擎，就不一一列舉了）。三個系統(tǒng)的核心理念是，MapReduce引擎太慢，因為它太通用、太強(qiáng)壯、太保守，我們SQL需要更輕量、更激進(jìn)地獲取資源、更專門地對SQL做優(yōu)化，而且不需要那么多容錯性保證（因為系統(tǒng)出錯了大不了重新啟動任務(wù)，如果整個處理時間更短的話，比如幾分鐘之內(nèi)）。這些系統(tǒng)讓用戶更快速地處理SQL任務(wù)，犧牲了通用性、穩(wěn)定性等特性。如果說MapReduce是大砍刀，砍啥都不怕，那上面三個就是剔骨刀，靈巧鋒利，但是不能搞太大太硬的東西。

????????這些系統(tǒng)，說實話，一直沒有達(dá)到人們期望的流行度。因為這時候又兩個異類被造出來了，他們是Hive on Tez / Spark和SparkSQL。它們的設(shè)計理念是，MapReduce慢，但是如果我用新一代通用計算引擎Tez或者Spark來跑SQL，那我就能跑的更快，而且用戶不需要維護(hù)兩套系統(tǒng)。這就好比如果你廚房小，人又懶，對吃的精細(xì)程度要求有限，那你可以買個電飯煲，能蒸能煲能燒，省了好多廚具。

????????上面的介紹，基本就是一個數(shù)據(jù)倉庫的構(gòu)架了。底層HDFS，上面跑MapReduce／Tez／Spark，再在上面跑Hive、Pig?；蛘逪DFS上直接跑Impala，Drill，Presto。這解決了中低速數(shù)據(jù)處理的要求。

那如果我要更高速的處理呢？

如果我是一個類似微博的公司，我希望顯示不只是24小時熱博，我想看一個不斷變化的熱播榜，更新延遲在一分鐘之內(nèi)，上面的手段都將無法勝任。于是又一種計算模型被開發(fā)出來，這就是Streaming（流）計算。Storm是最流行的流計算平臺。流計算的思路是，如果要達(dá)到更實時的更新，我何不在數(shù)據(jù)流進(jìn)來的時候就處理了？比如還是詞頻統(tǒng)計的例子，我的數(shù)據(jù)流是一個一個的詞，我就讓他們一邊流過我就一邊開始統(tǒng)計了。流計算很高明，基本無延遲，但是它的短處是不靈活，你想要統(tǒng)計的東西必須預(yù)先知道，畢竟數(shù)據(jù)流過就沒了，你沒算的東西就無法補(bǔ)算了。雖然它是個很好的東西，但是無法替代上面數(shù)據(jù)倉庫和批處理系統(tǒng)。

????????還有一個有些獨立的模塊是KV Store，比如Cassandra、Hbase、MongoDB以及很多很多很多很多其他的（多到無法想象）。KV Store就是說，由于我有一堆鍵值（key），我能很快速滴獲取與這個Key綁定的數(shù)據(jù)。比如我用身份證號就能取到你的身份數(shù)據(jù)。這個動作用MapReduce也能完成，但是很可能要掃描整個數(shù)據(jù)集。而KV Store專用來處理這個操作，所有存和取都專門為此優(yōu)化了。從幾個P的數(shù)據(jù)中查找一個身份證號，也許只要零點幾秒。這讓大數(shù)據(jù)公司的一些專門操作被大大優(yōu)化了。比如我網(wǎng)頁上有個根據(jù)訂單號查找訂單內(nèi)容的頁面，而整個網(wǎng)站的訂單數(shù)量無法單機(jī)數(shù)據(jù)庫存儲，我就會考慮用KV Store來存。KV Store的理念是，基本無法處理復(fù)雜的計算，大多沒法JOIN，也許沒法聚合，沒有強(qiáng)一致性保證（不同數(shù)據(jù)分布在不同機(jī)器上，你每次讀取也許會讀到不同的結(jié)果，也無法處理類似銀行轉(zhuǎn)賬那樣的強(qiáng)一致性要求的操作），但是就是快、極快。

每個不同的KV Store設(shè)計都有不同取舍，有些更快，有些容量更高，有些可以支持更復(fù)雜的操作。必有一款適合你。

???????YDB是延云針對用戶對大數(shù)據(jù)探索式、即席分析的需求而開發(fā)的分析軟件，可以說是筆者的心頭好。

YDB將傳統(tǒng)數(shù)據(jù)庫索引技術(shù)應(yīng)用在大數(shù)據(jù)技術(shù)上，打破目前大數(shù)據(jù)計算技術(shù)的僵局。將大數(shù)據(jù)檢索向時效性更強(qiáng)，查詢方式更靈活，執(zhí)行效率更高的方向演進(jìn)。雖然引用傳統(tǒng)索引技術(shù)，但是對硬件的需求并不比Hadoop高，不會讓小型用戶望而卻步。技術(shù)上YDB采用Java語言編寫，接地氣，SQL接口，用戶也更易于上手使用，同時每天千億增量萬億總量的數(shù)據(jù)量也能滿足高端用戶的需求。YDB主要技術(shù)方向在大索引，大索引的好處在于加快了檢索的速度，減少查詢中的分組、統(tǒng)計和排序時間，通過提高系統(tǒng)的性能和響應(yīng)時間來節(jié)約資源。大索引技術(shù)的運(yùn)用才能使YDB在如此大規(guī)模的數(shù)據(jù)量下依然保持查詢響應(yīng)時間在幾秒，數(shù)據(jù)導(dǎo)入延遲在幾分鐘。

大數(shù)據(jù)年代拼的不僅僅是數(shù)據(jù)量有多大，還要拼速度，拼誰的更快、更準(zhǔn)、本錢更低。大數(shù)據(jù)的運(yùn)用范疇還在不斷的擴(kuò)大，大索引技術(shù)還有很長的路要走。終有一天大數(shù)據(jù)會帶給咱們震懾國際的影響。