如何用形象的比喻描述大數據的技術生態？Hadoop、Hive、Spark 之間是什麼關係？
對於我們這些文科，商科生來說。我們剛剛搞懂伺服器，資料庫，C++，Java等基礎語言是個什麼東西的時候，大數據時代來了，科技蜀黍又玩起Hadoop，HDFS，MapReduce，Common，Spark，Mahout，HBase，NoSQL，Cassandra，GFS, MapReduce, BigTable，Hive，Pig……這些蛇精病和大怪獸了。我不認識它們，還有什麼妖怪沒記進來的，請各位繼續在評論里補充。
可各位大神能不能把這些混亂的技術妖詞（對不起，正是因為不懂，所以很亂），做一個生態的比喻？比成，一棵樹？一個城市？一個人的循環系統？隨便你比……總之讓我們這些技術白痴也能搞明白，它們之間是什麼關係，誰是幹什麼的？
叩謝。
大數據本身是個很寬泛的概念，Hadoop生態圈（或者泛生態圈）基本上都是為了處理超過單機尺度的數據處理而誕生的。你可以把它比作一個廚房所以需要的各種工具。鍋碗瓢盆，各有各的用處，互相之間又有重合。你可以用湯鍋直接當碗吃飯喝湯，你可以用小刀或者刨子去皮。但是每個工具有自己的特性，雖然奇怪的組合也能工作，但是未必是最佳選擇。
大數據，首先你要能存的下大數據。
傳統的文件系統是單機的，不能橫跨不同的機器。HDFS（Hadoop Distributed FileSystem）的設計本質上是為了大量的數據能橫跨成百上千台機器，但是你看到的是一個文件系統而不是很多文件系統。比如你說我要獲取/hdfs/tmp/file1的數據，你引用的是一個文件路徑，但是實際的數據存放在很多不同的機器上。你作為用戶，不需要知道這些，就好比在單機上你不關心文件分散在什麼磁軌什麼扇區一樣。HDFS為你管理這些數據。
存的下數據之後，你就開始考慮怎麼處理數據。雖然HDFS可以為你整體管理不同機器上的數據，但是這些數據太大了。一台機器讀取成T上P的數據（很大的數據哦，比如整個東京熱有史以來所有高清電影的大小甚至更大），一台機器慢慢跑也許需要好幾天甚至好幾周。對於很多公司來說，單機處理是不可忍受的，比如微博要更新24小時熱博，它必須在24小時之內跑完這些處理。那麼我如果要用很多台機器處理，我就面臨了如何分配工作，如果一台機器掛了如何重新啟動相應的任務，機器之間如何互相通信交換數據以完成複雜的計算等等。這就是MapReduce / Tez / Spark的功能。MapReduce是第一代計算引擎，Tez和Spark是第二代。MapReduce的設計，採用了很簡化的計算模型，只有Map和Reduce兩個計算過程（中間用Shuffle串聯），用這個模型，已經可以處理大數據領域很大一部分問題了。
那什麼是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小時熱博，我想看一個不斷變化的熱播榜，更新延遲在一分鐘之內，上面的手段都將無法勝任。於是又一種計算模型被開發出來，這就是Streaming（流）計算。Storm是最流行的流計算平台。流計算的思路是，如果要達到更實時的更新，我何不在數據流進來的時候就處理了？比如還是詞頻統計的例子，我的數據流是一個一個的詞，我就讓他們一邊流過我就一邊開始統計了。流計算很牛逼，基本無延遲，但是它的短處是，不靈活，你想要統計的東西必須預先知道，畢竟數據流過就沒了，你沒算的東西就無法補算了。因此它是個很好的東西，但是無法替代上面數據倉庫和批處理系統。
還有一個有些獨立的模塊是KV Store，比如Cassandra，HBase，MongoDB以及很多很多很多很多其他的（多到無法想像）。所以KV Store就是說，我有一堆鍵值，我能很快速滴獲取與這個Key綁定的數據。比如我用身份證號，能取到你的身份數據。這個動作用MapReduce也能完成，但是很可能要掃描整個數據集。而KV Store專用來處理這個操作，所有存和取都專門為此優化了。從幾個P的數據中查找一個身份證號，也許只要零點幾秒。這讓大數據公司的一些專門操作被大大優化了。比如我網頁上有個根據訂單號查找訂單內容的頁面，而整個網站的訂單數量無法單機資料庫存儲，我就會考慮用KV Store來存。KV Store的理念是，基本無法處理複雜的計算，大多沒法JOIN，也許沒法聚合，沒有強一致性保證（不同數據分布在不同機器上，你每次讀取也許會讀到不同的結果，也無法處理類似銀行轉賬那樣的強一致性要求的操作）。但是丫就是快。極快。
每個不同的KV Store設計都有不同取捨，有些更快，有些容量更高，有些可以支持更複雜的操作。必有一款適合你。
除此之外，還有一些更特製的系統／組件，比如Mahout是分散式機器學習庫，Protobuf是數據交換的編碼和庫，ZooKeeper是高一致性的分布存取協同系統，等等。
有了這麼多亂七八糟的工具，都在同一個集群上運轉，大家需要互相尊重有序工作。所以另外一個重要組件是，調度系統。現在最流行的是Yarn。你可以把他看作中央管理，好比你媽在廚房監工，哎，你妹妹切菜切完了，你可以把刀拿去殺雞了。只要大家都服從你媽分配，那大家都能愉快滴燒菜。
你可以認為，大數據生態圈就是一個廚房工具生態圈。為了做不同的菜，中國菜，日本菜，法國菜，你需要各種不同的工具。而且客人的需求正在複雜化，你的廚具不斷被發明，也沒有一個萬用的廚具可以處理所有情況，因此它會變的越來越複雜。學習很重要的是能將紛繁複雜的信息進行歸類和抽象。
對應到大數據技術體系，雖然各種技術百花齊放，層出不窮，但大數據技術本質上無非解決4個核心問題。
- 存儲，海量的數據怎樣有效的存儲？主要包括hdfs、Kafka；
- 計算，海量的數據怎樣快速計算？主要包括MapReduce、Spark、Flink等；
- 查詢，海量數據怎樣快速查詢？主要為Nosql和Olap，Nosql主要包括Hbase、 Cassandra 等，其中olap包括kylin、impla等，其中Nosql主要解決隨機查詢，Olap技術主要解決關聯查詢；
- 挖掘，海量數據怎樣挖掘出隱藏的知識？也就是當前火熱的機器學習和深度學習等技術，包括TensorFlow、caffe、mahout等；
大數據技術生態其實是一個江湖....
在一個夜黑風高的晚上，江湖第一大幫會Google三本陣法修鍊秘籍流出，大數據技術江湖從此紛爭四起、永無寧日...
這三本秘籍分別為：
- 《Google file system》：論述了怎樣藉助普通機器有效的存儲海量的大數據；
- 《Google MapReduce》：論述了怎樣快速計算海量的數據；
- 《Google BigTable》：論述了怎樣實現海量數據的快速查詢；
以上三篇論文秘籍是大數據入門的最好文章，通俗易懂，先看此三篇再看其它技術；
在Google三大秘籍流出之後，江湖上，致力於武學開放的apache根據這三本秘籍分別研究出了對應的武學巨著《hadoop》，並開放給各大門派研習，Hadoop包括三大部分，分別是hdfs、MapReduce和hbase：
hdfs解決大數據的存儲問題。
mapreduce解決大數據的計算問題。
hbase解決大數據量的查詢問題。
之後，在各大門派的支持下，Hadoop不斷衍生和進化各種分支流派，其中最激烈的當屬計算技術，其次是查詢技術。存儲技術基本無太多變化，hdfs一統天下。
以下為大概的演進：
1，傳統數據倉庫派說你mapreduce修鍊太複雜，老子不會編程，老子以前用sql吃遍天下，為了將這撥人收入門下，並降低大數據修鍊難度，遂出了hive，pig、impla等SQL ON Hadoop的簡易修鍊秘籍；
2，伯克利派說你MapReduce只重招數，內力無法施展，且不同的場景需要修鍊不同的技術，太過複雜，於是推出基於內力（內存）的《Spark》，意圖解決所有大數據計算問題。
3，流式計算相關門派說你hadoop只能憋大招（批量計算），太麻煩，於是出了SparkStreaming、Storm，S4等流式計算技術，能夠實現數據一來就即時計算。
4，apache看各大門派紛爭四起，推出flink，想一統流計算和批量計算的修鍊；
以上，如有幫助，別忘了點個贊，謝謝
Home - The Big Data Landscape
有興趣可以訪問上面的網站，了解更多的知識。
我暫且就按照一個由遠及近的順序，按照時間的早晚從大數據出現之前的時代講到現在。暫時按一個城市來比喻吧，反正Landscape的意思也大概是」風景「的意思。
早在大數據概念出現以前就存在了各種各樣的關於數學、統計學、演算法、編程語言的研究、討論和實踐。這個時代，演算法以及各種數學知識作為建築的原料(比如鋼筋、磚塊)，編程語言作為粘合劑(比如水泥)構成了一座座小房子(比如一個應用程序)，形成了一小片一小片的村莊(比如一台伺服器)。這個時代村與村之間還沒有高速公路(GFS, HDFS, Flume, Kafka等)，只有一條泥濘不好走的土路(比如RPC)，經濟模式也是小作坊式的經濟。一開始互聯網並不發達，網速也不快，這種老土的方式完全應付得來，可是隨著社交網路和智能手機的興起，改變了這一切。網站流量成百上千倍的提高，數據變得更加多樣化，計算機硬體性能無法按照摩爾定律穩定的提升，小村莊，小作坊生產的模式註定受到限制。人們需要更強大的模式...
起開始，人們以為只要有一個強大的中央資料庫，也就是在所有的村莊之間建一座吞吐量巨大，並且兼容並蓄(非關係型，NoSQL)的倉庫，用來中轉每個村莊生產的大量異質貨物就能夠拉動經濟的增長。可是沒過多久，人們就意識到這是一個too young to simple的想法，因為這個倉庫的大小也總是有上限的。
之後MapReduce的概念最早由google提出，用來解決大規模集群協同運算的問題，既然一台計算機性能有限，何不將他們聯合起來？其野心勃勃，希望為每個村莊都建立一條」村村通「公路，也就是GFS了，就是Google分散式文件系統的意思，將不同伺服器的硬碟連接起來，在外面看起來就好像一塊巨大的硬碟。然後構建與其上的MapReduce就是一座工廠調度每個村莊的勞動力和物資，讓這些村莊作為一個經濟體運轉起來。居民變得富裕起來了。
不過，富裕起來的只有」谷歌鎮「，世界的其他村鎮仍然過著原始的生活。這個時候雅虎和Apache的一幫人本著獨樂樂不如眾樂樂的精神，仿造google的思想，創建了HDFS(Hadoop 分散式文件系統，對應GFS)、Hadoop(對應google的MapReduce)，並公開了全部的藍圖，供全世界免費使用。這樣整個世界到處都建立起來了工廠，人們變得富裕起來了。這個時代，Hadoop叫做大數據基礎設施。
俗話說：飽暖思淫慾，工廠的領導不滿足於村鎮工廠的粗放型生產，也不再想僱用那麼多的勞動力，所以Mahout、HBase、Hive、Pig應運而生，他們都是數控機床，加工中心，只需要幾名操作手就能夠讓整個工廠運轉起來，自此人們安居樂業，豐衣足食。
當然，少數更有野心的資本家，不滿足於現在的生產力，為了追求更高的利潤（這是資本主義的本質），開發了效率更高的系統Spark，可以10倍於Hadoop的速度生產產品，新的時代才剛剛拉開序幕...
就是這樣，以上！這一塊關注過很久了，目前很多很成熟的組件。這是一張生態圖，我大多數都在本文中介紹過了，主要的組件都是為了方便大家從底層的MapReduce模型中脫離出來，用高層語言來做分散式計算。
HBase：是一個高可靠性、高性能、面向列、可伸縮的分散式存儲系統，利用HBase技術可在廉價PC Server上搭建起大規模結構化數據集群。像Facebook，都拿它做大型實時應用 Facebook"s New Realtime Analytics System: HBase to Process 20 Billion Events Per Day
Pig：Yahoo開發的，並行地執行數據流處理的引擎，它包含了一種腳本語言，稱為Pig Latin，用來描述這些數據流。Pig Latin本身提供了許多傳統的數據操作，同時允許用戶自己開發一些自定義函數用來讀取、處理和寫數據。在LinkedIn也是大量使用。
Hive：Facebook領導的一個數據倉庫工具，可以將結構化的數據文件映射為一張資料庫表，並提供完整的sql查詢功能，可以將sql語句轉換為MapReduce任務進行運行。其優點是學習成本低，可以通過類SQL語句快速實現簡單的MapReduce統計。像一些data scientist 就可以直接查詢，不需要學習其他編程介面。
Cascading/Scalding：Cascading是Twitter收購的一個公司技術，主要是提供數據管道的一些抽象介面，然後又推出了基於Cascading的Scala版本就叫Scalding。Coursera是用Scalding作為MapReduce的編程介面放在Amazon的EMR運行。
Zookeeper：一個分散式的，開放源碼的分散式應用程序協調服務，是Google的Chubby一個開源的實現。
Oozie：一個基於工作流引擎的開源框架。由Cloudera公司貢獻給Apache的，它能夠提供對Hadoop MapReduce和Pig Jobs的任務調度與協調。
Azkaban: 跟上面很像，Linkedin開源的面向Hadoop的開源工作流系統，提供了類似於cron 的管理任務。
Tez：Hortonworks主推的優化MapReduce執行引擎，與MapReduce相比較，Tez在性能方面更加出色。
至於Spark，我在其他的帖子中有詳細闡述：與 Hadoop 對比，如何看待 Spark 技術？ - 董飛的回答
Google內部早就開始玩大數據，發現時代跟不上他們的節奏，擔心技術後繼無人，於是發表了三篇論文（搜下gfs bigtable mapreduce）。有幾個工作不飽和，整天沒事幹的人，想搞個開源的網頁搜索（lucene nutch）。看到那三篇論文被震驚了，於是開始依葫蘆畫瓢，在一個二流的互聯網公司(Yahoo)開始實踐。這正中Google下懷。倒騰幾下，出來了一頭大象（hadoop），這只是個代號而已。大數據，不僅僅是存儲海量的數據，更強調利用好數據的價值，這就是分析和計算。好比一個龐大的原子彈研發團隊，愛因斯坦只有一個，把愛因斯坦壓榨成瘋子模樣也只是杯水車薪，但是可以往裡面投入能力差一點、各個大學、研究機構量產的、也有一定能力的學渣們（我靠），來一起搞，人海戰術被證明是可行的，因為cpu不就是很多二極體（2貨們）組成的嘛。每個學渣要能記住一些信息和處理一些信息。這就是分散式存儲和計算（hdfs mapreduce），上層由愛因斯坦之類的來統一把控。好吧，開始跑，羅斯福問愛因斯坦，學渣們靠得住嗎。愛因斯坦回答，這個系統本來就假設學渣們靠不住，他們天天dota，泡妹子，但系統有足夠好的容錯性，一個不行就換另一個，一個太慢就兩個一起跑，誰快用誰，內部還有信用機制和黑名單呢。羅斯福說，我看行。
讓我用做飯來類比。
做飯自己吃 ＝ 開發一個自己公司用的軟體
在飯店做飯 ＝ 開發一個商業軟體
經營中央廚房 ＝ 分散式處理軟體
區別在哪呢？自己做飯吃，想怎麼做怎麼做。在飯店要滿足大多數人的口味，還要控制成本。中央廚房核心難點是大規模生產的流程和質量控制。
======== 以下是吐槽 ========
其實還有一個容易混淆的東西，大數據是個商業概念，比較接近的技術名詞是分散式系統。大數據的概念比分散式系統廣，包括技術還包括技術產生的價值。
分散式系統的技術本身是盤冷盤，被大數據翻出來了而已。現在流行的這些軟體思想基礎都是二十世紀九十年代的研究成果而已。
數據價值也不是新概念了，統計學有很多經典案例來說明數據的價值，大數據理想中是突破傳統的統計規模，產生質變。
理想和現實的差距還是很大，我沒見過真正產生價值的大數據應用案例。也許是真有突破別人也不願意分享吧。這導致我成了大數據黑，參考我去年寫的文章：還要不要做大數據
Hadoop是第一家大型包工隊，能組織一堆人合作搬磚（用HDFS法）蓋房（用MapReduce法）。他們搬磚比較慢。
Spark是第二家包工隊，砌磚中途不把磚卸到地上而是放手上，可以實時交互地砌出複雜的屋子，比Hadoop家快得多。
Hadoop急了，升級，指定調度專家YARN來調度工人。他家可以聽懂甲方說幾種方言（Pig, Hive, Cascading)。
Spark從多種倉庫搬磚（HDFS，Cassandra,S3，HBase），還允許不同專家如YARN/ MESOS來調度這堆人和磚，能聽懂多種甲方方言和特殊任務指令(Shark, Spark, MLLib, GraphX, SparkR)。
後來，大企業也紛紛成立包工隊，如AWS Elastic MapReduce，Windows Azure HDInsight，OpenStack等。
//待更新
//擴展故事Hadoop做到了不丟磚，民工死了也不丟磚丟任務。
作者的問題本身有一些問題，不能把Hive與Hadoop、Spark放到同一個維度去比較。我們通常比較的是Hadoop與Spark，他們才是兩種不同的大數據生態系統，各自的組件都非常多，往往也不容易學，下面我把他們兩者整理在一幅圖中，給大家一個全貌的感覺。至於各組件的詳細介紹、相關聯繫和區別，以及它們在大數據平台建設中的具體實施關注點，待點贊數達到1000，我再對帖子進行詳細的更新，請大家隨手幫忙點個贊。
以上這些大數據組件是日常大數據工作中經常會碰到的，每個組件大概的功能，我已經在圖中做了標識。下面，針對這幅圖我給大家兩點重要提示：
a.藍色部分，是Hadoop生態系統組件，黃色部分是Spark生態組件，雖然他們是兩種不同的大數據處理框架，但它們不是互斥的，Spark與hadoop 中的MapReduce是一種相互共生的關係。Hadoop提供了Spark許多沒有的功能，比如分散式文件系統，而Spark 提供了實時內存計算，速度非常快。有一點大家要注意，Spark並不是一定要依附於Hadoop才能生存，除了Hadoop的HDFS，還可以基於其他的雲平台，當然啦，大家一致認為Spark與Hadoop配合默契最好擺了。
b.技術趨勢：Spark在崛起，hadoop和Storm中的一些組件在消退。大家在學習使用相關技術的時候，記得與時俱進掌握好新的趨勢、新的替代技術，以保持自己的職業競爭力。
HSQL未來可能會被Spark SQL替代，現在很多企業都是HIVE SQL和Spark SQL兩種工具共存，當Spark SQL逐步成熟的時候，就有可能替換HSQL；
MapReduce也有可能被Spark 替換，趨勢是這樣，但目前Spark還不夠成熟穩定，還有比較長的路要走；
Hadoop中的演算法庫Mahout正被Spark中的演算法庫MLib所替代，為了不落後，大家注意去學習Mlib演算法庫；
Storm會被Spark Streaming替換嗎?在這裡，Storm雖然不是hadoop生態中的一員，但我仍然想把它放在一起做過比較。由於Spark和hadoop天衣無縫的結合，Spark在逐步的走向成熟和穩定，其生態組件也在逐步的完善，是冉冉升起的新星，我相信Storm會逐步被擠壓而走向衰退。
歡迎大家關注我的知乎專欄「大數據實踐與職業生涯」並留言，專欄會陸續的推出過往十多年的大數據工作經驗總結和我的一些研究實踐成果。如果你是大數據新人，或者想轉行進入大數據領域，或者大數據職業生涯上存在一些疑惑，都歡迎關注我的知乎live分享「大數據人的職業生涯規劃」 、 「數據分析師-從零入門到精通」、「大數據人的數據科學家之路」。
樓主比我知道的詞多了去了。
ps, 我是程序員
請在pc/mac上點這個鏈接
Insight Data Engineering: Pipeline Components Cheatsheet
這是灣區一個專註數據工程師與數據科學家培訓的一個program總結的Pipeline。生動形象。結合以上各個答主的文字總結，應該能幫助大家對大數據的生態系統有個大概的把握。
少年：
你渴望力量嗎？-&> Spark
數據太大單機放不下怎麼辦？-&>HDFS
Spark 可以處理靜態數據，Stream能力不足怎麼辦？-&>Storm
有了Storm，是否需要一個靠譜的Message Broker? -&> Kafka
輸出數據頻率太高是不是要找個寫的快的資料庫？-&>Cassandra
Team里都是business school guys，是不是要找個他們能用的interface? -&> Hive
題目：如何用形象的比喻描述大數據的技術生態？
其實也不用形象的比喻你就能懂，
首先需要知道Hadoop生態圈主要包含哪些框架
1. Hadoop
HDFS：Hadoop分散式文件系統
MapReduce：MapReduce分散式編程模型
Yarn：資源分配
Hbase：海量資料庫，面向列
Hive：通過SQL操作結構化數據，為用戶操作結構化數據提供一個易用的介面。
Flume：日誌收集
Kafka：消息隊列
Storm：流計算
Spark框架
Spark-Core：Spark框架的核心，包括RDD，任務調度等。
Spark-SQL：作用也是通過SQL操作結構化數據，提供一個易用的介面，相當於一個前端，其後端可以包括HDFS、MongoDB等。
Spark-Streaming：流計算
Spark-Mlib：機器學習庫
Spark-GraphX：圖計算
下面的四個模塊都是在Spark-Core的基礎上實現的，可以看出來Spark其主要作用還是在於高效計算，其核心在於RDD與任務調度。
所以在學習的時候可以重點關注Hadoop的存儲，Spark的計算，發揮各自的優勢。
早些的時候，我聽過一句話計算機的東西無非就三樣，存儲、計算和通信，下面就從這三點理一下大數據生態圈的那些框架
1.存儲
文件系統：HDFS
資料庫：HBase
2. 計算
批計算：MapReduce，Spark-Core
互動式計算：Hive,Spark-SQL
實時計算：Storm,Spark-Streaming
3. 通信
分散式框架一般都會需要一個基礎，那就是RPC（遠程過程調用），RPC提供了這樣一種功能，客戶端和服務端遵循某種介面協議，當客戶端調用介面協議中的某個函數時，會轉發給服務端，然後服務端調用服務端的實現函數，通過序列化在將結果通過網路返回給客戶端。
在學習這些框架的時候，無非就是先學習
它是幹什麼的，使用場景？
它的架構，組件包括哪些？
一些重要的流程？
在深入的話就是源碼了。
HDFS主要解決海量文件存儲，它提供一個高可靠、可擴展的分散式文件存儲系統，其主要組件包含NameNode與DataNode，其中NameNode負責管理數據的元信息，DataNode負責存儲實際的數據信息，重要的流程比如上傳文件（其實很複雜），首先客戶端會向NameNode申請元信息，拿到元信息後，客戶端就會想相應的DataNode寫數據，如果副本數為3的話，客戶端會拿到三個元信息（一般不會在同一個DataNode上），然後用這三個DataNode組成Pipline，客戶端只負責第一個DataNode數據的寫入，後續的DataNode的數據由前一個DataNode負責寫入。這樣的話，一個集群中就會有三份數據，提供了高可靠，當然這個寫過程中還包括容錯（寫過程中某個環節出錯），也有運行中的容錯，比如運行中某個節點突然宕機，最嚴重的NameNode節點宕機該怎麼辦？不展開說了，太多一時半會講不完。
接下來說一說MapReduce，它的主要原理是演算法思想中的分治法，也就是把一個大的作業分發到不同的子節點去分別執行，在將結果合併，MR分為兩個版本MRv1和MRv2，MR主要由編程模型（MapReduce API）、資源管理與作業控制（v1：JobTracker,TaskTracker，v2：Yarn）、數據處理引擎（MapTask、ReduceTask）。v1和v2的主要區別在於，v1將資源管理和作業控制都交給JobTracker，而v2將資源管理和作業控制分開，分別由RM和NM（AppMaster）節點去管理。MR的執行過程其實也挺複雜，裡面包含多處優化、容錯等機制，簡單說一下就是先對數據進行分片，然後用一個RecorderReader不斷的去讀這個分片，解析出一個kv，在去調用用戶編寫map，處理完後寫入到一個緩衝區中，在溢出到磁碟，然後執行reduce任務的節點在從map節點拉取結果（通過http方式），依次通過合併，歸併排序，執行用戶編寫的reduce函數，在寫入到相應的輸出中（例如HDFS）。
下面說一下Yarn，Yarn框架主要作用是資源管理，它上面可以運行多種計算框架，MapReduce，Spark等，以MR的提交為例，客戶端先從RM上申請一個JobID，然後向一個共享文件系統提交作業（包括作業配置文件，切片），RM分配資源，在NM中分配一個Container，其中一台是AppMaster，其他NM負責執行map，reduce任務，AppMaster負責map、reduce任務的啟動與跟蹤，當map任務結束後，reduce任務會拉取map任務的結果，這個時候就需要知道map和任務節點的映射關係，因為AppMaster會向RM報告任務先關信息，所以從RM中可以獲取映射關係，當任務結束後，RM回收NM的資源並更新集群資源信息。
HBase,海量資料庫，以HDFS為基礎，可擴展，高可靠，關鍵概念有下面一些：行健、列族、cell、版本，通過這四個坐標可以確定一條數據。組件包括HMaster和RegionServer，其中HMaster負責RegionServer的運行狀態和RegionServer的負載均衡，當表格過大時，就會分割成Region，存儲到不同的RegionServer上，一個RegionServer上可以包含多個Region，Region以Hfile的形式存儲在HDFS上，所以Region是個邏輯概念，這麼多的數據，索引必然成為一個問題，Hbase採取的方式是二級索引，有點像操作系統中的頁表。
Spark，高效計算框架，因為是學院派做的，又加入了機器學習、圖計算框架，它的核心在於RDD與任務調度，從數據結構的角度看RDD，它就是一種數據結構加上操作數據結構的API，RDD的操作主要分為Transformation和Action任務執行主要分為兩個步驟，Stage劃分與提交，Task調度與執行，說到這裡，又不得不說一下Spark的APP模型，一個App中可以包含多個action操作，一個action操作會觸發一個Job，一個Job包含多個Stage，每個Stage中會包含一個或多個RDD，一個RDD包含一個或多個Partition...各個階段RDD的依賴主要是由DAGScheduler計算得到的，然後在提交運行的時候，會將Stage轉換為Taskset，由TaskScheduler把Tasks調度到相應的Worker節點，交由Executor執行。。。
引用Xiaoyu Ma的話
「有了MapReduce，Tez和Spark之後，程序員發現，MapReduce的程序寫起來真麻煩。」
如果想深入學習Spark，推薦看這篇文章 從WordCount看Spark大數據處理的核心機制（1）沒計算機背景 想研究開發不容易啊
http://apache.org 你的答案在這裡。
這群神經病多是apache家跑出來的，互相勾結纏繞依附
分散式系統，也就是把虛擬層再提升一個面。
以個體電腦或節點當為處理器。
簡單說就是解決單一電腦性能的局限。
你所提及的那些名詞，
你要明白他們只是工具。
除非你要改進他們每一樣的性能，
否則你亦無須去了解每一樣。
在這個時代，更需要掌握的是中心思想，
而不是每一樣工具的用法。
好像有些離題了ˊ_&>ˋ
就是一台大電腦，
每一個individual分擔著整個系統的每一部分。
它們是獨立的，但為一個目標所引導。
怎麼沒有storm，kettle，pantaho之類的蛇精病。。。哈哈哈哈
一個完全外行人的理解：bigdata cycle：origin-user sata，service data，system data，IOT data...==&>storage-sql,nosql,distribute file system...==&>compute-hadoop mapreduce,spark,storm...==&>analyze-machine learning...==&>feedback-new features or new products...==&>stimulate more data...每個環節都有太多的東西了。
個人寫有兩篇抄菜大數據的文章，你可以先看一看。一起加油吧！
小象飛起啦啦
推薦閱讀：