姓名：張瀚鐸? ? ? 學(xué)號：17021211233

【嵌牛導(dǎo)讀】：談到大數(shù)據(jù)，相信大家對hadoop和Apache Spark這兩個名字并不陌生糜颠。然而汹族，最近業(yè)界有一些人正在大張旗鼓的宣揚Hadoop將死，Spark將立其兴。他們究竟是危言聳聽?嘩眾取寵?還是眼光獨到堪破未來呢?與Hadoop相比顶瞒，Spark技術(shù)如何?現(xiàn)工業(yè)界大數(shù)據(jù)技術(shù)都在使用何種技術(shù)?如果現(xiàn)在想要參加大數(shù)據(jù)培訓(xùn)的話，應(yīng)該從哪一種開始呢?

【嵌牛鼻子】：大數(shù)據(jù)? ?數(shù)據(jù)可視化? ?數(shù)據(jù)分析

【嵌牛提問】：Hadoop將被Spark替代元旬？

【嵌牛正文】：

談到大數(shù)據(jù)榴徐，相信大家對hadoop和Apache Spark這兩個名字并不陌生。然而法绵，最近業(yè)界有一些人正在大張旗鼓的宣揚Hadoop將死箕速，Spark將立。他們究竟是危言聳聽?嘩眾取寵?還是眼光獨到堪破未來呢?與Hadoop相比朋譬，Spark技術(shù)如何?現(xiàn)工業(yè)界大數(shù)據(jù)技術(shù)都在使用何種技術(shù)?如果現(xiàn)在想要參加大數(shù)據(jù)培訓(xùn)的話盐茎，應(yīng)該從哪一種開始呢?

(1)先說二者之間的區(qū)別吧。

首先徙赢，Hadoop與Spark解決問題的層面不同字柠。

Hadoop和Apache Spark兩者都是大數(shù)據(jù)框架，但是各自存在的目的不盡相同狡赐。Hadoop實質(zhì)上更多是一個分布式數(shù)據(jù)基礎(chǔ)設(shè)施: 它將巨大的數(shù)據(jù)集分派到一個由普通計算機組成的集群中的多個節(jié)點進行存儲窑业，意味著您不需要購買和維護昂貴的服務(wù)器硬件。

同時枕屉，Hadoop還會索引和跟蹤這些數(shù)據(jù)常柄，讓大數(shù)據(jù)處理和分析效率達到前所未有的高度。Spark搀擂，則是那么一個專門用來對那些分布式存儲的大數(shù)據(jù)進行處理的工具西潘，它并不會進行分布式數(shù)據(jù)的存儲。

其次哨颂，還有一點也值得注意——這兩者的災(zāi)難恢復(fù)方式迥異喷市。因為Hadoop將每次處理后的數(shù)據(jù)都寫入到磁盤上，所以其天生就能很有彈性的對系統(tǒng)錯誤進行處理威恼。

Spark的數(shù)據(jù)對象存儲在分布于數(shù)據(jù)集群中的叫做彈性分布式數(shù)據(jù)集(RDD: Resilient Distributed Dataset)中品姓。這些數(shù)據(jù)對象既可以放在內(nèi)存，也可以放在磁盤箫措，所以RDD同樣也可以提供完成的災(zāi)難恢復(fù)功能腹备。

由于兩者的側(cè)重點不同，使用場景不同斤蔓，大講臺老師認為其實并沒有替代之說植酥。Spark更適合于迭代運算比較多的ML和DM運算。因為在Spark里面附迷，有RDD的概念惧互。RDD可以cache到內(nèi)存中，那么每次對RDD數(shù)據(jù)集的操作之后的結(jié)果喇伯，都可以存放到內(nèi)存中喊儡，下一個操作可以直接從內(nèi)存中輸入，省去了MapReduce大量的磁盤IO操作稻据。但是艾猜，我們也要看到spark的限制：內(nèi)存。我認為Hadoop雖然費時捻悯，但是在OLAP等大規(guī)模數(shù)據(jù)的應(yīng)用場景匆赃，還是受歡迎的。目前Hadoop涵蓋了從數(shù)據(jù)收集今缚、到分布式存儲算柳，再到分布式計算的各個領(lǐng)域，在各領(lǐng)域都有自己獨特優(yōu)勢姓言。

(2)為什么有這么多人不看好Hadoop瞬项，力捧Spark呢?

很多人在談到Spark代替Hadoop的時候，其實很大程度上指的是代替MapReduce何荚。

MapReduce的缺陷很多囱淋，最大的缺陷之一是Map + Reduce的模型。這個模型并不適合描述復(fù)雜的數(shù)據(jù)處理過程餐塘。很多公司把各種奇怪的Machine Learning計算用MR模型描述妥衣，不斷挖掘MR潛力，對系統(tǒng)工程師和Ops也是極大挑戰(zhàn)了戒傻。很多計算税手，本質(zhì)上并不是一個Map，Shuffle再Reduce的結(jié)構(gòu)稠鼻，比如我編譯一個SubQuery的SQL冈止，每個Query都做一次Group By，我可能需要Map候齿，Reduce+Reduce熙暴，中間不希望有無用的Map;又或者我需要Join，這對MapReduce來說簡直是噩夢慌盯，什么給左右表加標簽周霉，小表用Distributed Cache分發(fā)，各種不同Join的Hack亚皂，都是因為MapReduce本身是不直接支持Join的俱箱，其實我需要的是，兩組不同的計算節(jié)點掃描了數(shù)據(jù)之后按照Key分發(fā)數(shù)據(jù)到下一個階段再計算灭必，就這么簡單的規(guī)則而已;再或者我要表示一組復(fù)雜的數(shù)據(jù)Pipeline狞谱，數(shù)據(jù)在一個無數(shù)節(jié)點組成的圖上流動乃摹，而因為MapReduce的呆板模型，我必須一次一次在一個Map/Reduce步驟完成之后不必要地把數(shù)據(jù)寫到磁盤上再讀出跟衅，才能繼續(xù)下一個節(jié)點孵睬，因為Map Reduce2個階段完成之后，就算是一個獨立計算步驟完成伶跷，必定會寫到磁盤上等待下一個Map Reduce計算掰读。

上面這些問題，算是每個號稱下一代平臺都嘗試解決的“饶現(xiàn)在號稱次世代平臺現(xiàn)在做的相對有前景的是Hortonworks的Tez和Databricks的Spark蹈集。他們都嘗試解決了上面說的那些問題。Tez和Spark都可以很自由地描述一個Job里執(zhí)行流雇初。他們相對現(xiàn)在的MapReduce模型來說拢肆，極大的提升了對各種復(fù)雜處理的直接支持，不需要再絞盡腦汁“挖掘”MR模型的潛力靖诗。綜上善榛，Spark數(shù)據(jù)處理速度秒殺MapReduce因為其處理數(shù)據(jù)的方式不一樣，會比MapReduce快上很多呻畸。

(3)可以判Hadoop“死刑”嗎?

目前備受追捧的Spark還有很多缺陷移盆，比如：

穩(wěn)定性方面，由于代碼質(zhì)量問題伤为，Spark長時間運行會經(jīng)常出錯咒循，在架構(gòu)方面，由于大量數(shù)據(jù)被緩存在RAM中绞愚，Java回收垃圾緩慢的情況嚴重叙甸，導(dǎo)致Spark性能不穩(wěn)定，在復(fù)雜場景中SQL的性能甚至不如現(xiàn)有的Map/Reduce位衩。

不能處理大數(shù)據(jù)裆蒸，單獨機器處理數(shù)據(jù)過大，或者由于數(shù)據(jù)出現(xiàn)問題導(dǎo)致中間結(jié)果超過RAM的大小時糖驴，常常出現(xiàn)RAM空間不足或無法得出結(jié)果僚祷。然而，Map/Reduce運算框架可以處理大數(shù)據(jù)贮缕，在這方面辙谜，Spark不如Map/Reduce運算框架有效。

不能支持復(fù)雜的SQL統(tǒng)計;目前Spark支持的SQL語法完整程度還不能應(yīng)用在復(fù)雜數(shù)據(jù)分析中感昼。在可管理性方面装哆，SparkYARN的結(jié)合不完善，這就為使用過程中埋下隱憂，容易出現(xiàn)各種難題蜕琴。

大講臺老師并不想說Spark和Hadoop誰強誰弱萍桌，而是想告訴大家——在比較Hadoop和Spark方面要記住的最重要一點就是，它們并不是非此即彼的關(guān)系凌简，因為它們不是相互排斥梗夸，也不是說一方是另一方的簡易替代者。兩者彼此兼容号醉，這使得這對組合成為一種功能極其強大的解決方案，適合諸多大數(shù)據(jù)應(yīng)用場合辛块。

也就是說畔派，大數(shù)據(jù)行業(yè)的老鳥們?nèi)绻粫﨟adoop就要當心了，擠出時間來學(xué)習(xí)Spark和其他新技術(shù)是絕對必要的;而對于目前正準備嘗試大數(shù)據(jù)培訓(xùn)的朋友們润绵，從Hadoop開始仍然是最好的選擇线椰。長遠來看新技術(shù)總會不斷出現(xiàn)，不管是Spark還是Tez似乎都有著更美妙的大數(shù)據(jù)前景尘盼，然而沒有人會勸你完全拋開Hadoop憨愉。