對於一些文科生、商科生來說，剛剛搞懂服務器、數據庫、C++、Java等基礎語言是個什麼東西的時候，大數據時代來了。大數據時代，科技蜀黍們又玩起Hadoop、HDFS、MapReduce、Spark、HBase、NoSQL、Hive、pig……這些蛇精病和大怪獸了。看著這些彷若天書的大怪獸說明書，那叫一個崩潰。
於是，就有小夥伴跑來找小編能不能把能把這些混亂的技術妖詞，做一個生態的比喻？比成，一棵樹？一個城市？一個人的循環系統？隨便比……總之讓他們這些技術白痴也能搞明白，它們之間是什麼關係，誰是幹什麼的？
於是，這篇文章就這樣誕生了……（請原諒以下我風格的轉變，因為我要說一個很嚴肅的問題）
大數據本身是個很廣泛的概念，Hadoop生態圈基本上都是為了處理超過單個計算機所能計算處理的數據而誕生的。你可以把它想象成一個廚房中的各種廚具。什麼鍋碗瓢盆啊，各自有各自的用處，相互之間功能既能配合又有所重合。比如，你可以用鍋直接當碗吃飯，或者你可以用小刀去皮。雖然把奇怪的工具組合起來也能工作，但這未必是最佳選擇。
所以為了方便理解大數據生態工具的主要作用，我們先從大數據的存儲說起。
之前的數據文件系統是單機的，不能鏈接不同的機器。HDFS的誕生本質上是為了使大量的數據能橫跨成百上千臺機器，讓這些機器使用一個文件系統。比如你說我要獲取hdfs/tmp/file1的數據，你引用的是一個文件路徑，但是實際的數據存放在很多不同的機器上。你作為用戶，不需要知道這些，就好比你根本不用關心你電腦的文件分別存儲在什麼磁道什麼扇區一樣。HDFS就像一個大管家，為你管理這些數據，你只需要調用即可。
存好數據以後，你必須考慮怎麼處理這些數據。雖然HDFS可以幫你宏觀上管理不同機器上存的數據，但是這些數據太多太多了。
一臺機器讀取TB級別乃至PB級別的數據（這個數據非常非常大哦，比你看的小電影有史以來所有高清的總和還要大很多喲），需要慢慢跑好幾天甚至好幾周。對於許多公司來說，這種時長是不可忍受的，比如各種小時更新、每天更新的熱搜，它必須在規定時間之內跑完這些處理。
那如果用很多臺機器處理是不是就會快很多？使用多臺機器我們就面臨了如何分配工作的問題，以及如果一臺機器掛了如何重新啟動相應的任務，機器之間如何互相通信交換數據以完成複雜的計算等等。
處理這些問題就是MapReduce / Tez / Spark的功能。MapReduce是第一代計算引擎，Tez和Spark是第二代。MapReduce的設計，採用了簡化的計算模型，只有Map和Reduce兩個計算過程（中間用Shuffle串聯），用這個模型，已經可以處理大數據領域很大一部分問題了。
那什麼是Map？什麼是Reduce？
假如你要統計一個巨大的文本文件存儲在HDFS上，你想知道文本所有詞的出現頻率。你啟動了一個MapReduce程序，在Map階段，幾千臺機器同時讀取這個文本的各個部分，然後分別把各自獲取的部分分別統計單詞的出現頻率，產生類似（hello, 12100次），（world，15214次）的對應詞組；這幾千臺機器各自都產生了如上的集合，然後又有幾千臺機器啟動Reduce處理。
Reducer機器1將從Mapper機器獲取所有以A開頭的統計結果，機器2將獲取以B開頭的統計結果（實際上不會真的以字母作為開頭依據，而是用函數產生Hash值以避免數據互串。因為英文中X開頭的詞比其他的要少很多，而我們並不希望各個機器的工作量相差太大）。
然後這些Reducer將再次彙總，（hello，12100）＋（hello，12311）＋（hello，345881）= （hello，370292）。每個Reducer都像上方那樣處理，你就得到了整個文件的詞語出現頻率的結果。
這是個很簡單的模型，很多算法都可以用這個模型來描述。
Map＋Reduce的模型粗暴簡單，雖然很好用，但是很笨重。第二代的Tez和Spark除了內存存儲之類的新特徵，本質上來說，是讓Map/Reduce模型更具有適用性，讓Map和Reduce之間的數據交換更靈活，更少的磁盤讀寫，以便更方便地描述複雜算法，取得更高的吞吐量。
有了MapReduce，Tez和Spark之後，程序員蟈蟈們發現，MapReduce的程序寫起來真TM複雜，他們希望簡化這個過程。
於是就有了Pig和Hive。Pig是用接近腳本方式去描述MapReduce，Hive則用的是SQL。它們把腳本和SQL語言翻譯成MapReduce程序，丟給計算引擎去計算，而你就從複雜的MapReduce程序中解脫出來，用更簡單更直觀的語言去寫程序了。
有了Hive之後，人們發現SQL對比Java有巨大的優勢。SQL太容易寫了，剛才詞語出現頻率的問題，用SQL寫就是一兩行的事兒，而MapReduce寫起來要幾十上百行。更重要的是，這解放了非計算機背景的用戶：我也是會寫SQL的！
於是數據分析人員終於從每天跪舔工程師蟈蟈中解脫出來，工程師蟈蟈也從寫奇奇怪怪的一次性處理程序中釋放出來，這樣你好我好大家好，都開心了。因此，Hive逐漸成長為大數據倉庫的核心組件，因為易寫易改，一看就懂，容易維護。
自從數據分析人員開始用Hive分析數據之後，它們發現，Hive在MapReduce上跑，真TM慢！流水線作業也許還能用用，比如24小時更新的推薦，反正24小時內跑完就算了。
但是數據分析作業，人們總是希望能跑更快更快。比如我希望看過去一個小時內有多少人在情趣小道具的頁面駐足，分別停留了多長時間，對於一個像某寶這樣擁有海量數據的網站，這個處理過程可能要花幾十分鐘甚至N個小時。而這個分析只是你漫漫長路的第一步，你還要看多少人瀏覽了情趣衣服、多少人看了貝多芬的CD，以便跟boss彙報，我們的用戶是猥瑣男、悶騷女更多還是文藝青年更多。你無法忍受等待的折磨，只能跟帥帥的工程師蟈蟈說，快，快，再快一點！
於是Impala，Presto，Drill誕生了。這三個系統的核心設計理念是，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小時熱博，我想看一個不斷變化的熱播榜，更新延遲在一分鐘之內，上面的方法就無法勝任了。
於是又一種計算模型被開發出來，這就是Streaming（流）計算。流計算的思路是，如果想要實時的更新，我為什麼不在數據流進來的時候就處理了？比如詞頻統計的那個例子，數據流是一個一個的詞，我就讓他們一邊流過一邊統計。
流計算非常牛逼，基本沒有什麼延遲，但是它的缺點是，不靈活，想要統計的東西必須提前知道，畢竟數據流過就沒了，沒算的東西是沒有辦法補算的。因此它很方便，但是沒辦法替代上面數據倉庫和批處理系統。
有了這麼多亂七八糟的工具，都在同一個計算機集群上運轉，大家需要互相尊重有序的工作，所以這其中一個非常重要的組件是調度系統。現在最流行的是Yarn，你可以把他看作指揮工作的。好比你媽媽在廚房監工指揮，叫你切菜切完去拿刀殺雞。只要大家都服從你媽媽分配，那大家都能愉快滴燒菜。
所以大數據生態圈就是一個廚房工具生態圈，為了做中國菜，日本菜，法國菜，你需要各種不同的工具。而且隨著客人的需求越來越複雜，你使用的廚具也會不斷被髮明，也沒有一個萬用的廚具可以處理所有情況，因此整個生態圈裡的工具會變的越來越多、越來越複雜。
閱讀更多 睿帆大數據 的文章
