hadoop與spark的異同

解決問題的層面不一樣
首先，Hadoop和Apache Spark兩者都是大數據框架，但是各自存在的目的不盡相同。Hadoop實質上更多是一個分佈式數據基礎設施: 它將巨大的數據集分派到一個由普通計算機組成的集羣中的多個節點進行存儲，意味着您不需要購買和維護昂貴的服務器硬件。
同時，Hadoop還會索引和跟蹤這些數據，讓大數據處理和分析效率達到前所未有的高度。Spark，則是那麼一個專門用來對那些分佈式存儲的大數據進行處理的工具，它並不會進行分佈式數據的存儲。
兩者可合可分
Hadoop除了提供爲大家所共識的HDFS分佈式數據存儲功能之外，還提供了叫做MapReduce的數據處理功能。所以這裏我們完全可以拋開Spark，使用Hadoop自身的MapReduce來完成數據的處理。
相反，Spark也不是非要依附在Hadoop身上才能生存。但如上所述，畢竟它沒有提供文件管理系統，所以，它必須和其他的分佈式文件系統進行集成才能運作。這裏我們可以選擇Hadoop的HDFS,也可以選擇其他的基於雲的數據系統平臺。但Spark默認來說還是被用在Hadoop上面的，畢竟，大家都認爲它們的結合是最好的。
以下是從網上摘錄的對MapReduce的最簡潔明瞭的解析:
  我們要數圖書館中的所有書。你數1號書架，我數2號書架。這就是“Map”。我們人越多，數書就更快。
現在我們到一起，把所有人的統計數加在一起。這就是“Reduce”。
Spark數據處理速度秒殺MapReduce
Spark因爲其處理數據的方式不一樣，會比MapReduce快上很多。MapReduce是分步對數據進行處理的: ”從集羣中讀取數據，進行一次處理，將結果寫到集羣，從集羣中讀取更新後的數據，進行下一次的處理，將結果寫到集羣，等等…“ Booz Allen Hamilton的數據科學家Kirk Borne如此解析。
反觀Spark，它會在內存中以接近“實時”的時間完成所有的數據分析：“從集羣中讀取數據，完成所有必須的分析處理，將結果寫回集羣，完成，” Born說道。Spark的批處理速度比MapReduce快近10倍，內存中的數據分析速度則快近100倍。
如果需要處理的數據和結果需求大部分情況下是靜態的，且你也有耐心等待批處理的完成的話，MapReduce的處理方式也是完全可以接受的。
但如果你需要對流數據進行分析，比如那些來自於工廠的傳感器收集回來的數據，又或者說你的應用是需要多重數據處理的，那麼你也許更應該使用Spark進行處理。
大部分機器學習算法都是需要多重數據處理的。此外，通常會用到Spark的應用場景有以下方面：實時的市場活動，在線產品推薦，網絡安全分析，機器日記監控等。
災難恢復
兩者的災難恢復方式迥異，但是都很不錯。因爲Hadoop將每次處理後的數據都寫入到磁盤上，所以其天生就能很有彈性的對系統錯誤進行處理。
Spark的數據對象存儲在分佈於數據集羣中的叫做彈性分佈式數據集(RDD: Resilient Distributed Dataset)中。“這些數據對象既可以放在內存，也可以放在磁盤，所以RDD同樣也可以提供完成的災難恢復功能，”Borne指出。


對Hadoop與Spark孰優孰劣這個問題，最準確的觀點就是，設計人員旨在讓Hadoop和Spark在同一個團隊裏面協同運行。
直接比較Hadoop和Spark有難度，因爲它們處理的許多任務都一樣，但是在一些方面又並不相互重疊。
比如說，Spark沒有文件管理功能，因而必須依賴Hadoop分佈式文件系統(HDFS)或另外某種解決方案。將Hadoop MapReduce與Spark作一番比較來得更明智，因爲它們作爲數據處理引擎更具有可比性。
過去幾年，隨着數據科學趨於成熟，也日益需要用一種不同的方法來處理大數據。Hadoop在一些業務應用領域的表現比後起之秀Spark更勝一籌， 不過Spark在大數據領域有其一席之地，這歸功於它具有速度快、易於使用的優點。本文剖析了兩大平臺的一系列常見屬性，包括性能、容錯、成本、易用性、 數據處理、兼容性和安全性。
Hadoop和Spark方面要記住的最重要一點就是，它們並不是非此即彼的關係，因爲它們不是相互排斥，也不是說一方是另一方的簡易替代者。兩者彼此兼容，這使得這對組合成爲一種功能極其強大的解決方案，適合諸多大數據應用場合。
Hadoop的定義
Hadoop是Apache.org的一個項目，其實是一種軟件庫和框架，以便使用簡單的編程模型，跨計算器集羣對龐大數據集(大數據)進行分佈式 處理。Hadoop可靈活擴展，從單一計算機系統，到提供本地存儲和計算能力的數千個商用系統，它都能輕鬆支持。實際上，Hadoop就是大數據分析領域 的重量級大數據平臺。
Hadoop由協同運行、構建Hadoop框架的多個模塊組成。Hadoop框架的主要模塊包括如下：
Hadoop Common Hadoop分佈式文件系統(HDFS) Hadoop YARN Hadoop MapReduce
雖然上述四個模塊構成了Hadoop的核心，不過還有其他幾個模塊。這些模塊包括：Ambari、Avro、Cassandra、Hive、 Pig、Oozie、Flume和Sqoop，它們進一步增強和擴展了Hadoop的功能，得以擴大到大數據應用領域，處理龐大數據集。
許多使用大數據集和分析工具的公司使用Hadoop。它已成爲大數據應用系統中事實上的標準。設計Hadoop的初衷是處理這項任務：搜尋和搜索數 十億個網頁，將這些信息收集到數據庫中。正是由於渴望搜尋和搜索互聯網，纔有了Hadoop的HDFS及分佈式處理引擎MapReduce。
如果數據集變得極其龐大或極其複雜，以至於當前的解決方案無法在數據用戶認爲合理的時間段內有效地處理信息，Hadoop對公司就會大有用處。
MapReduce是一種出色的文本處理引擎，它理應如此，因爲搜尋互聯網和搜索互聯網(它的首要任務)都是基於文本的任務。
Spark的定義
Apache Spark開發人員聲稱它是“一種用於數據大規模處理的快速通用引擎”。相比之下，如果說Hadoop的大數據框架好比是800磅重的大猩猩，Spark就好比是130磅重的獵豹。
雖然批評Spark的內存處理技術的人士承認，Spark確實速度很快(最多比Hadoop MapReduce快100倍)，但他們可能並不願意承認它在磁盤上運行起來速度最多快10倍。Spark還可以執行批量處理，然而它真正擅長的是處理流工作負載、交互式查詢和基於機器的學習。
相比MapReduce基於磁盤的批量處理引擎，Spark賴以成名之處是其數據實時處理功能。Spark與Hadoop及其模塊兼容。實際上，在Hadoop的項目頁面上，Spark就被列爲是一個模塊。
Spark有自己的頁面，因爲雖然它可以通過YARN(另一種資源協調者)在Hadoop集羣中運行，但是它也有一種獨立模式。它可以作爲 Hadoop模塊來運行，也可以作爲獨立解決方案來運行;這樣一來，很難直接比較兩者。然而隨着時間的推移，一些大數據科學家預計Spark會出現分叉，可能會取代Hadoop，尤其是在更快速地訪問處理的數據至關重要的情況下。
Spark是一種集羣計算框架，這意味着它更多地與MapReduce競爭，而不是與整個Hadoop生態系統競爭。比如說，Spark沒有自己的分佈式文件系統，但可以使用HDFS。
Spark使用內存，也可以使用磁盤進行處理，而MapReduce完全基於磁盤。MapReduce和Spark的主要區別在於，MapReduce使用持久存儲，而Spark使用彈性分佈式數據集(RDDS)，下面容錯部分有更詳細的解釋。
性能
網上不缺關於Spark與MapReduce相比有多快的信息。對兩者進行比較有個問題，那就是它們處理數據的方式不一樣，數據處理部分有介紹。Spark之所以如此快速，原因在於它在內存中處理一切數據。沒錯，它還可以使用磁盤來處理未全部裝入到內存中的數據。
Spark的內存處理爲來自多個來源的數據提供了近乎實時分析的功能：營銷活動、機器學習、物聯網傳感器、日誌監控、安全分析和社交媒體網站。另 外，MapReduce使用批量處理，其實從來就不是爲驚人的速度設計的。它的初衷是不斷收集來自網站的信息，不需要這些數據具有實時性或近乎實時性。
易用性
衆所周知，Spark以性能見長，但是它也因易用性而小有名氣，原因是它隨帶易於使用的API，支持Scala(原生語言)、Java、Python和Spark SQL。Spark SQL非常類似於SQL 92，所以幾乎不需要經歷一番學習，馬上可以上手。
Spark還有一種交互模式，那樣開發人員和用戶都可以獲得查詢和其他操作的即時反饋。MapReduce沒有交互模式，不過有了Hive和Pig等附加模塊，採用者使用MapReduce來得容易一點。
成本
MapReduce和Spark都是Apache項目，這意味着它們是開源免費軟件產品。雖然軟件不需要成本，但是派人用硬件運行任何一種平臺帶來了成本。這兩種產品都設計成可以在商用硬件上運行，比如所謂的低成本白盒服務器系統。
MapReduce和Spark在同樣的硬件上運行，那麼這兩種解決方案的成本差異體現在哪裏?MapReduce使用常規數量的內存，因爲數據處 理基於磁盤，所以公司得購買速度更快的磁盤和大量磁盤空間來運行MapReduce。MapReduce還需要更多的系統，將磁盤輸入/輸出分佈到多個系 統上。
Spark需要大量內存，但是可以使用常規數量的常規轉速磁盤。一些用戶抱怨會產生臨時文件，需要清理。這些臨時文件通常保存7天，以便加快針對同 一數據集的任何處理。磁盤空間相對便宜，由於Spark不使用磁盤輸入/輸入用於處理，已使用的磁盤空間可以用於SAN或NAS。
然而，由於需要大量內存在內存中處理一切數據，Spark系統的成本更高，這點沒錯。但是Spark的技術同時減少了所需的系統數量。所以，最後的 情形是，系統成本較高，但是數量大大減少。也許到時候，Spark實際上可以降低每個計算單位的成本，儘管內存方面有額外的要求。
舉例說明，“Spark已證明在數據多達PB的情況下也輕鬆自如。它被用於在數量只有十分之一的機器上，對100TB數據進行排序的速度比Hadoop MapReduce快3倍。”這一成績讓Spark成爲2014年Daytona GraySort基準。
兼容性
MapReduce和Spark相互兼容;MapReduce通過JDBC和ODC兼容諸多數據源、文件格式和商業智能工具，Spark具有與MapReduce同樣的兼容性。
數據處理
MapReduce是一種批量處理引擎。MapReduce以順序步驟來操作，先從集羣讀取數據，然後對數據執行操作，將結果寫回到集羣，從集羣讀 取更新後的數據，執行下一個數據操作，將那些結果寫回到結果，依次類推。Spark執行類似的操作，不過是在內存中一步執行。它從集羣讀取數據後，對數據 執行操作，然後寫回到集羣。
Spark還包括自己的圖形計算庫GraphX​​。GraphX讓用戶可以查看與圖形和集合同樣的數據。用戶還可以使用彈性分佈式數據集(RDD)，改變和聯合圖形，容錯部分作了討論。
容錯
至於容錯，MapReduce和Spark從兩個不同的方向來解決問題。MapReduce使用TaskTracker節點，它爲 JobTracker節點提供了心跳(heartbeat)。如果沒有心跳，那麼JobTracker節點重新調度所有將執行的操作和正在進行的操作，交 給另一個TaskTracker節點。這種方法在提供容錯性方面很有效，可是會大大延長某些操作(即便只有一個故障)的完成時間。
Spark使用彈性分佈式數據集(RDD)，它們是容錯集合，裏面的數據元素可執行並行操作。RDD可以引用外部存儲系統中的數據集，比如共享式文件系統、HDFS、HBase，或者提供Hadoop InputFormat的任何數據源。Spark可以用Hadoop支持的任何存儲源創建RDD，包括本地文件系統，或前面所列的其中一種文件系統。
RDD擁有五個主要屬性：
分區列表 計算每個分片的函數 依賴其他RDD的項目列表 面向鍵值RDD的分區程序(比如說RDD是散列分區)，這是可選屬性 計算每個分片的首選位置的列表(比如HDFS文件的數據塊位置)，這是可選屬性
RDD可能具有持久性，以便將數據集緩存在內存中。這樣一來，以後的操作大大加快，最多達10倍。Spark的緩存具有容錯性，原因在於如果RDD的任何分區丟失，就會使用原始轉換，自動重新計算。
可擴展性
按照定義，MapReduce和Spark都可以使用HDFS來擴展。那麼，Hadoop集羣能變得多大呢?
據稱雅虎有一套42000個節點組成的Hadoop集羣，可以說擴展無極限。最大的已知Spark集羣是8000個節點，不過隨着大數據增多，預計集羣規模也會隨之變大，以便繼續滿足吞吐量方面的預期。
安全
Hadoop支持Kerberos身份驗證，這管理起來有麻煩。然而，第三方廠商讓企業組織能夠充分利用活動目錄Kerberos和LDAP用於身份驗證。同樣那些第三方廠商還爲傳輸中數據和靜態數據提供數據加密。
Hadoop分佈式文件系統支持訪問控制列表(ACL)和傳統的文件權限模式。Hadoop爲任務提交中的用戶控制提供了服務級授權(Service Level Authorization)，這確保客戶擁有正確的權限。
Spark的安全性弱一點，目前只支持通過共享密鑰(密碼驗證)的身份驗證。Spark在安全方面帶來的好處是，如果你在HDFS上運行Spark，它可以使用HDFS ACL和文件級權限。此外，Spark可以在YARN上運行，因而能夠使用Kerberos身份驗證。
總結Hadoop vs Spark
乍一看，對任何大數據應用而言，使用Spark似乎是默認選擇。然而，事實並非如此。MapReduce已在大數據市場取得了進展，尤其受到這種公司企業的追捧：需要由商用系統對龐大數據集加以控制。Spark的速度、靈活性和相對易用性對MapReduce的低操作成本來說是絕對補充。
實際上，Spark與MapReduce是一種相互共生的關係。Hadoop提供了Spark所沒有的功能特性，比如分佈式文件系統，而Spark 爲需要它的那些數據集提供了實時內存處理。完美的大數據場景正是設計人員當初預想的那樣：讓Hadoop和Spark在同一個團隊裏面協同運行。


來源：http://www.techweb.com.cn/network/system/2016-03-09/2292838.shtml；http://www.techweb.com.cn/network/system/2016-01-25/2267414.shtml