什麼是spark？

分散式計算框架，

Mapreduce也是分散式計算框架，但是Spark要多加2個字，分散式記憶體計算框架，牛就牛在記憶體這塊。MR分散式計算框架比較會偷懶，幹活幹著幹著就把活放著休息（寫到磁碟），而Spark則不偷懶，一直幹不停（資料都在記憶體），隨叫隨到，從不猶豫，並且Spark幹活也比較有方法，愛動腦子（DAG）。

所以和它的堂兄MapRedcue比起來，有如哪些不同點呢：

（1）Spark腦子聰明、不偷懶- 中間結果不輸出磁碟

​ MR喜歡將中間結果寫到磁碟上，MR做事又喜歡將一件事情分層幾個環節來做（多個stage，執行的時候講多個stage串聯起來），每個環節都把中間結果寫到磁碟，下個stage又從磁碟拿出來，難免囉嗦、麻煩效率低（MR做事比較死板，一板一眼按流程挨個做(一個任務分為多個stage序列執行)）。

​ Spark相對機靈一點，事先評估好做事情的策略和方法，哪些事情可以放在一起，哪些不放在一起，方法策略定好後（所有動作抽象為有向五環圖執行計劃DAG），再動手幹,規劃好的事情可以挨個做，也可以同時做，活不離手（資料在記憶體），當然有時候拿不過來了，也可以放一放手（寫到磁碟上），下次再要做的時候再拿起來繼續。

​ 但是顯然spark的缺點也明顯了，記憶體，你的資料一致放在記憶體，哪有那麼多記憶體讓你敗啊，如果和其他一樣需要消耗記憶體的服務在一起，肯定要打個你死我活。MR就不會，別人想多點記憶體，他一點都不在意，誰要誰拿去，哥不稀罕。

（2）脾氣不好-spark容錯比maprduce要差

​ 有點才華的人脾氣都大啊，spark比較有個性，脾氣確實不咋地。如果活幹著幹著失敗了，spark暴怒之下就要從頭再來（做事太急，急的都不知道自己在哪裡跌倒了-因為資料在記憶體，需要重新計算），而MR則不會從頭再來，他哪裡跌倒哪裡爬起來，因為做事情慢，所以也是有條不紊（知道在哪裡跌倒了-資料在磁碟）。

其實兩個人都有比較好的脾氣- 好的容錯能力，但是他們對比起來，MR容錯能力略好一點。

（3）相處能力（與其他元件的相容性）

​ spark可以自己單幹，也可以在yarn上一夥人幹，吃飯也不挑剔-（資料來源可以是HDFS支援的各類檔案格式），還可以通過jdbc和odbc和家族之外人共事（與傳統BI工具）

​ mr內心是這樣想的：這有什麼好拿出來炫耀的，我也可以做到。確實他們兩兄弟在這一點上是旗鼓相當的。

（4）身體健康（安全性）

· 血型- 程式語言

​ spark的選型是scala，mapreduce的血型是java，從血型看，scala更厲害一點，scala血型的人擅長幹體力活（處理資料），並且也支援其他血型（java，python，sql），尤其是對sql的支援，比mapreduce不知道強了多少倍。java血型更適合處理綜合性的複雜事情，並不是很擅長幹體力活，並且幹活時的套路太多了（寫個mr程式各種框架套著）

​ Spark 更易於程式設計，同時也包含互動式模式；Hadoop MapReduce 不易程式設計但是現有的很多工具使其更易於使用。

​ · 免疫能力-安全機制

​ 畢竟大哥就是大哥，年齡在那裡擺著呢，免疫能力當然更好一點-具備所有 Hadoop 支援的安全機制，同時也整合了其它基於 Hadoop 的安全專案， 比如 Knox 閘道器和 Sentry。志在解決 Hadoop 安全的 Rhino 專案也只是在新增 Sentry 支援時添加了 Spark 支援。否則 Spark 開發者們只能自己去提升其安全性了。

​ Spark 則略顯不足。 授權驗證由共享祕鑰機制支援，網路使用者介面則通過 servlet 過濾器和事件日誌保護。Spark 可以執行在 YARN 上並配合使用 HDFS， 這也就意味著它同時還擁有 Kerberos 認證授權驗證，HDFS 檔案許可機制和節點間的加密機制。

spark的優點

辛湜：Spark是一個高效的分散式計算系統，相比Hadoop有以下幾個優勢：

• 效能可以比Hadoop高100倍。

• Spark提供比Hadoop更上層的API，同樣的演算法在Spark中實現往往只有Hadoop的十分之一或者一百分之一的長度。

spark的骨幹

基於對MR的理解，回憶一下分散式計算碰到的幾個典型問題

（1）分散式情況下，資源如何分配，誰負責分配資源，資源都在哪裡 ？

（2）分散式情況下，任務如何分配，任務哪裡來，誰分配任務，分給誰？

（3）分散式情況下，任務執行的時候，如何跟蹤任務進度，誰統一彙總任務執行情況，下面的人如何回報任務？

（4）分散式情況下，任務執行的時候，如何跟蹤資源動態使用情況，誰負責統計所有資源情況，各個節點怎麼回報資源給統計的人？

其實分散式計算框架，就這點破事，折騰不出什麼新鮮花樣，基於對上面問題的思考，看看spark是怎麼解決的。

（1）資源分配問題：ClusterManager負責資源分配，怎麼分配由ClusterManager自己選擇分配演算法，資源都在Worker上面（一幫幹活的兄弟），ClusterManager首先必須知道各個兄弟有什麼資源，任務一旦來了（來了就需要消耗資源），ClusterManager根據實際情況切分任務，各個兄弟都攤派出一些資源（磁碟、記憶體、網路）來處理任務【一級分配】

（2）任務分配問題：任務分配可以有多種方式和策略，如基於YARN，MESOS來安排任務的分配和任務執行時對任務的監控，任務來源很明顯就是Driver app提交過來的。

（3）如何跟蹤執行的任務：任務的執行最後會落實到worker上，所以任務跟蹤必須是work和YARN等反饋，讓yarn來統一管理任務的執行情況，任務來了之後，worker內部也要調配人馬，組織以一個的executor來分解任務，從而提升任務執行的效率，能並行的並行，不能 的就序列，但是每一個executor執行的情況都要彙總起來，統一由worker的某個服務一起回報給yarn，driver app（互動介面可以看到任務執行的進度）。

（4）如何跟蹤資源的使用情況:Spark 的工作節點。對 Spark 應用程式來說，由叢集管理器分配得到資源的 Worker 節點主要負責以下工作：建立 Executor ，將資源和任務進一步分配給 Executor ，同步資源資訊給 Cluster Manager 。

心臟 - spark core

人心臟停止跳動就死掉了，spark的心臟是spark core，所有的功能都是建立在這基礎之上，

a.負責與下面的人打交道：與檔案系統如HDFS，

b.負責與上面的人打交道：應用程式開發

c.管理自家財產：如記憶體、CPU等

d. 管理自己事物：如任務的管理等

凡是要互動的功能，都和spark core有千絲萬縷的聯絡，沒有它，全都得掛

· 嘴巴 - spark sql

外界通過spark sql可以快速傳達要spark做什麼，並且這是一個懂得BI方言的嘴巴，很容易和傳統的BI家族進行互動，是外部和spark打交道的重要入口。

· 一個一直張開的嘴巴-spark streaming

有時候spark sql做事有點磨嘰，spark streaming 就來解決，一個一直張開的嘴巴從來就不關閉，一直吃吃吃….永不停歇。

· MLLIB

SPARK的開掛技能，spark很聰明，它知道有些人的腦子不夠用，寫不出來那些牛逼的機器學習演算法，所以他準備好了葵花寶典，寫不出來不要緊，按照葵花寶典就可以寫出來了，分類、迴歸、聚類、協同等等，可擴充套件的Spark機器學習庫，由通用的學習演算法和工具組成，包括二元分類、線性迴歸、聚類、協同過濾、梯度下降以及底層優化原語。用於機器學習和統計等場景

·GRAPHX

開掛技能，處理圖計算的寶典，直接用就可以了。GraphX是用於圖計算和並行圖計算的新的（alpha）Spark API。通過引入彈性分散式屬性圖（Resilient Distributed Property Graph），一種頂點和邊都帶有屬性的有向多重圖，擴充套件了Spark RDD。為了支援圖計算，GraphX暴露了一個基礎操作符集合（如subgraph，joinVertices和aggregateMessages）和一個經過優化的Pregel API變體。此外，GraphX還包括一個持續增長的用於簡化圖分析任務的圖演算法和構建器集合。

Spark Core

Spark Core是大規模平行計算和分散式資料處理的基礎引擎。它的職責有：

1. 記憶體管理和故障恢復;
2. 排程、分發和監控叢集上的作業;
3. 與儲存系統進行互動。

Spark引入了RDD(彈性分散式資料集)的概念，RDD是一個不可變的容錯、分散式物件集合，支援並行操作。RDD可包含任何型別的物件，可通過載入外部資料集或通過Driver程式中的集合來完成建立。

RDD支援兩種型別的操作：

1. 轉換(Transformations)指的是作用於一個RDD上並會產生包含結果的新RDD的操作(例如map, filter, join, union等)
2. 動作(Actions)指的是作用於一個RDD之後，會觸發叢集計算並得到返回值的操作(例如reduce，count，first等)

Spark中的轉換操作是“延遲的(lazy)”，意味著轉換時它們並不立即啟動計算並返回結果。相反，它們只是“記住”要執行的操作和待執行操作的資料集(例如檔案)。轉換操作僅當產生呼叫action操作時才會觸發實際計算，完成後將結果返回到driver程式。這種設計使Spark能夠更有效地執行，例如，如果一個大檔案以不同方式進行轉換操作並傳遞到首個action操作，此時Spark將只返回第一行的結果，而不是對整個檔案執行操作。

預設情況下，每次對其觸發執行action操作時，都需要重新計算前面經過轉換操作的RDD，不過，你也可以使用持久化或快取方法在記憶體中持久化RDD來避免這一問題，此時，Spark將在叢集的記憶體中保留這些元素，從而在下次使用時可以加速訪問。

SparkSQL

SparkSQL是Spark中支援SQL語言或者Hive查詢語言查詢資料的一個元件。它起先作為Apache Hive 埠執行在Spark之上(替代MapReduce)，現在已經被整合為Spark的一個重要元件。除支援各種資料來源，它還可以使用程式碼轉換來進行SQL查詢，功能十分強大。下面是相容Hive查詢的示例：

// sc is an existing SparkContext.  
val sqlContext = new org.apache.spark.sql.hive.HiveContext(sc)  
sqlContext.sql("CREATE TABLE IF NOT EXISTS src (key INT, value STRING)")  
sqlContext.sql("LOAD DATA LOCAL INPATH 'examples/src/main/resources/kv1.txt' INTO TABLE src") // Queries are expressed in HiveQL  
sqlContext.sql("FROM src SELECT key, value").collect().foreach(println) 

Spark Streaming

Spark Streaming支援實時處理流資料，例如生產環境中的Web伺服器日誌檔案(例如 Apache Flume和 HDFS/S3)，社交媒體資料(例如Twitter)和各種訊息佇列中(例如Kafka)的實時資料。在引擎內部，Spark Streaming接收輸入的資料流，與此同時將資料進行切分，形成資料片段(batch)，然後交由Spark引擎處理，按資料片段生成最終的結果流，如下圖所示。

Spark Streaming API與Spark Core緊密結合，使得開發人員可以輕鬆地同時駕駛批處理和流資料。

MLlib

MLlib是一個提供多種演算法的機器學習庫，目的是使用分類，迴歸，聚類，協同過濾等演算法能夠在叢集上橫向擴充套件(可以查閱Toptal中關於機器學習的文章詳細瞭解)。MLlib中的一些演算法也能夠與流資料一起使用，例如使用普通最小二乘法的線性迴歸演算法或k均值聚類演算法(以及更多其他正在開發的演算法)。Apache Mahout(一個Hadoop的機器學習庫)摒棄MapReduce並將所有的力量放在Spark MLlib上。

GraphX

GraphX是一個用於操作圖和執行圖並行操作的庫。它為ETL即Extraction-Transformation-Loading、探索性分析和迭代圖計算提供了統一的工具。除了內建的圖操作之外，它也提供了一個通用的圖演算法庫如PageRank。