大數(shù)據(jù)這個概念本身就太大而且太寬，如果一定要嚴格定義是非常困難的一件事，不過Hadoop生態(tài)圈或者由其延伸的泛生態(tài)系統(tǒng)，基本上都是為了處理大量數(shù)據(jù)誕生的——一般而言，這種數(shù)據(jù)依賴單機很難完成。

這個圈子里的工具，就像是我們廚房里的各種廚具——各自都有不同的用處，但也有一部分功能重合，比如盆和豌都可以用來喝湯，削皮刀和菜刀都可以用來去皮。

[[249259]]

但是，盆用來喝湯未免奇怪，削皮刀切菜也是萬萬不能。即使你強行要創(chuàng)造一些奇異的組合，即使最終完成工作，卻不一定是最快、最好的選擇。

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

對傳統(tǒng)的單機文件系統(tǒng)來說，橫跨不同機器幾乎是不可能完成的任務。而通過HDFS(Hadoop Distributed FileSystem)，你可以通過橫跨上千甚至上萬臺機器來完成大量數(shù)據(jù)得存儲，同時這些數(shù)據(jù)全部都能歸屬在同一個文件系統(tǒng)之下。你可以通過引用一個文件路徑獲取存儲在許多臺機器上的數(shù)據(jù)文件。作為一個使用者，你完全不用去計較文件具體存儲的位置，這個文件系統(tǒng)會為你搞定一切。

我們當然不是為了搜集數(shù)據(jù)而進行存儲，我們還要用數(shù)據(jù)做一些事情。雖然我們通過HDFS存下了橫跨上千臺機器的數(shù)據(jù)，我們依然面臨一個問題——這些數(shù)據(jù)過于龐大，如果只交給一臺機器處理，我們可能得等上幾周甚至更長。這些可能以T甚至于P來計量單位的數(shù)據(jù)，只靠一臺機器真的能跑到地老天荒。

對于很多公司，這是無法接受的事情——我們都知道有各種熱度排行，加入一臺機器處理這個數(shù)據(jù)、計算熱度、進行發(fā)布，可能一周之后出來結(jié)果，但大家早已經(jīng)不關心了。

所以使用大量機器進行處理是必然的選擇。在大量機器處理過程中，必須處理一些事務：任務分配、緊急情況處理、信息互通等等，這時候必須引入MapReduce / Tez / Spark 。這其中，前者可以成為計算引擎的第一代產(chǎn)品，后兩者則是經(jīng)過優(yōu)化后的下一代。MapReduce采用了非常簡單的計算模型設計，可以說只用了兩個計算的處理過程，但是這個工具已經(jīng)足夠應付大部分的大數(shù)據(jù)工作了。

什么是Map?什么是Reduce?

考慮如果你要統(tǒng)計一個巨大的文本文件存儲在類似HDFS上，你想要知道這個文本里各個詞的出現(xiàn)頻率。你啟動了一個MapReduce程序。Map階段，幾百臺機器同時讀取這個文件的各個部分，分別把各自讀到的部分分別統(tǒng)計出詞頻，產(chǎn)生類似(hello, 12100次)，(world，15214次)等等這樣的Pair(我這里把Map和Combine放在一起說以便簡化);這幾百臺機器各自都產(chǎn)生了如上的集合，然后又有幾百臺機器啟動Reduce處理。Reducer機器A將從Mapper機器收到所有以A開頭的統(tǒng)計結(jié)果，機器B將收到B開頭的詞匯統(tǒng)計結(jié)果(當然實際上不會真的以字母開頭做依據(jù)，而是用函數(shù)產(chǎn)生Hash值以避免數(shù)據(jù)串化。因為類似X開頭的詞肯定比其他要少得多，而你不希望數(shù)據(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ù)交換更靈活，更少的磁盤讀寫，以便更方便地描述復雜算法，取得更高的吞吐量。

有了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寫起來大約要幾十上百行。而更重要的是，非計算機背景的用戶終于感受到了愛：我也會寫SQL!于是數(shù)據(jù)分析人員終于從乞求工程師幫忙的窘境解脫出來，工程師也從寫奇怪的一次性的處理程序中解脫出來。大家都開心了。Hive逐漸成長成了大數(shù)據(jù)倉庫的核心組件。甚至很多公司的流水線作業(yè)集完全是用SQL描述，因為易寫易改，一看就懂，容易維護。

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

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

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

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