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

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