我經(jīng)常會從客戶或者網(wǎng)上聽到這個問題烦周，尤其是最近幾年口四。那么關(guān)于spark哪些被我們神化了，哪些又是真實的卿叽，以及它在“大數(shù)據(jù)”的生態(tài)系統(tǒng)中又是怎樣的？
這里寫圖片描述
HDFS—Hadoop分布式文件系統(tǒng)伊群。它是一個分布式的考杉、面向塊的、不可更新的舰始、高度伸縮性的崇棠、可運行在集群中普通硬盤上的文件系統(tǒng)。此外丸卷，HDFS還是一個獨立的工具枕稀，它可以獨立于Hadoop生態(tài)系統(tǒng)中其他組件而運行(但是如果我們想要使HDFS高可用時，還需要依賴zookeeper和日志管理器，但這又是另外一碼事了)抽莱。
MapReduce框架—這是一個基本的在集群中一組標準硬件上執(zhí)行的分布式計算框架范抓。我們沒必要一定在HDFS張使用它—因為文件系統(tǒng)是可插拔的；同樣的食铐，我們也沒必要一定在yarn中使用它，因為資源管理器是可插拔的：例如我們可以用Mesos來替換它僧鲁。
YARN—Hadoop集群中默認的資源管理器虐呻。但是我們可以在集群中不使用yarn，而是將我們的mr(譯注:map/reduce)任務運行在Mesos之上寞秃；或者僅僅在集群中運行不需要依賴yarn的hbase斟叼。
Hive—Hive是一個構(gòu)建在MapReduce框架之上的類sql查詢引擎，它可以將hiveQL語句轉(zhuǎn)換為一系列運行在集群中的mapReduce任務春寿。此外朗涩，hdfs也不是唯一的存儲系統(tǒng)，也不一定非得使用MapReduce框架绑改，比如在這里我么可以替換為Tez谢床。
Hbase—基于HDFS的鍵值對存儲系統(tǒng)，為Hadoop提供了聯(lián)機事務處理(OLTP)能力厘线。Hbase僅僅依賴HDFS和zookeeper;但是Hbase只能依賴于HDFS嗎识腿？不是的，Hbase除了可以運行在HDFS上之外造壮，還可以運行在Tachyon(內(nèi)存文件系統(tǒng))渡讼、MapRFS、IBM GPFS以及其他一些框架之上耳璧。
這里寫圖片描述
這里寫圖片描述
Spark Core – 用于通用分布式數(shù)據(jù)處理的引擎凳厢。它不不依賴于任何其他組件，可以運行在任何商用服務器集群上竞慢。
Spark Sql – 運行在Spark上的SQL查詢語句先紫，支持一系列SQL函數(shù)和HiveQL。但是還不是很成熟筹煮，所以不要在生產(chǎn)系統(tǒng)中使用遮精；而HiveQL集成了需要的hive元數(shù)據(jù)和Hive相關(guān)的jar包。
Spark Streaming – 基于spark的微批處理引擎，支持各種各樣數(shù)據(jù)源的導入本冲。唯一依賴的是Spark Core引擎准脂。
MLib – 構(gòu)建在spark之上的機器學習庫，支持一系列數(shù)據(jù)挖掘算法檬洞。
這里寫圖片描述
MapReduce可以被Spark Core替換畅铭？是的，它會隨著時間的推移被替代其兴，而且這種替代是合理的顶瞒。但是spark目前還不是特別成熟能完全替代MapReduce。此外元旬，也沒有人會完全放棄MapReduce,除非所有依賴MapReduce的工具都有可替代方案榴徐。比如說，想要在pig上運行的腳本能在spark上執(zhí)行還是有些工作要做的匀归。
Hive可以被Spark SQL替換坑资？是的，這又是對的穆端。但是我們需要理解的是Spark SQL對于spark本身來說還是比較年輕的袱贮，大概要年輕1.5倍。相對于比較成熟的Hive來說它只能算是玩具了吧体啰，我將在一年半到兩年之內(nèi)再回頭來看Spark SQL.攒巍。如果我們還記得的話，兩到三年前Impala就號稱要終結(jié)Hive,但是截止到目前兩種技術(shù)也還是共存狀態(tài)荒勇，Impala并沒有終結(jié)Hive柒莉。在這里對于Spark SQL來說也是一樣的。
Storm可以被Spark Streaming替換沽翔？ 是的兢孝，可以替換窿凤。只不過平心而論storm并不是Hadoop生態(tài)系統(tǒng)中的一員，因為它是完全獨立的工具跨蟹。他們的計算模型并不太形同雳殊，所以我不認為storm會消失，反而仍會作為一個商業(yè)產(chǎn)品窗轩。
Mahout可以被MLib替換夯秃？公平的講，Machout已經(jīng)失去了市場痢艺，而且從過去的幾年來看它正在快速失去市場寝并。對于這個工具，我們可以說這里是Spark真正可以替換Hadoop生態(tài)系統(tǒng)中的地方腹备。 因此，總的來說斤蔓，這篇文章的結(jié)論是：
不要被大數(shù)據(jù)供應商的包裝所愚弄植酥。他們大量推進的是市場而不是最終的真理。Hadoop最開始是被設(shè)計為可擴展的框架弦牡，而且其中很多部分是可替換的：可以將HDFS替換為Tachyon友驮，可以將YARN替換為Mesos，可以將MapReduce替換為Tez并且在Tez之上可以運行Hive驾锰。這將會是Hadoop技術(shù)棧的可選方案或者完全替代方案卸留？倘若我們放棄的MR（MapReduce）而使用Tez,那么它還會是Hadoop嗎？
Spark不能為我們提供完整的技術(shù)棧椭豫。它允許我們將它的功能集成到我們的Hadoop集群中并且從中獲益耻瑟，而不用完全脫離我們老的集群方案。
Spark還不夠成熟赏酥。我認為在過三到四年我們就不會再叫“Hadoop椩”而是叫它“大數(shù)據(jù)棧”或者類似的稱呼裸扶。因為在大數(shù)據(jù)棧中我們有很廣泛的選擇可以選出不同的開源產(chǎn)品來組合在一起形成一個單獨的技術(shù)棧使用框都。
轉(zhuǎn)自：http://blog.csdn.net/archleaner/article/details/50988258
