中統原創：深度解析之Spark 優於 Hadoop 嗎？
原作者：Sundara Raghavan Sankaran
譯者：Blanca
對於任何一個進入大資料世界的人來講，
維琪百科對大資料這樣解釋：大資料是一個寬泛的術語，它指傳統資料處理應用程式無法處理的巨大而複雜的資料集。
簡單來講，隨著資料量的增加，採用常規處理方法需要花費大量時間且價格不菲。
Doug Cutting受穀歌GFS及MapReduce白皮書的啟發，在 2005年創辦了Hadoop 。Hadoop 採用開源軟體框架對超大資料集進行分散式存儲技術及分散式處理。換句話說，設計這一產品的目的在於縮減處理大資料集的時間和成本。
Hadoop，其分散式檔案系統(HDFS)和分散式處理模組(MapReduce)成為大資料計算的實際標準。Hadoop 這一術語不僅可以與基礎模組相關，
隨著時間的推移，生成的資料量猛增，處理大量資料的需求也隨之猛增。這最終使大資料計算需要滿足各種不同需求，而這些需求並非都可以全部由Hadoop 完成。
大多數資料分析本質上是反覆運算處理。儘管反覆運算處理可以由MapReduce完成，但資料讀取應該在每次反覆運算中進行。通常情況下，這並沒有問題。
許多人認為資料分析是一門藝術而非一門科學。在任何藝術領域，藝術家創造一小塊部分拼圖，又將小拼圖將放到更大的拼圖上，見證它的生長。可以粗略的翻譯為：資料分析師想在下一個處理開始之前得到前一個處理的結果。換句話說，許多資料分析學在本質上都是互動式的。在傳統意義上，互動式分析習慣上受結構化查詢語言(SQL)的影響。
這些障礙促使了Spark的誕生，這種新型處理模組能促進反覆運算程式設計和互動式分析。Spark裝備了一個將資料載入記憶體並反復查詢的記憶體原始模型。這使Spark非常適合大量資料分析及機器學習演算法。
注意，Spark僅僅規定了分散式處理模組。存儲資料部分仍然依賴Hadoop（分散式檔案系統HDFS）採用分佈存儲方式高效存儲資料，而不由Spark完成。
Spark 將大資料生態系統設置在超光速磁片上，確保比MapReduce快10-100倍。許多人認為這可能是MapReduce的終結。
相比MapReduce來講，Spark操作簡單，甚至可以說非常便捷。即使對於一個簡單邏輯或演算法，MapReduce也需要100行代碼；但使用Spark，一個簡單邏輯，幾行代碼就可以完成。這就引出了一個關鍵因素，叫做用途廣泛。許多對於MapReduce來講不可能完成的機器學習或圖表問題的高級演算法，都可以由Spark完成。這讓Spark的採用率相當高。
MapReduce沒有交互模組。儘管Hive和Pig包含命令列介面，這些系統的性能仍然依賴MapReduce。MapReduce對於批次處理仍然十分受用。
Spark 在記憶體中處理資料，而MapReduce卻將處理後的資料傳送回磁片。所以Spark將優於MapReduce。
在2014年，Spark晉級Daytona GraySort測試並拔得頭籌。對於門外漢來說，DaytonaGraySort是測試系統檢索100TB（一萬億條記錄）資料速度的協力廠商評判基準。
Spark使用206個AWS EC2 設備，在23分鐘內將100TB的資料存儲到磁片上。此前的最高記錄保持者是MapReduce，它使用了2100台設備，總共花費了72分鐘。Spark在相同的條件下卻比MapReduce快了3倍，使用的設備總數也少了10倍。
Spark佔用大量記憶體。如果我們運行Spark的同時運行其他佔用記憶體的服務，其性能可能大打折扣。但是，我們可以有把握地說，Spark在反覆運算處理方面占上風（需要多次傳遞同一資料）。
成本這兩者在計算能力、磁片和網路環境方面的硬體要求都十分相似。記憶體越大，Spark表現越好。這兩者都使用商品伺服器。
MapReduce程式設計費力，市場上這方面的專家並不多。即便有為數不多的Spark專家，但這也僅僅是因為Spark是初創產品。所以學習Spark程式設計比MapReduce要容易的多。
脫離了Hadoop 的Spark
運行Spark其實並不需要Hadoop的支援。如果我們沒有從分散式檔案系統（HDFS）中讀取資料，Spark也可以自行運行。Spark也可以從諸如S3, Cassandra等其他存儲中讀寫資料。在這種架構下，Spark可在獨立模式下運行，並不需要Hadoop 元件的支援。
近期研究表明在產品中使用Spark的使用者激增。許多用戶同時運行Spark和Cassandra, 或者Spark和Hadoop ，又或者在Apche Mesos上運行Spark. 儘管Spark用戶數量有所增長，但並沒有在大資料社區造成恐慌。MapReduce使用率可能會下降，但具體降幅未知。
許多人預測Spark會促使另一種更優質堆疊的發展。但這種新型堆疊可能會與Hadoop 及其套裝軟體生態系統非常相似。
Spark的最大優點是簡潔。但它並不會徹底消滅MapReduce，因為使用MapReduce依然大有人在。即便Spark成為大贏家，除非研發新分散式檔案系統，我們將同時使用Hadoop 和Spark處理資料。
原文連結：//bigdata-madesimple.com/is-spark-better-than-hadoop-map-reduce/
資料特工介紹
公眾號“中國統計網”後臺回復“特工”加入我們
End.
運行人員：中國統計網小編（微信號：itongjilove）
中國統計網，是國內最早的大資料學習網站，公眾號：中國統計網
//www.itongji.cn
即使對於一個簡單邏輯或演算法，MapReduce也需要100行代碼；但使用Spark，一個簡單邏輯，幾行代碼就可以完成。這就引出了一個關鍵因素，叫做用途廣泛。許多對於MapReduce來講不可能完成的機器學習或圖表問題的高級演算法，都可以由Spark完成。這讓Spark的採用率相當高。MapReduce沒有交互模組。儘管Hive和Pig包含命令列介面，這些系統的性能仍然依賴MapReduce。MapReduce對於批次處理仍然十分受用。
Spark 在記憶體中處理資料，而MapReduce卻將處理後的資料傳送回磁片。所以Spark將優於MapReduce。
在2014年，Spark晉級Daytona GraySort測試並拔得頭籌。對於門外漢來說，DaytonaGraySort是測試系統檢索100TB（一萬億條記錄）資料速度的協力廠商評判基準。
Spark使用206個AWS EC2 設備，在23分鐘內將100TB的資料存儲到磁片上。此前的最高記錄保持者是MapReduce，它使用了2100台設備，總共花費了72分鐘。Spark在相同的條件下卻比MapReduce快了3倍，使用的設備總數也少了10倍。
Spark佔用大量記憶體。如果我們運行Spark的同時運行其他佔用記憶體的服務，其性能可能大打折扣。但是，我們可以有把握地說，Spark在反覆運算處理方面占上風（需要多次傳遞同一資料）。
成本這兩者在計算能力、磁片和網路環境方面的硬體要求都十分相似。記憶體越大，Spark表現越好。這兩者都使用商品伺服器。
MapReduce程式設計費力，市場上這方面的專家並不多。即便有為數不多的Spark專家，但這也僅僅是因為Spark是初創產品。所以學習Spark程式設計比MapReduce要容易的多。
脫離了Hadoop 的Spark
運行Spark其實並不需要Hadoop的支援。如果我們沒有從分散式檔案系統（HDFS）中讀取資料，Spark也可以自行運行。Spark也可以從諸如S3, Cassandra等其他存儲中讀寫資料。在這種架構下，Spark可在獨立模式下運行，並不需要Hadoop 元件的支援。
近期研究表明在產品中使用Spark的使用者激增。許多用戶同時運行Spark和Cassandra, 或者Spark和Hadoop ，又或者在Apche Mesos上運行Spark. 儘管Spark用戶數量有所增長，但並沒有在大資料社區造成恐慌。MapReduce使用率可能會下降，但具體降幅未知。
許多人預測Spark會促使另一種更優質堆疊的發展。但這種新型堆疊可能會與Hadoop 及其套裝軟體生態系統非常相似。
Spark的最大優點是簡潔。但它並不會徹底消滅MapReduce，因為使用MapReduce依然大有人在。即便Spark成為大贏家，除非研發新分散式檔案系統，我們將同時使用Hadoop 和Spark處理資料。
原文連結：//bigdata-madesimple.com/is-spark-better-than-hadoop-map-reduce/
資料特工介紹
公眾號“中國統計網”後臺回復“特工”加入我們
End.
運行人員：中國統計網小編（微信號：itongjilove）
中國統計網，是國內最早的大資料學習網站，公眾號：中國統計網
//www.itongji.cn