本節書摘來自華章計算機《spark與hadoop大資料分析》一書中的第2章，第2.2節,作者：文卡特·安卡姆（venkat ankam） 更多章節内容可以通路雲栖社群“華章計算機”公衆号檢視。
hadoop和mr已有10年曆史，已經被證明是高性能處理海量資料的最佳解決方案。然而，mr在疊代計算中性能不足，在這種情況下，多個mr作業之間的輸出必須被寫入 hdfs。在單個mr作業中，它的性能不足則是因為mr架構存在的一些缺點所緻。
讓我們來看看計算趨勢的發展曆史，以便了解計算的格局在過去20年中的變化。
這個趨勢是當網絡成本更低時（1990年代）對uri索引（reference），當存儲成本更低時（2000 年代）進行複制（replicate），以及當記憶體成本更低時（2010 年代）進行再計算（recompute），如圖2-5 所示：
圖2-5 計算的趨勢
那麼，在一段時間裡有哪些東西真正改變了？
錄音帶已經消亡，磁盤已成為錄音帶，ssd 幾乎成為磁盤。現在，目前的趨勢是把資料緩存在記憶體中。
讓我們來了解一下，為什麼基于記憶體的計算很重要，以及它如何能産生顯著的性能優勢。
圖2-6顯示了從各種媒體到cpu的資料傳輸速率。磁盤到cpu的傳輸速率為100 mb/s，ssd到cpu為600 mb/s，通過網絡到cpu為1 mb到1 gb/s。然而，ram到cpu的傳輸速度驚人地快，達到了10 gb/s。是以，理想的思路是把所有或部分資料緩存到記憶體裡，以便實作更高的性能：
2.2.1 spark 的發展曆史
spark 始于 2009 年，起初是作為加州大學伯克利分校 rad 實驗室的一個研究項目，該實驗室就是 amplab 的前身。該實驗室的研究人員以前一直在使用 hadoop mapreduce，并觀察到 mr 對于疊代和互動式計算工作是低效率的。是以，從一開始，spark 被設計為快速進行互動式查詢和疊代的算法，采用了支援記憶體存儲和高效故障恢複等一些思路。
圖2-6 為什麼采用基于記憶體的計算
在2011年，amplab開始在spark上開發更進階的元件，如shark和spark streaming。這些元件有時被稱為berkeley資料分析架構（berkeley data analytics stack，bdas）。
spark于2010年3月首次開源，并于2013年6月被轉移到apache軟體基金會。
到2014年2月，它成為了apache軟體基金會的一個頂級項目。spark已經成為大資料領域最大的開源社群之一。現在，有超過50個組織裡的超過250位貢獻者正在為spark開發做出貢獻。它的使用者群增長迅猛，包括了從小型公司到财富500強公司。圖2-7顯示了 apache spark的發展曆史：
圖2-7 apache spark 的發展曆史
2.2.2 apache spark 是什麼
讓我們來了解一下apache spark 是什麼，以及是什麼使之成為大資料分析的利器：
apache spark 是一個快速的企業級大規模資料處理引擎，它可以與apache hadoop 進行互操作。
它是用 scala 編寫的。scala 是一種兼顧了面向對象和函數式的程式設計語言，它在 jvm 中運作。
spark 讓應用程式在處理過程中能夠可靠地在記憶體中分發資料。這是 spark 性能的關鍵，因為它讓應用程式能夠避免低效率的磁盤通路，并以記憶體速度進行計算。
通過讓每次疊代都通過記憶體通路資料，它能夠适用于疊代算法。
通過 scala、python 和 r 的互動式 shell，它為 java、scala、python 和 r 語言提供了本地支援。開發它的應用程式是比較容易的，并且需要的代碼量通常可以減少 2 到 10 倍。
spark 提供了一系列的庫，包括用于互動式分析的 spark sql 和 dataframe、用于機器學習的 mllib、用于圖形處理的 graphx 和用于實時分析的 spark streaming。你可以在同一個應用程式中無縫地組合這些功能。
spark 可以運作在 hadoop、mesos、 standalone 叢集管理器，内部硬體系統或雲計算平台上。
2.2.3 apache spark 不是什麼
hadoop 提供了用于存儲的 hdfs 和用于計算的 mr。但是，spark 不提供任何特定的存儲媒體。spark 主要是一個計算引擎，但你可以把資料存儲在記憶體裡或 tachyon 上進行處理。
spark 具有從存儲在 hdfs 或 hadoop api 支援的其他存儲系統（包括你的本地檔案系統、amazon s3、cassandra、hive、hbase、elasticsearch 等）中的任何檔案建立分布式資料集的能力。
重要的是要注意 spark 不是 hadoop，也不需要 hadoop 來運作它。它隻是為那些實作了 hadoop api 的存儲系統提供支援而已。spark 支援文本檔案、序列檔案、avro、parquet 和其他任何 hadoop 輸入格式。
spark是否會替代hadoop？
spark旨在與hadoop互操作。它不是hadoop的替代品，但它替代了hadoop 上的mr架構。把mr作為引擎的所有hadoop處理架構（sqoop、hive、pig、mahout、cascading和crunch），現在都把spark作為附加的處理引擎。
2.2.4 mapreduce 的問題
在性能和把業務問題轉換為 mr 問題方面，mr 開發人員都面臨着一些挑戰。讓我們來了解這些與 mr 相關的問題。以及如何在 apache spark 中解決這些問題：
mr為每個映射器和化簡器建立單獨的 jvm。啟動 jvm 需要相當長的時間。
mr 代碼需要大量的樣闆代碼。程式員需要從映射（map）和化簡（reduce）的角度來考慮并設計每個業務問題，這使得它成為一種非常難以開發的程式。光靠一個 mr 作業很少能進行完整的計算。你需要多個 mr 作業來完成整個任務，并且需要在所有層次都設計并跟蹤優化情況。hive 和 pig 解決了這個問題。但是，它們不一定适合所有的用例。
mr 作業會在每個作業之間将資料寫入磁盤，是以不适合疊代處理。
更進階别的抽象（如 cascading 和 scalding）能為 mr 作業提供更好的程式設計手段。但是，這樣并不會産生任何額外的性能優勢。
mr 也沒有提供理想的 api。
mr速度緩慢是因為 mr 作業中的每個作業都把資料存儲在磁盤上。對同一資料集的多個查詢會分别讀取資料，産生大量的磁盤讀寫，如圖2-8 所示：
圖2-8 mapreduce對比apache spark
spark 将 mr 的概念提升到更高水準，将中間資料存儲在記憶體中，并根據需要多次重複使用。這樣就在記憶體速度下提供了高性能，如圖2-8 所示。
如果我隻有一個mr作業，它的表現會與spark一樣嗎？