如何用形象的比喻描述大數據Hadoop、Hive、Spark 之間是什麼關係

問題：如何用形象的比喻描述大數據的技術生態？Hadoop、Hive、Spark 之間是什麼關係？

對於我們這些文科，商科生來說。我們剛剛搞懂服務器，數據庫，C++，java等基礎語言是個什麼東西的時候，大數據時代來了，科技蜀黍又玩起Hadoop，HDFS，MapReduce，Common，Spark，Mahout，HBase，NoSQL，Cassandra，GFS, MapReduce, BigTable，Hive，Pig……這些蛇精病和大怪獸了。我不認識它們，還有什麼妖怪沒記進來的，請各位繼續在評論裡補充。

可各位大神能不能把這些混亂的技術妖詞（對不起，正是因為不懂，所以很亂），做一個生態的比喻？比成，一棵樹？一個城市？一個人的循環系統？隨便你比……總之讓我們這些技術白痴也能搞明白，它們之間是什麼關係，誰是幹什麼的？

叩謝。

回答者：Xiaoyu Ma，號稱是大數據工程師

大數據本身是個很寬泛的概念，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。你可以把他看作中央管理，好比你媽在廚房監工，哎，你妹妹切菜切完了，你可以把刀拿去殺雞了。只要大家都服從你媽分配，那大家都能愉快滴燒菜。

你可以認為，大數據生態圈就是一個廚房工具生態圈。為了做不同的菜，中國菜，日本菜，法國菜，你需要各種不同的工具。而且客人的需求正在複雜化，你的廚具不斷被髮明，也沒有一個萬用的廚具可以處理所有情況，因此它會變的越來越複雜。

回答者：紀路，Pythoner/數據挖掘 http://mrobot.me

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的速度生產產品，新的時代才剛剛拉開序幕...

就是這樣，以上！

回答者：董飛，微信訂閱號：donglaoshi-123 | Coursera…

這一塊關注過很久了，目前很多很成熟的組件。這是一張生態圖，我大多數都在本文中介紹過了，主要的組件都是為了方便大家從底層的MapReduce模型中脫離出來，用高層語言來做分佈式計算。

HBase：是一個高可靠性、高性能、面向列、可伸縮的分佈式存儲系統，利用HBase技術可在廉價PC Server上搭建起大規模結構化數據集群。像Facebook，都拿它做大型實時應用 Facebook's New Realtime AnalyticsSystem: 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 技術？ - 董飛的回答

回答者：白伯純，http://sinofool.net EA | Renren | Baidu

讓我用做飯來類比。

做飯自己吃 ＝ 開發一個自己公司用的軟件

在飯店做飯 ＝ 開發一個商業軟件

經營中央廚房 ＝ 分佈式處理軟件

區別在哪呢？自己做飯吃，想怎麼做怎麼做。在飯店要滿足大多數人的口味，還要控制成本。中央廚房核心難點是大規模生產的流程和質量控制。

====== 以下是吐槽 ======

其實還有一個容易混淆的東西，大數據是個商業概念，比較接近的技術名詞是分佈式系統。大數據的概念比分佈式系統廣，包括技術還包括技術產生的價值。

分佈式系統的技術本身是盤冷菜，被大數據翻出來了而已。現在流行的這些軟件思想基礎都是二十世紀九十年代的研究成果而已。

數據價值也不是新概念了，統計學有很多經典案例來說明數據的價值，大數據理想中是突破傳統的統計規模，產生質變。

理想和現實的差距還是很大，我沒見過真正產生價值的大數據應用案例。也許是真有突破別人也不願意分享吧。這導致我成了大數據黑，參考我去年寫的文章：還要不要做大數據

回答者：帝嚳蠻犬，看到認真的答案不點贊就是耍流氓。

Google內部早就開始玩大數據，發現時代跟不上他們的節奏，擔心技術後繼無人，於是發表了三篇論文（搜下gfs bigtable mapreduce）。有幾個工作不飽和，整天沒事幹的人，想搞個開源的網頁搜索（lucene nutch）。看到那三篇論文被震驚了，於是開始依葫蘆畫瓢，在一個二流的互聯網公司(Yahoo)開始實踐。這正中Google下懷。倒騰幾下，出來了一頭大象（hadoop），這只是個代號而已。大數據，不僅僅是存儲海量的數據，更強調利用好數據的價值，這就是分析和計算。好比一個龐大的原子彈研發團隊，愛因斯坦只有一個，把愛因斯坦壓榨成瘋子模樣也只是杯水車薪，但是可以往裡面投入能力差一點、各個大學、研究機構量產的、也有一定能力的學渣們（我靠），來一起搞，人海戰術被證明是可行的，因為cpu不就是很多二極管（2貨們）組成的嘛。每個學渣要能記住一些信息和處理一些信息。這就是分佈式存儲和計算（hdfs mapreduce），上層由愛因斯坦之類的來統一把控。好吧，開始跑，羅斯福問愛因斯坦，學渣們靠得住嗎。愛因斯坦回答，這個系統本來就假設學渣們靠不住，他們天天dota，泡妹子，但系統有足夠好的容錯性，一個不行就換另一個，一個太慢就兩個一起跑，誰快用誰，內部還有信用機制和黑名單呢。羅斯福說，我看行。