劃重點
大資料這個概念本身就太大而且太寬，如果一定要嚴格定義是非常困難的一件事，不過Hadoop生态圈或者由其延伸的泛生态系統，基本上都是為了處理大量資料誕生的——一般而言，這種資料依賴單機很難完成。
這個圈子裡的工具，就像是我們廚房裡的各種廚具——各自都有不同的用處，但也有一部分功能重合，比如盆和豌都可以用來喝湯，削皮刀和菜刀都可以用來去皮。
但是，盆用來喝湯未免奇怪，削皮刀切菜也是萬萬不能。即使你強行要創造一些奇異的組合，即使最終完成工作，卻不一定是最快、最好的選擇。
大資料，首先你要能存的下大資料。
對傳統的單機檔案系統來說，橫跨不同機器幾乎是不可能完成的任務。而通過HDFS（Hadoop Distributed FileSystem），你可以通過橫跨上千甚至上萬台機器來完成大量資料得存儲，同時這些資料全部都能歸屬在同一個檔案系統之下。你可以通過引用一個檔案路徑擷取存儲在許多台機器上的資料檔案。作為一個使用者，你完全不用去計較檔案具體存儲的位置，這個檔案系統會為你搞定一切。
我們當然不是為了搜集資料而進行存儲，我們還要用資料做一些事情。雖然我們通過HDFS存下了橫跨上千台機器的資料，我們依然面臨一個問題——這些資料過于龐大，如果隻交給一台機器處理，我們可能得等上幾周甚至更長。這些可能以T甚至于P來計量機關的資料，隻靠一台機器真的能跑到地老天荒。
對于很多公司，這是無法接受的事情——我們都知道有各種熱度排行，加入一台機器處理這個資料、計算熱度、進行釋出，可能一周之後出來結果，但大家早已經不關心了。
是以使用大量機器進行處理是必然的選擇。在大量機器處理過程中，必須處理一些事務：任務配置設定、緊急情況處理、資訊互通等等，這時候必須引入MapReduce / Tez / Spark 。這其中，前者可以成為計算引擎的第一代産品，後兩者則是經過優化後的下一代。MapReduce采用了非常簡單的計算模型設計，可以說隻用了兩個計算的處理過程，但是這個工具已經足夠應付大部分的大資料工作了。
什麼是Map？什麼是Reduce？
考慮如果你要統計一個巨大的文本檔案存儲在類似HDFS上，你想要知道這個文本裡各個詞的出現頻率。你啟動了一個MapReduce程式。Map階段，幾百台機器同時讀取這個檔案的各個部分，分别把各自讀到的部分分别統計出詞頻，産生類似
（hello, 12100次），（world，15214次）等等這樣的Pair（我這裡把Map和Combine放在一起說以便簡化）；這幾百台機器各自都産生了如上的集合，然後又有幾百台機器啟動Reduce處理。
Reducer機器A将從Mapper機器收到所有以A開頭的統計結果，機器B将收到B開頭的詞彙統計結果（當然實際上不會真的以字母開頭做依據，而是用函數産生Hash值以避免資料串化。因為類似X開頭的詞肯定比其他要少得多，而你不希望資料處理各個機器的工作量相差懸殊）。然後這些Reducer将再次彙總，（hello，12100）＋（hello，12311）＋（hello，345881）= （hello，370292）。每個Reducer都如上處理，你就得到了整個檔案的詞頻結果。
這看似是個很簡單的模型，但很多算法都可以用這個模型描述了。
Map＋Reduce的簡單模型很黃很暴力，雖然好用，但是很笨重。第二代的Tez和Spark除了記憶體Cache之類的新feature，本質上來說，是讓Map/Reduce模型更通用，讓Map和Reduce之間的界限更模糊，資料交換更靈活，更少的磁盤讀寫，以便更友善地描述複雜算法，取得更高的吞吐量。
有了MapReduce，Tez和Spark之後，程式員發現，MapReduce的程式寫起來真麻煩。他們希望簡化這個過程。這就好比你有了彙編語言，雖然你幾乎什麼都能幹了，但是你還是覺得繁瑣。你希望有個更高層更抽象的語言層來描述算法和資料處理流程。于是就有了Pig和Hive。Pig是接近腳本方式去描述MapReduce，Hive則用的是SQL。它們把腳本和SQL語言翻譯成MapReduce程式，丢給計算引擎去計算，而你就從繁瑣的MapReduce程式中解脫出來，用更簡單更直覺的語言去寫程式了。
有了Hive之後，人們發現SQL對比Java有巨大的優勢。一個是它太容易寫了。剛才詞頻的東西，用SQL描述就隻有一兩行，MapReduce寫起來大約要幾十上百行。而更重要的是，非計算機背景的使用者終于感受到了愛：我也會寫SQL！于是資料分析人員終于從乞求工程師幫忙的窘境解脫出來，工程師也從寫奇怪的一次性的處理程式中解脫出來。大家都開心了。Hive逐漸成長成了大資料倉庫的核心元件。甚至很多公司的流水線作業集完全是用SQL描述，因為易寫易改，一看就懂，容易維護。
自從資料分析人員開始用Hive分析資料之後，它們發現，Hive在MapReduce上跑，真雞巴慢！流水線作業集也許沒啥關系，比如24小時更新的推薦，反正24小時内跑完就算了。但是資料分析，人們總是希望能跑更快一些。比如我希望看過去一個小時内多少人在充氣娃娃頁面駐足，分别停留了多久，對于一個巨型網站海量資料下，這個處理過程也許要花幾十分鐘甚至很多小時。而這個分析也許隻是你萬裡長征的第一步，你還要看多少人浏覽了跳蛋多少人看了拉赫曼尼諾夫的CD，以便跟老闆彙報，我們的使用者是猥瑣男悶騷女更多還是文藝青年／少女更多。你無法忍受等待的折磨，隻能跟帥帥的工程師蝈蝈說，快，快，再快一點！
于是Impala，Presto，Drill誕生了（當然還有無數非著名的互動SQL引擎，就不一一列舉了）。三個系統的核心理念是，MapReduce引擎太慢，因為它太通用，太強壯，太保守，我們SQL需要更輕量，更激進地擷取資源，更專門地對SQL做優化，而且不需要那麼多容錯性保證（因為系統出錯了大不了重新啟動任務，如果整個處理時間更短的話，比如幾分鐘之内）。這些系統讓使用者更快速地處理SQL任務，犧牲了通用性穩定性等特性。如果說MapReduce是大砍刀，砍啥都不怕，那上面三個就是剔骨刀，靈巧鋒利，但是不能搞太大太硬的東西。
這些系統，說實話，一直沒有達到人們期望的流行度。因為這時候又兩個異類被造出來了。他們是Hive on Tez / Spark和SparkSQL。它們的設計理念是，MapReduce慢，但是如果我用新一代通用計算引擎Tez或者Spark來跑SQL，那我就能跑的更快。而且使用者不需要維護兩套系統。這就好比如果你廚房小，人又懶，對吃的精細程度要求有限，那你可以買個電鍋，能蒸能煲能燒，省了好多廚具。
上面的介紹，基本就是一個資料倉庫的構架了。底層HDFS，上面跑MapReduce／Tez／Spark，在上面跑Hive，Pig。或者HDFS上直接跑Impala，Drill，Presto。這解決了中低速資料處理的要求。
如何更高速的處理？
考慮一下，如果我需要更高的處理速度，我要展示的資料不再是24小時甚至更長尺度的資料報告，而是一個随時更新、随時變化的榜單，這個榜單的更新最好在1分鐘甚至更短，那麼上述手段就無發滿足我的需要。
這時候，另一個工具即将登場——Streaming計算模型。這種模型通常被稱為流計算模型，使用最多的平台式Storm。這種模型會在資料開始搜集的時候進行計算，而不是在搜集完成後——你每獲得一個資料都會加入到實時計算中成為最終成果的一份子。這種方式處理的資料基本不會存在延遲問題。
但它并不是盡善盡美。在使用流計算之前，我們必須預先找到統計的核心，因為一段資料經過處理就會放在一邊——正如流過的河水無法倒回一樣——未能提前找到統計核心的時候資料就被浪費掉了。這也是流計算無法完全替代我們前文講過的工具的原因。
另一個比較獨立的工具是KV Store，類似于Cassandra，HBase，MongoDB等等非常非常多的其他東西。他是什麼意思呢，假如你有一堆鍵值，你就能通過某種方式快速獲得鍵值背後的一大堆資料。就好像你去銀行插入銀行卡就能取到錢一樣。
假如你特立獨行，使用MapReduce完成也沒有任何問題，但是由此帶來的不便就是掃描資料庫的時間會很長。如果我們采用了KV Store，這種專門為了鍵值存取而設定的工具，那這個速度就會非常快。這個工具的核心就是快，其他的事情他一概不管，就是要快。
除此之外，還有一些更特制的系統／元件，比如Mahout是分布式機器學習庫，Protobuf是資料交換的編碼和庫，ZooKeeper是高一緻性的分布存取協同系統，等等。
當你拿到這麼多工具（甚至多到連很多東西的名字都寫不熟練）之後，你把他們拼裝在一起，如果沒有一個完美的安排大家就會互相打架，造成效率低下，是以這個時候還要引入一個排程系統，專門給大家安排任務、安排時間，使系統能夠良好運轉。
* 作者：Xiaoyu Ma
* 連結：https://www.zhihu.com/question/27974418/answer/38965760