生產(chǎn)環(huán)境選型考慮：Spark 全方位對比 Hadoop MapReduce

ApacheSparkApacheSpark和HadoopMapReduce之間的主要區(qū)別是：ApacheSparkApacheSpark和HadoopMapReduce之間的主要區(qū)別是：ApacheSpark與HadoopMapReduce的五個主要區(qū)別：1、ApacheSpark可能比HadoopMapReduce快100倍。2、ApacheSpark使用內(nèi)存，并且不依賴于Hadoop的兩階段范式。3、ApacheSpark適用于可以全部放入服務(wù)器內(nèi)存的較小數(shù)據(jù)集。4、Hadoop處理海量數(shù)據(jù)集更具成本效益。5、ApacheSpark現(xiàn)在比HadoopMapReduce更受歡迎。多年來，Hadoop—直是大數(shù)據(jù)無可爭議的首選直到Spark出現(xiàn)。自2014年首次發(fā)布以來，ApacheSpark一直在點燃大數(shù)據(jù)世界。憑借Spark便捷的API和承諾的速度比HadoopMapReduce快100倍，一些分析人士認(rèn)為，Spark標(biāo)志著大數(shù)據(jù)新時代的到來。Spark是一個開源數(shù)據(jù)處理框架，如何能夠如此快速地處理所有這些信息？秘訣在于Spark在集群上運(yùn)行在內(nèi)存中，它不依賴于Hadoop的MapReduce兩階段范式。這使得重復(fù)訪問相同數(shù)據(jù)的速度更快。Spark可以作為獨立應(yīng)用程序運(yùn)行，也可以在HadoopYARN之上運(yùn)行，它可以直接從HDFS讀取數(shù)據(jù)。雅虎、英特爾、百度、Yelp和Zillow等數(shù)十家主要科技公司已經(jīng)將Spark作為其技術(shù)堆棧的一部分。雖然Spark似乎注定要取代HadoopMapReduce，但您現(xiàn)在還不應(yīng)該指望MapReduce。在這篇文章中，我們將比較這兩個平臺，看看Spark是否真的非常有優(yōu)勢。什么是ApacheSpark？ApacheSpark是“用于大規(guī)模數(shù)據(jù)處理的統(tǒng)一分析引擎”。Spark由非營利性的ApacheSoftwareFoundation維護(hù)，該基金會已經(jīng)發(fā)布了數(shù)百個開源軟件項目。自項目啟動以來，已有1200多名開發(fā)人員為Spark做出了貢獻(xiàn)。Spark最初是在加州大學(xué)伯克利分校的AMPLab開發(fā)的，于2010年首次作為開源項目發(fā)布。Spark使用HadoopMapReduce分布式計算框架作為其基礎(chǔ)。Spark旨在改進(jìn)MapReduce項目的幾個方面，例如性能和易用性，同時保留MapReduce的許多優(yōu)點。Spark包括一個核心數(shù)據(jù)處理引擎，以及用于SQL、機(jī)器學(xué)習(xí)和流處理的庫。憑借適用于Java、Scala、Python和R的API，Spark在開發(fā)人員中享有廣泛的吸引力一一為其贏得了大數(shù)據(jù)處理領(lǐng)域“瑞士軍刀”的美譽(yù)。什么是HadoopMapReduce？HadoopMapReduce將自己描述為“一個用于輕松編寫應(yīng)用程序的軟件框架，該應(yīng)用程序以可靠、容錯的方式在大型商用硬件集群（數(shù)千個節(jié)點）上并行處理大量數(shù)據(jù)（多TB數(shù)據(jù)集）?！盡apReduce范式由兩個順序任務(wù)組成：Map和Reduce（因此得名）。Map過濾和排序數(shù)據(jù)，同時將其轉(zhuǎn)換為鍵值對。然后，Reduce接受此輸入并通過對數(shù)據(jù)集執(zhí)行某種匯總操作來減小其大小。MapReduce可以通過分解大型數(shù)據(jù)集并并行處理它們來極大地加速大數(shù)據(jù)任務(wù)。MapReduce范式由Google員工JeffDean和SanjayGhemawat于2004年首次提出；后來它被整合到Apache的Hadoop框架中以進(jìn)行分布式處理。Spark和MapReduce的區(qū)別＞性能＞易于使用＞數(shù)據(jù)處理＞安全然而，Spark和MapReduce之間也有一些相似之處這并不奇怪，因為Spark使用MapReduce作為其基礎(chǔ)。Spark和MapReduce的相似點包括：＞成本＞兼容性＞容錯下面，我們將在每個部分詳細(xì)介紹Spark和MapReduce之間的差異(以及相似之處)。SparkVSMapReduce：性能ApacheSpark在隨機(jī)存取存儲器(RAM)中處理數(shù)據(jù)，而HadoopMapReduce在執(zhí)行映射或歸約操作后將數(shù)據(jù)持久化回磁盤。那么理論上，Spark的性能應(yīng)該優(yōu)于HadoopMapReduce。盡管如此，Spark需要大量內(nèi)存。與標(biāo)準(zhǔn)數(shù)據(jù)庫非常相似，Spark將進(jìn)程加載到內(nèi)存中并保留在那里,直到進(jìn)一步通知以進(jìn)行緩存。如果您在HadoopYARN上運(yùn)行Spark和其他需要資源的服務(wù)，或者如果數(shù)據(jù)太大而無法完全放入內(nèi)存，那么Spark可能會遭受嚴(yán)重的性能下降。MapReduce會在作業(yè)完成后立即終止其進(jìn)程，因此它可以輕松地與性能差異很小的其他服務(wù)一起運(yùn)行。對于需要多次傳遞相同數(shù)據(jù)的迭代計算，Spark具有優(yōu)勢。但是，當(dāng)涉及到類似ETL的一次性作業(yè)時一一例如，數(shù)據(jù)轉(zhuǎn)換或數(shù)據(jù)集成這正是MapReduce的設(shè)計目的。小結(jié)：當(dāng)所有數(shù)據(jù)都適合內(nèi)存時，Spark性能更好，尤其是在專用集群上。HadoopMapReduce專為無法放入內(nèi)存的數(shù)據(jù)而設(shè)計，并且可以與其他服務(wù)一起很好地運(yùn)行。SparkVSHadoopMapReduce：易用性Spark為Java、Scala和Python提供了預(yù)構(gòu)建的API，還包括用于SQL的SparkSQL(以前稱為Shark)。由于Spark的簡單構(gòu)建塊，編寫用戶定義的函數(shù)很容易。Spark甚至包括用于運(yùn)行命令并立即反饋的交互模式。MapReduce是用Java編寫的，并且非常難以編程。ApachePig讓它變得更容易(盡管它需要一些時間來學(xué)習(xí)語法)，而ApacheHive則增加了SQL兼容性。一些Hadoop工具也可以在沒有任何編程的情況下運(yùn)行MapReduce作業(yè)。此外，雖然Hive包含命令行界面，但MapReduce沒有交互模式。ApacheImpala和ApacheTez等項目希望將完整的交互式查詢引入Hadoop。在安裝和維護(hù)方面，Spark不受Hadoop的約束。Spark和HadoopMapReduce都包含在Hortonworks(HDP3.1)和Cloudera(CDH5.13)的發(fā)行版中。小結(jié)：小結(jié)：Spark是數(shù)據(jù)處理的瑞士軍刀，而HadoopMapReduce是批處理的突擊刀。小結(jié)：小結(jié)：Spark是數(shù)據(jù)處理的瑞士軍刀，而HadoopMapReduce是批處理的突擊刀。小結(jié)：Spark更易于編程，并且包含交互模式。HadoopMapReduce更難編程，但有幾個工具可以使它更容易。SparkVSHadoopMapReduce：成本Spark和MapReduce是開源解決方案，但您仍然需要在機(jī)器和人員上花錢。Spark和MapReduce都可以使用商品服務(wù)器并在云上運(yùn)行。此外，這兩種工具都有相似的硬件要求：Spark集群中的內(nèi)存至少應(yīng)該與您需要處理的數(shù)據(jù)量一樣大，因為數(shù)據(jù)必須適合內(nèi)存才能獲得最佳性能。如果您需要處理大量數(shù)據(jù)，Hadoop肯定是更便宜的選擇，因為硬盤空間比內(nèi)存空間便宜得多。另一方面，考慮到Spark和MapReduce的性能，Spark應(yīng)該更劃算。Spark需要更少的硬件來更快地執(zhí)行相同的任務(wù)，尤其是在計算能力按使用付費的云服務(wù)器上。人員配備問題呢？盡管Hadoop自2005年就已經(jīng)存在，但市場上仍然缺乏MapReduce專家。根據(jù)Gartner的一份研究報告，57%的使用Hadoop的組織表示“獲得必要的技能和能力”是他們最大的Hadoop挑戰(zhàn)。那么這對于自2010年才出現(xiàn)的Spark來說意味著什么呢？雖然它可能有更快的學(xué)習(xí)曲線，但Spark也缺乏合格的專家。好消息是，有大量Hadoop即服務(wù)產(chǎn)品和基于Hadoop的服務(wù)（如Integrated自己的數(shù)據(jù)集成服務(wù)），這有助于緩解這些硬件和人員配備要求。同時，Spark即服務(wù)選項可通過AmazonWebServices等提供商獲得。小結(jié)：根據(jù)基準(zhǔn)，Spark更具成本效益，但人員配備成本可能更高。HadoopMapReduce可能會更便宜，因為可用的人員更多，而且對于海量數(shù)據(jù)量來說可能更便宜。SparkVSHadoopMapReduce：兼容性ApacheSpark可以作為獨立應(yīng)用程序在HadoopYARN或ApacheMesos內(nèi)部部署或云中運(yùn)行。Spark支持實現(xiàn)Hadoop輸入格式的數(shù)據(jù)源，因此它可以與Hadoop支持的所有相同數(shù)據(jù)源和文件格式集成。Spark還通過JDBC和ODBC與商業(yè)智能工具一起工作。底線：Spark對各種數(shù)據(jù)類型和數(shù)據(jù)源的兼容性與HadoopMapReduce相同。SparkvsHadoopMapReduce：數(shù)據(jù)處理Spark可以做的不僅僅是簡單的數(shù)據(jù)處理：它還可以處理圖形，它包括MLlib機(jī)器學(xué)習(xí)庫。由于其高性能，Spark可以進(jìn)行實時處理和批處理。Spark提供了一個“一刀切”的平臺供您使用，而不是在不同的平臺上拆分任務(wù)，這會增加您的IT復(fù)雜性。HadoopMapReduce非常適合批處理。如果你想要一個實時選項，你需要使用另一個平臺，比如Impala或ApacheStorm，而對于圖形處理，你可以使用ApacheGiraph。MapReduce曾經(jīng)有ApacheMahout用于機(jī)器學(xué)習(xí)，但后來被Spark和H2O拋棄了。SparkvsHadoopMapReduce：容錯ApacheSparkApacheSpark是大數(shù)據(jù)平臺上閃亮的新玩具，但仍有使用HadoopMapReduce的用例。無論您選擇ApacheSpark還是HadoopSpark具有每個任務(wù)的重試和推測執(zhí)行，就像MapReduce一樣。盡管如此，MapReduce在這里有一點優(yōu)勢，因為它依賴于硬盤驅(qū)動器，而不是RAM。如果MapReduce進(jìn)程在執(zhí)行過程中崩潰，它可以從中斷的地方繼續(xù)，而Spark必須從頭開始處理。小結(jié)：Spark和HadoopMapReduce都具有良好的容錯性，但HadoopMapReduce的容錯性稍強(qiáng)一些。SparkVSHadoopMapReduce：安全性在安全性方面，與MapReduce相比，Spark沒有那么先進(jìn)。事實上，Spark中的安全性默認(rèn)設(shè)置為“關(guān)閉”，這會使您容易受到攻擊。RPC通道支持通過共享密鑰在Spark中進(jìn)行身份驗證。Spark將事件日志記錄作為一項功能，并且可以通過javaxservlet過濾器保護(hù)WebUI。此外，由于Spark可以運(yùn)行在YARN上并使用HDFS，因此還可以享受Kerberos身份驗證、HDFS文件權(quán)限以及節(jié)點之間的加密。HadoopMapReduce可以享受所有Hadoop安全優(yōu)勢并與Hadoop安全項目集成，例如KnoxGateway和ApacheSentry。旨在提高Hadoop安全性的ProjectRhino僅在添加Sentry支持方面提到了Spark。否則，Spark開發(fā)人員將不得不自己提高Spark的安全性。小結(jié)：與具有更多安全功能和項目的MapReduce相比，Spark安全性仍然欠發(fā)達(dá)。Spark的常用場景雖然兩者都是大規(guī)模數(shù)據(jù)處理的強(qiáng)大選項，但某些情況下，其中一種比另一種更理想。流數(shù)據(jù)處理隨著公司走向數(shù)字化轉(zhuǎn)型，他們正在尋找實時分析數(shù)據(jù)的方法。Spark的內(nèi)存數(shù)據(jù)處理使其成為處理流數(shù)據(jù)的理想選擇。SparkStreaming是Spark的一個變體，它使這個用例成為可能。那么，公司可以通過哪些方式利用SparkStreaming?流式ETL-在傳統(tǒng)的ETL過程中，數(shù)據(jù)被讀取、轉(zhuǎn)換為兼容格式并保存到目標(biāo)數(shù)據(jù)存儲中。使用StreamingETL的過程效率更高，因為數(shù)據(jù)在保存到目標(biāo)數(shù)據(jù)存儲之前會在內(nèi)存中不斷清理和聚合。數(shù)據(jù)豐富一一公司在嘗試適應(yīng)和提供更增強(qiáng)的客戶體驗時處于不斷變化的狀態(tài)。通過將實時數(shù)據(jù)與靜態(tài)數(shù)據(jù)相結(jié)合，公司可以構(gòu)建更可靠的客戶畫像，從而為他們提供個性化體驗。觸發(fā)事件檢測實時響應(yīng)事件的能力是一項重要的業(yè)務(wù)能力，有助于提高敏捷性和適應(yīng)變化的能力。借助SparkStreaming，公司可以實時分析數(shù)據(jù)，以識別需要立即關(guān)注的異常活動。機(jī)器學(xué)習(xí)在預(yù)測分析方面，Spark的機(jī)器學(xué)習(xí)庫(MLib)提供了一套強(qiáng)大的工具，可以輕松完成它。當(dāng)用戶對一組數(shù)據(jù)進(jìn)行重復(fù)查詢時，他們本質(zhì)上是在構(gòu)建類似于機(jī)器學(xué)習(xí)的算法。例如，機(jī)器學(xué)習(xí)可以幫助公司出于營銷目的進(jìn)行客戶細(xì)分。它還可以幫助執(zhí)行情緒分析。交互式查詢想象一下能夠?qū)崟r數(shù)據(jù)執(zhí)行交互式查詢。從本質(zhì)上講，您可以分析大型數(shù)據(jù)集，而無需依賴外部數(shù)據(jù)存儲來處理信息。使用SparkStreaming，您可以查詢數(shù)據(jù)流，而無需將其持久化到外部數(shù)據(jù)庫。MapReduce的常用場景當(dāng)處理對于內(nèi)存中操作來說太大的數(shù)據(jù)時，MapReduce是要走的路。因此，MapReduce最適合處理大型數(shù)據(jù)集。處理大型數(shù)據(jù)集（PB或TB）考慮到實施和維護(hù)所需的時間和費用，千兆字節(jié)大小不足以證明MapReduce的合理性。希望管理PB或TB數(shù)據(jù)的組織是MapReduce的理想選擇。以不同格式存儲數(shù)據(jù)公司可以使用MapReduce處理多種文件類型，例如文本、圖像、純文本等。由于這些文件對于內(nèi)存中的處理來說太大了，使用MapReduce進(jìn)行批處理更經(jīng)濟(jì)。數(shù)據(jù)處理MapReduce具有對大型數(shù)據(jù)集執(zhí)行基本和復(fù)雜分析的強(qiáng)大功能。通過使用基于磁盤的存儲而不是內(nèi)存中的處理，對大型數(shù)據(jù)集進(jìn)行匯總、過濾和連接等任務(wù)的效率要高得多。Spark與HadoopMapReduce趨勢隨著公司尋找在擁擠的市場中保持競爭力的新方法，他們將需要適應(yīng)即將到來的數(shù)據(jù)管理趨勢。這些趨勢包括：XOps-使用DevOps的最佳實踐，XOps的目標(biāo)是在數(shù)據(jù)管理過程中實現(xiàn)可靠性、可重用性和可重復(fù)性。DataFabric-作為一個架構(gòu)框架，DataFabric的目標(biāo)是在一個無縫的數(shù)據(jù)管理平臺中結(jié)合多種類型的數(shù)據(jù)存儲、分析、處理和安全性數(shù)據(jù)分析作為核心業(yè)務(wù)功能-傳統(tǒng)上，數(shù)據(jù)