minimach梯度演算法

㈠ spark和hadoop的區別

直接比較Hadoop和Spark有難度，因為它們處理的許多任務都一樣，但是在一些方面又並不相互重疊。

比如說，Spark沒有文件管理功能，因而必須依賴Hadoop分布式文件系統(HDFS)或另外某種解決方案。

Hadoop框架的主要模塊包括如下：

• Hadoop Common

• Hadoop分布式文件系統(HDFS)

• Hadoop YARN

• Hadoop MapRece

雖然上述四個模塊構成了Hadoop的核心，不過還有其他幾個模塊。這些模塊包括：Ambari、Avro、Cassandra、Hive、 Pig、Oozie、Flume和Sqoop，它們進一步增強和擴展了Hadoop的功能。

Spark確實速度很快(最多比Hadoop MapRece快100倍)。Spark還可以執行批量處理，然而它真正擅長的是處理流工作負載、互動式查詢和機器學習。

相比MapRece基於磁碟的批量處理引擎，Spark賴以成名之處是其數據實時處理功能。Spark與Hadoop及其模塊兼容。實際上，在Hadoop的項目頁面上，Spark就被列為是一個模塊。

Spark有自己的頁面，因為雖然它可以通過YARN(另一種資源協調者)在Hadoop集群中運行，但是它也有一種獨立模式。它可以作為 Hadoop模塊來運行，也可以作為獨立解決方案來運行。

MapRece和Spark的主要區別在於，MapRece使用持久存儲，而Spark使用彈性分布式數據集(RDDS)。

性能

Spark之所以如此快速，原因在於它在內存中處理一切數據。沒錯，它還可以使用磁碟來處理未全部裝入到內存中的數據。

Spark的內存處理為來自多個來源的數據提供了近乎實時分析的功能：營銷活動、機器學習、物聯網感測器、日誌監控、安全分析和社交媒體網站。另 外，MapRece使用批量處理，其實從來就不是為驚人的速度設計的。它的初衷是不斷收集來自網站的信息，不需要這些數據具有實時性或近乎實時性。

易用性

支持Scala(原生語言)、Java、Python和Spark SQL。Spark SQL非常類似於SQL 92，所以幾乎不需要經歷一番學習，馬上可以上手。

Spark還有一種交互模式，那樣開發人員和用戶都可以獲得查詢和其他操作的即時反饋。MapRece沒有交互模式，不過有了Hive和Pig等附加模塊，採用者使用MapRece來得容易一點。

成本

「Spark已證明在數據多達PB的情況下也輕松自如。它被用於在數量只有十分之一的機器上，對100TB數據進行排序的速度比Hadoop MapRece快3倍。」這一成績讓Spark成為2014年Daytona GraySort基準。

兼容性

MapRece和Spark相互兼容;MapRece通過JDBC和ODC兼容諸多數據源、文件格式和商業智能工具，Spark具有與MapRece同樣的兼容性。

數據處理

MapRece是一種批量處理引擎。MapRece以順序步驟來操作，先從集群讀取數據，然後對數據執行操作，將結果寫回到集群，從集群讀 取更新後的數據，執行下一個數據操作，將那些結果寫回到結果，依次類推。Spark執行類似的操作，不過是在內存中一步執行。它從集群讀取數據後，對數據 執行操作，然後寫回到集群。

Spark還包括自己的圖形計算庫GraphX。GraphX讓用戶可以查看與圖形和集合同樣的數據。用戶還可以使用彈性分布式數據集(RDD)，改變和聯合圖形，容錯部分作了討論。

容錯

至於容錯，MapRece和Spark從兩個不同的方向來解決問題。MapRece使用TaskTracker節點，它為 JobTracker節點提供了心跳(heartbeat)。如果沒有心跳，那麼JobTracker節點重新調度所有將執行的操作和正在進行的操作，交 給另一個TaskTracker節點。這種方法在提供容錯性方面很有效，可是會大大延長某些操作(即便只有一個故障)的完成時間。

Spark使用彈性分布式數據集(RDD)，它們是容錯集合，裡面的數據元素可執行並行操作。RDD可以引用外部存儲系統中的數據集，比如共享式文件系統、HDFS、HBase，或者提供Hadoop InputFormat的任何數據源。Spark可以用Hadoop支持的任何存儲源創建RDD，包括本地文件系統，或前面所列的其中一種文件系統。

RDD擁有五個主要屬性：

• 分區列表

• 計算每個分片的函數

• 依賴其他RDD的項目列表

• 面向鍵值RDD的分區程序(比如說RDD是散列分區)，這是可選屬性

• 計算每個分片的首選位置的列表(比如HDFS文件的數據塊位置)，這是可選屬性

RDD可能具有持久性，以便將數據集緩存在內存中。這樣一來，以後的操作大大加快，最多達10倍。Spark的緩存具有容錯性，原因在於如果RDD的任何分區丟失，就會使用原始轉換，自動重新計算。

可擴展性

按照定義，MapRece和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身份驗證。

總結

Spark與MapRece是一種相互共生的關系。Hadoop提供了Spark所沒有的功能特性，比如分布式文件系統，而Spark 為需要它的那些數據集提供了實時內存處理。完美的大數據場景正是設計人員當初預想的那樣：讓Hadoop和Spark在同一個團隊裡面協同運行。

然後看這篇文章：Link



註：對下面這一段持保留意見：

此外我們這里還要講到的是一個關於spark的重要誤區—「spark是基於內存的技術」。它不是基於內存的技術；spark是一個管道式的執行引擎，而且在shuffle的過程中會將數據寫入磁碟(比如說，如果我們想針對某個欄位做聚合操作)、如果內存不夠的話也一樣會內存溢出(但是內存可以調整)。因此，spark之所以比MapRece快主要是因為它是管道式處理方式而不是有些人說的「基於內存的優化」。當然，spark在內存中做了緩存來提高性能，但這不是spark真正工作快的原因。

現在，我們再來完整比對一下：

1. MapRece可以被Spark Core替換？是的，它會隨著時間的推移被替代，而且這種替代是合理的。但是spark目前還不是特別成熟能完全替代MapRece。此外，也沒有人會完全放棄MapRece,除非所有依賴MapRece的工具都有可替代方案。比如說，想要在pig上運行的腳本能在spark上執行還是有些工作要做的。

（註：Pig是一種數據流語言，用來快速輕松的處理巨大的數據，雅虎推出的，現在正在走下坡路。Pig可以非常方便的處理HDFS和HBase的數據，和Hive一樣,Pig可以非常高效的處理其需要做的，通過直接操作Pig查詢可以節省大量的勞動和時間。當你想在你的數據上做一些轉換，並且不想編寫MapRece jobs就可以用Pig.）

2. Hive可以被Spark SQL替換？是的，這又是對的。但是我們需要理解的是Spark SQL對於spark本身來說還是比較年輕的，大概要年輕1.5倍。相對於比較成熟的Hive來說它只能算是玩具了吧，我將在一年半到兩年之內再回頭來看Spark SQL.。如果我們還記得的話，兩到三年前Impala就號稱要終結Hive,但是截止到目前兩種技術也還是共存狀態，Impala並沒有終結Hive。在這里對於Spark SQL來說也是一樣的。

3. Storm可以被Spark Streaming替換？是的，可以替換。只不過平心而論storm並不是Hadoop生態系統中的一員，因為它是完全獨立的工具。他們的計算模型並不太形同，所以我不認為storm會消失，反而仍會作為一個商業產品。

4. Mahout可以被MLib替換？公平的講，Machout已經失去了市場，而且從過去的幾年來看它正在快速失去市場。對於這個工具，我們可以說這里是Spark真正可以替換Hadoop生態系統中的地方。 (註：同意！Spark的ML非常好用！要好好學！)

因此，總的來說，這篇文章的結論是：

1.不要被大數據供應商的包裝所愚弄。他們大量推進的是市場而不是最終的真理。Hadoop最開始是被設計為可擴展的框架，而且其中很多部分是可替換的：可以將HDFS替換為Tachyon（現在新的名字是Alluxio），可以將YARN替換為Mesos，可以將MapRece替換為Tez並且在Tez之上可以運行Hive。這將會是Hadoop技術棧的可選方案或者完全替代方案？倘若我們放棄的MR（MapRece）而使用Tez,那麼它還會是Hadoop嗎？

2. Spark不能為我們提供完整的技術棧。它允許我們將它的功能集成到我們的Hadoop集群中並且從中獲益，而不用完全脫離我們老的集群方案。

3. Spark還不夠成熟。我認為在過三到四年我們就不會再叫「Hadoop棧」而是叫它「大數據棧」或者類似的稱呼。因為在大數據棧中我們有很廣泛的選擇可以選出不同的開源產品來組合在一起形成一個單獨的技術棧使用。