Spark入門實戰系列--1.Spark及其生態圈簡介

時間 2019-11-20

標籤 spark 入門實戰系列 1.spark 及其生態圈簡介欄目 Spark 简体版

原文原文鏈接

【注】該系列文章以及使用到安裝包/測試數據能夠在《傾情大奉送--Spark入門實戰系列》獲取

1、簡介

1.1 Spark簡介

Spark是加州大學伯克利分校AMP實驗室（Algorithms, Machines, and People Lab）開發通用內存並行計算框架。Spark在2013年6月進入Apache成爲孵化項目，8個月後成爲Apache頂級項目，速度之快足見過人之處，Spark以其先進的設計理念，迅速成爲社區的熱門項目，圍繞着Spark推出了Spark SQL、Spark Streaming、MLLib和GraphX等組件，也就是BDAS（伯克利數據分析棧），這些組件逐漸造成大數據處理一站式解決平臺。從各方面報道來看Spark抱負並不是池魚，而是但願替代Hadoop在大數據中的地位，成爲大數據處理的主流標準，不過Spark尚未太多大項目的檢驗，離這個目標還有很大路要走。html

Spark使用Scala語言進行實現，它是一種面向對象、函數式編程語言，可以像操做本地集合對象同樣輕鬆地操做分佈式數據集（Scala 提供一個稱爲 Actor 的並行模型，其中Actor經過它的收件箱來發送和接收非同步信息而不是共享數據，該方式被稱爲：Shared Nothing 模型）。在Spark官網上介紹，它具備運行速度快、易用性好、通用性強和隨處運行等特色。node

l運行速度快web

Spark擁有DAG執行引擎，支持在內存中對數據進行迭代計算。官方提供的數據代表，若是數據由磁盤讀取，速度是Hadoop MapReduce的10倍以上，若是數據從內存中讀取，速度能夠高達100多倍。算法

l易用性好sql

Spark不只支持Scala編寫應用程序，並且支持Java和Python等語言進行編寫，特別是Scala是一種高效、可拓展的語言，可以用簡潔的代碼處理較爲複雜的處理工做。shell

l通用性強數據庫

Spark生態圈即BDAS（伯克利數據分析棧）包含了Spark Core、Spark SQL、Spark Streaming、MLLib和GraphX等組件，這些組件分別處理Spark Core提供內存計算框架、SparkStreaming的實時處理應用、Spark SQL的即席查詢、MLlib或MLbase的機器學習和GraphX的圖處理，它們都是由AMP實驗室提供，可以無縫的集成並提供一站式解決平臺。express

l隨處運行apache

Spark具備很強的適應性，可以讀取HDFS、Cassandra、HBase、S3和Techyon爲持久層讀寫原生數據，可以以Mesos、YARN和自身攜帶的Standalone做爲資源管理器調度job，來完成Spark應用程序的計算。編程

1.2 Spark與Hadoop差別

Spark是在借鑑了MapReduce之上發展而來的，繼承了其分佈式並行計算的優勢並改進了MapReduce明顯的缺陷，具體以下：

首先，Spark把中間數據放到內存中，迭代運算效率高。MapReduce中計算結果須要落地，保存到磁盤上，這樣勢必會影響總體速度，而Spark支持DAG圖的分佈式並行計算的編程框架，減小了迭代過程當中數據的落地，提升了處理效率。

其次，Spark容錯性高。Spark引進了彈性分佈式數據集RDD (Resilient Distributed Dataset) 的抽象，它是分佈在一組節點中的只讀對象集合，這些集合是彈性的，若是數據集一部分丟失，則能夠根據「血統」（即充許基於數據衍生過程）對它們進行重建。另外在RDD計算時能夠經過CheckPoint來實現容錯，而CheckPoint有兩種方式：CheckPoint Data，和Logging The Updates，用戶能夠控制採用哪一種方式來實現容錯。

最後，Spark更加通用。不像Hadoop只提供了Map和Reduce兩種操做，Spark提供的數據集操做類型有不少種，大體分爲：Transformations和Actions兩大類。Transformations包括Map、Filter、FlatMap、Sample、GroupByKey、ReduceByKey、Union、Join、Cogroup、MapValues、Sort和PartionBy等多種操做類型，同時還提供Count, Actions包括Collect、Reduce、Lookup和Save等操做。另外各個處理節點之間的通訊模型再也不像Hadoop只有Shuffle一種模式，用戶能夠命名、物化，控制中間結果的存儲、分區等。

1.3 Spark的適用場景

目前大數據處理場景有如下幾個類型：

1. 複雜的批量處理（Batch Data Processing），偏重點在於處理海量數據的能力，至於處理速度可忍受，一般的時間多是在數十分鐘到數小時；

2. 基於歷史數據的交互式查詢（Interactive Query），一般的時間在數十秒到數十分鐘之間

3. 基於實時數據流的數據處理（Streaming Data Processing），一般在數百毫秒到數秒之間

目前對以上三種場景需求都有比較成熟的處理框架，第一種狀況能夠用Hadoop的MapReduce來進行批量海量數據處理，第二種狀況能夠Impala進行交互式查詢，對於第三中狀況能夠用Storm分佈式處理框架處理實時流式數據。以上三者都是比較獨立，各自一套維護成本比較高，而Spark的出現可以一站式平臺滿意以上需求。

經過以上分析，總結Spark場景有如下幾個：

lSpark是基於內存的迭代計算框架，適用於須要屢次操做特定數據集的應用場合。須要反覆操做的次數越多，所需讀取的數據量越大，受益越大，數據量小可是計算密集度較大的場合，受益就相對較小

l因爲RDD的特性，Spark不適用那種異步細粒度更新狀態的應用，例如web服務的存儲或者是增量的web爬蟲和索引。就是對於那種增量修改的應用模型不適合

l數據量不是特別大，可是要求實時統計分析需求

1.4 Spark演進時間表

演進時間表：

l 2009年由Berkeley's AMPLab開始編寫最初的源代碼

l 2010年開放源代碼

l 2013年6月進入Apache孵化器項目

l 2014年2月成爲Apache的頂級項目（8個月時間）

l 2014年5月底Spark1.0.0發佈

l 2014年9月Spark1.1.0發佈

l 2014年12月Spark1.2.0發佈

目前狀況：

l 目前已經有30+公司100+開發者在提交代碼

l Hadoop最大的廠商Cloudera宣稱加大Spark框架的投入來取代Mapreduce

l Hortonworks

l Hadoop廠商MapR投入Spark陣營

l Apache Mahout放棄MapReduce，將使用Spark做爲後續算子的計算平臺

1.5 Spark成功案例

目前大數據在互聯網公司主要應用在廣告、報表、推薦系統等業務上。在廣告業務方面須要大數據作應用分析、效果分析、定向優化等，在推薦系統方面則須要大數據優化相關排名、個性化推薦以及熱點點擊分析等。這些應用場景的廣泛特色是計算量大、效率要求高。Spark偏偏知足了這些要求，該項目一經推出便受到開源社區的普遍關注和好評。並在近兩年內發展成爲大數據處理領域最煊赫一時的開源項目。

本章將列舉國內外應用Spark的成功案例。

1. 騰訊

廣點通是最先使用Spark的應用之一。騰訊大數據精準推薦藉助Spark快速迭代的優點，圍繞「數據+算法+系統」這套技術方案，實現了在「數據實時採集、算法實時訓練、系統實時預測」的全流程實時並行高維算法，最終成功應用於廣點通pCTR投放系統上，支持天天上百億的請求量。

基於日誌數據的快速查詢系統業務構建於Spark之上的Shark，利用其快速查詢以及內存表等優點，承擔了日誌數據的即席查詢工做。在性能方面，廣泛比Hive高2-10倍，若是使用內存表的功能，性能將會比Hive快百倍。

2. Yahoo

Yahoo將Spark用在Audience Expansion中的應用。Audience Expansion是廣告中尋找目標用戶的一種方法：首先廣告者提供一些觀看了廣告而且購買產品的樣本客戶，據此進行學習，尋找更多可能轉化的用戶，對他們定向廣告。Yahoo採用的算法是logistic regression。同時因爲有些SQL負載須要更高的服務質量，又加入了專門跑Shark的大內存集羣，用於取代商業BI/OLAP工具，承擔報表/儀表盤和交互式/即席查詢，同時與桌面BI工具對接。目前在Yahoo部署的Spark集羣有112臺節點，9.2TB內存。

3. 淘寶

阿里搜索和廣告業務，最初使用Mahout或者本身寫的MR來解決複雜的機器學習，致使效率低並且代碼不易維護。淘寶技術團隊使用了Spark來解決屢次迭代的機器學習算法、高計算複雜度的算法等。將Spark運用於淘寶的推薦相關算法上,同時還利用Graphx解決了許多生產問題，包括如下計算場景：基於度分佈的中樞節點發現、基於最大連通圖的社區發現、基於三角形計數的關係衡量、基於隨機遊走的用戶屬性傳播等。

4. 優酷土豆

優酷土豆在使用Hadoop集羣的突出問題主要包括：第一是商業智能BI方面，分析師提交任務以後須要等待好久才獲得結果；第二就是大數據量計算，好比進行一些模擬廣告投放之時，計算量很是大的同時對效率要求也比較高，最後就是機器學習和圖計算的迭代運算也是須要耗費大量資源且速度很慢。

最終發現這些應用場景並不適合在MapReduce裏面去處理。經過對比，發現Spark性能比MapReduce提高不少。首先，交互查詢響應快，性能比Hadoop提升若干倍；模擬廣告投放計算效率高、延遲小（同hadoop比延遲至少下降一個數量級）；機器學習、圖計算等迭代計算，大大減小了網絡傳輸、數據落地等，極大的提升的計算性能。目前Spark已經普遍使用在優酷土豆的視頻推薦（圖計算）、廣告業務等。

1.6 Spark術語

1.6.1 Spark運行模式

運行環境	模式	描述
Local	本地模式	經常使用於本地開發測試，本地還分爲local單線程和local-cluster多線程;
Standalone	集羣模式	典型的Mater/slave模式，不過也能看出Master是有單點故障的；Spark支持 ZooKeeper來實現HA
On yarn	集羣模式	運行在yarn資源管理器框架之上，由yarn負責資源管理，Spark負責任務調度和計算
On mesos	集羣模式	運行在mesos資源管理器框架之上，由mesos負責資源管理，Spark負責任務調度和計算
On cloud	集羣模式	好比AWS的EC2，使用這個模式能很方便的訪問Amazon的S3; Spark支持多種分佈式存儲系統：HDFS和S3

1.6.2 Spark經常使用術語

術語	描述
Application	Spark的應用程序，包含一個Driver program和若干Executor
SparkContext	Spark應用程序的入口，負責調度各個運算資源，協調各個Worker Node上的Executor
Driver Program	運行Application的main()函數而且建立SparkContext
Executor	是爲Application運行在Worker node上的一個進程，該進程負責運行Task，而且負責將數據存在內存或者磁盤上。每一個Application都會申請各自的Executor來處理任務
Cluster Manager	在集羣上獲取資源的外部服務 (例如：Standalone、Mesos、Yarn)
Worker Node	集羣中任何能夠運行Application代碼的節點，運行一個或多個Executor進程
Task	運行在Executor上的工做單元
Job	SparkContext提交的具體Action操做，常和Action對應
Stage	每一個Job會被拆分不少組task，每組任務被稱爲Stage，也稱TaskSet
RDD	是Resilient distributed datasets的簡稱，中文爲彈性分佈式數據集;是Spark最核心的模塊和類
DAGScheduler	根據Job構建基於Stage的DAG，並提交Stage給TaskScheduler
TaskScheduler	將Taskset提交給Worker node集羣運行並返回結果
Transformations	是Spark API的一種類型，Transformation返回值仍是一個RDD，全部的Transformation採用的都是懶策略，若是隻是將Transformation提交是不會執行計算的
Action	是Spark API的一種類型，Action返回值不是一個RDD，而是一個scala集合；計算只有在Action被提交的時候計算才被觸發。

2、生態系統

Spark生態圈也稱爲BDAS（伯克利數據分析棧），是伯克利APMLab實驗室打造的，力圖在算法（Algorithms）、機器（Machines）、人（People）之間經過大規模集成來展示大數據應用的一個平臺。伯克利AMPLab運用大數據、雲計算、通訊等各類資源以及各類靈活的技術方案，對海量不透明的數據進行甄別並轉化爲有用的信息，以供人們更好的理解世界。該生態圈已經涉及到機器學習、數據挖掘、數據庫、信息檢索、天然語言處理和語音識別等多個領域。

Spark生態圈以Spark Core爲核心，從HDFS、Amazon S3和HBase等持久層讀取數據，以MESS、YARN和自身攜帶的Standalone爲資源管理器調度Job完成Spark應用程序的計算。這些應用程序能夠來自於不一樣的組件，如Spark Shell/Spark Submit的批處理、Spark Streaming的實時處理應用、Spark SQL的即席查詢、BlinkDB的權衡查詢、MLlib/MLbase的機器學習、GraphX的圖處理和SparkR的數學計算等等。

2.1 Spark Core

前面介紹了Spark Core的基本狀況，如下總結一下Spark內核架構：

l 提供了有向無環圖（DAG）的分佈式並行計算框架，並提供Cache機制來支持屢次迭代計算或者數據共享，大大減小迭代計算之間讀取數據局的開銷，這對於須要進行屢次迭代的數據挖掘和分析性能有很大提高

l 在Spark中引入了RDD (Resilient Distributed Dataset) 的抽象，它是分佈在一組節點中的只讀對象集合，這些集合是彈性的，若是數據集一部分丟失，則能夠根據「血統」對它們進行重建，保證了數據的高容錯性；

l 移動計算而非移動數據，RDD Partition能夠就近讀取分佈式文件系統中的數據塊到各個節點內存中進行計算

l 使用多線程池模型來減小task啓動開稍

l 採用容錯的、高可伸縮性的akka做爲通信框架

2.2 SparkStreaming

SparkStreaming是一個對實時數據流進行高通量、容錯處理的流式處理系統，能夠對多種數據源（如Kdfka、Flume、Twitter、Zero和TCP 套接字）進行相似Map、Reduce和Join等複雜操做，並將結果保存到外部文件系統、數據庫或應用到實時儀表盤。

Spark Streaming構架

l計算流程：Spark Streaming是將流式計算分解成一系列短小的批處理做業。這裏的批處理引擎是Spark Core，也就是把Spark Streaming的輸入數據按照batch size（如1秒）分紅一段一段的數據（Discretized Stream），每一段數據都轉換成Spark中的RDD（Resilient Distributed Dataset），而後將Spark Streaming中對DStream的Transformation操做變爲針對Spark中對RDD的Transformation操做，將RDD通過操做變成中間結果保存在內存中。整個流式計算根據業務的需求能夠對中間的結果進行疊加或者存儲到外部設備。下圖顯示了Spark Streaming的整個流程。

圖Spark Streaming構架

l容錯性：對於流式計算來講，容錯性相當重要。首先咱們要明確一下Spark中RDD的容錯機制。每個RDD都是一個不可變的分佈式可重算的數據集，其記錄着肯定性的操做繼承關係（lineage），因此只要輸入數據是可容錯的，那麼任意一個RDD的分區（Partition）出錯或不可用，都是能夠利用原始輸入數據經過轉換操做而從新算出的。

對於Spark Streaming來講，其RDD的傳承關係以下圖所示，圖中的每個橢圓形表示一個RDD，橢圓形中的每一個圓形表明一個RDD中的一個Partition，圖中的每一列的多個RDD表示一個DStream（圖中有三個DStream），而每一行最後一個RDD則表示每個Batch Size所產生的中間結果RDD。咱們能夠看到圖中的每個RDD都是經過lineage相鏈接的，因爲Spark Streaming輸入數據能夠來自於磁盤，例如HDFS（多份拷貝）或是來自於網絡的數據流（Spark Streaming會將網絡輸入數據的每個數據流拷貝兩份到其餘的機器）都能保證容錯性，因此RDD中任意的Partition出錯，均可以並行地在其餘機器上將缺失的Partition計算出來。這個容錯恢復方式比連續計算模型（如Storm）的效率更高。

Spark Streaming中RDD的lineage關係圖

l實時性：對於實時性的討論，會牽涉到流式處理框架的應用場景。Spark Streaming將流式計算分解成多個Spark Job，對於每一段數據的處理都會通過Spark DAG圖分解以及Spark的任務集的調度過程。對於目前版本的Spark Streaming而言，其最小的Batch Size的選取在0.5~2秒鐘之間（Storm目前最小的延遲是100ms左右），因此Spark Streaming可以知足除對實時性要求很是高（如高頻實時交易）以外的全部流式準實時計算場景。

l擴展性與吞吐量：Spark目前在EC2上已可以線性擴展到100個節點（每一個節點4Core），能夠以數秒的延遲處理6GB/s的數據量（60M records/s），其吞吐量也比流行的Storm高2～5倍，圖4是Berkeley利用WordCount和Grep兩個用例所作的測試，在Grep這個測試中，Spark Streaming中的每一個節點的吞吐量是670k records/s，而Storm是115k records/s。

Spark Streaming與Storm吞吐量比較圖

2.3 Spark SQL

Shark是SparkSQL的前身，它發佈於3年前，那個時候Hive能夠說是SQL on Hadoop的惟一選擇，負責將SQL編譯成可擴展的MapReduce做業，鑑於Hive的性能以及與Spark的兼容，Shark項目由此而生。

Shark即Hive on Spark，本質上是經過Hive的HQL解析，把HQL翻譯成Spark上的RDD操做，而後經過Hive的metadata獲取數據庫裏的表信息，實際HDFS上的數據和文件，會由Shark獲取並放到Spark上運算。Shark的最大特性就是快和與Hive的徹底兼容，且能夠在shell模式下使用rdd2sql()這樣的API，把HQL獲得的結果集，繼續在scala環境下運算，支持本身編寫簡單的機器學習或簡單分析處理函數，對HQL結果進一步分析計算。

在2014年7月1日的Spark Summit上，Databricks宣佈終止對Shark的開發，將重點放到Spark SQL上。Databricks表示，Spark SQL將涵蓋Shark的全部特性，用戶能夠從Shark 0.9進行無縫的升級。在會議上，Databricks表示，Shark更可能是對Hive的改造，替換了Hive的物理執行引擎，所以會有一個很快的速度。然而，不容忽視的是，Shark繼承了大量的Hive代碼，所以給優化和維護帶來了大量的麻煩。隨着性能優化和先進分析整合的進一步加深，基於MapReduce設計的部分無疑成爲了整個項目的瓶頸。所以，爲了更好的發展，給用戶提供一個更好的體驗，Databricks宣佈終止Shark項目，從而將更多的精力放到Spark SQL上。

Spark SQL容許開發人員直接處理RDD，同時也可查詢例如在 Apache Hive上存在的外部數據。Spark SQL的一個重要特色是其可以統一處理關係表和RDD，使得開發人員能夠輕鬆地使用SQL命令進行外部查詢，同時進行更復雜的數據分析。除了Spark SQL外，Michael還談到Catalyst優化框架，它容許Spark SQL自動修改查詢方案，使SQL更有效地執行。

還有Shark的做者是來自中國的博士生辛湜（Reynold Xin），也是Spark的核心成員，具體信息能夠看他的專訪 http://www.csdn.net/article/2013-04-26/2815057-Spark-Reynold

Spark SQL的特色:

l引入了新的RDD類型SchemaRDD，能夠象傳統數據庫定義表同樣來定義SchemaRDD，SchemaRDD由定義了列數據類型的行對象構成。SchemaRDD能夠從RDD轉換過來，也能夠從Parquet文件讀入，也可使用HiveQL從Hive中獲取。

l內嵌了Catalyst查詢優化框架，在把SQL解析成邏輯執行計劃以後，利用Catalyst包裏的一些類和接口，執行了一些簡單的執行計劃優化，最後變成RDD的計算

l在應用程序中能夠混合使用不一樣來源的數據，如能夠未來自HiveQL的數據和來自SQL的數據進行Join操做。

Shark的出現使得SQL-on-Hadoop的性能比Hive有了10-100倍的提升，那麼，擺脫了Hive的限制，SparkSQL的性能又有怎麼樣的表現呢？雖然沒有Shark相對於Hive那樣矚目地性能提高，但也表現得很是優異，以下圖所示：

爲何sparkSQL的性能會獲得怎麼大的提高呢？主要sparkSQL在下面幾點作了優化：

1. 內存列存儲（In-Memory Columnar Storage） sparkSQL的表數據在內存中存儲不是採用原生態的JVM對象存儲方式，而是採用內存列存儲；

2. 字節碼生成技術（Bytecode Generation） Spark1.1.0在Catalyst模塊的expressions增長了codegen模塊，使用動態字節碼生成技術，對匹配的表達式採用特定的代碼動態編譯。另外對SQL表達式都做了CG優化， CG優化的實現主要仍是依靠Scala2.10的運行時放射機制（runtime reflection）；

3. Scala代碼優化 SparkSQL在使用Scala編寫代碼的時候，儘可能避免低效的、容易GC的代碼；儘管增長了編寫代碼的難度，但對於用戶來講接口統一。

2.4 BlinkDB

BlinkDB 是一個用於在海量數據上運行交互式 SQL 查詢的大規模並行查詢引擎，它容許用戶經過權衡數據精度來提高查詢響應時間，其數據的精度被控制在容許的偏差範圍內。爲了達到這個目標，BlinkDB 使用兩個核心思想:

l一個自適應優化框架，從原始數據隨着時間的推移創建並維護一組多維樣本；

l一個動態樣本選擇策略，選擇一個適當大小的示例基於查詢的準確性和（或）響應時間需求。

和傳統關係型數據庫不一樣，BlinkDB是一個頗有意思的交互式查詢系統，就像一個蹺蹺板，用戶須要在查詢精度和查詢時間上作一權衡；若是用戶想更快地獲取查詢結果，那麼將犧牲查詢結果的精度；一樣的，用戶若是想獲取更高精度的查詢結果，就須要犧牲查詢響應時間。用戶能夠在查詢的時候定義一個失誤邊界。

2.5 MLBase/MLlib

MLBase是Spark生態圈的一部分專一於機器學習，讓機器學習的門檻更低，讓一些可能並不瞭解機器學習的用戶也能方便地使用MLbase。MLBase分爲四部分：MLlib、MLI、ML Optimizer和MLRuntime。

l ML Optimizer會選擇它認爲最適合的已經在內部實現好了的機器學習算法和相關參數，來處理用戶輸入的數據，並返回模型或別的幫助分析的結果；

l MLI 是一個進行特徵抽取和高級ML編程抽象的算法實現的API或平臺；

l MLlib是Spark實現一些常見的機器學習算法和實用程序，包括分類、迴歸、聚類、協同過濾、降維以及底層優化，該算法能夠進行可擴充； MLRuntime 基於Spark計算框架，將Spark的分佈式計算應用到機器學習領域。

總的來講，MLBase的核心是他的優化器，把聲明式的Task轉化成複雜的學習計劃，產出最優的模型和計算結果。與其餘機器學習Weka和Mahout不一樣的是：

l MLBase是分佈式的，Weka是一個單機的系統；

l MLBase是自動化的，Weka和Mahout都須要使用者具有機器學習技能，來選擇本身想要的算法和參數來作處理；

l MLBase提供了不一樣抽象程度的接口，讓算法能夠擴充

l MLBase基於Spark這個平臺

2.6 GraphX

GraphX是Spark中用於圖(e.g., Web-Graphs and Social Networks)和圖並行計算(e.g., PageRank and Collaborative Filtering)的API,能夠認爲是GraphLab(C++)和Pregel(C++)在Spark(Scala)上的重寫及優化，跟其餘分佈式圖計算框架相比，GraphX最大的貢獻是，在Spark之上提供一棧式數據解決方案，能夠方便且高效地完成圖計算的一整套流水做業。GraphX最早是伯克利AMPLAB的一個分佈式圖計算框架項目，後來整合到Spark中成爲一個核心組件。

GraphX的核心抽象是Resilient Distributed Property Graph，一種點和邊都帶屬性的有向多重圖。它擴展了Spark RDD的抽象，有Table和Graph兩種視圖，而只須要一份物理存儲。兩種視圖都有本身獨有的操做符，從而得到了靈活操做和執行效率。如同Spark，GraphX的代碼很是簡潔。GraphX的核心代碼只有3千多行，而在此之上實現的Pregel模型，只要短短的20多行。GraphX的代碼結構總體下圖所示，其中大部分的實現，都是圍繞Partition的優化進行的。這在某種程度上說明了點分割的存儲和相應的計算優化的確是圖計算框架的重點和難點。

GraphX的底層設計有如下幾個關鍵點。

1.對Graph視圖的全部操做，最終都會轉換成其關聯的Table視圖的RDD操做來完成。這樣對一個圖的計算，最終在邏輯上，等價於一系列RDD的轉換過程。所以，Graph最終具有了RDD的3個關鍵特性：Immutable、Distributed和Fault-Tolerant。其中最關鍵的是Immutable（不變性）。邏輯上，全部圖的轉換和操做都產生了一個新圖；物理上，GraphX會有必定程度的不變頂點和邊的複用優化，對用戶透明。

2.兩種視圖底層共用的物理數據，由RDD[Vertex-Partition]和RDD[EdgePartition]這兩個RDD組成。點和邊實際都不是以表Collection[tuple]的形式存儲的，而是由VertexPartition/EdgePartition在內部存儲一個帶索引結構的分片數據塊，以加速不一樣視圖下的遍歷速度。不變的索引結構在RDD轉換過程當中是共用的，下降了計算和存儲開銷。

3.圖的分佈式存儲採用點分割模式，並且使用partitionBy方法，由用戶指定不一樣的劃分策略（PartitionStrategy）。劃分策略會將邊分配到各個EdgePartition，頂點Master分配到各個VertexPartition，EdgePartition也會緩存本地邊關聯點的Ghost副本。劃分策略的不一樣會影響到所須要緩存的Ghost副本數量，以及每一個EdgePartition分配的邊的均衡程度，須要根據圖的結構特徵選取最佳策略。目前有EdgePartition2d、EdgePartition1d、RandomVertexCut和CanonicalRandomVertexCut這四種策略。在淘寶大部分場景下，EdgePartition2d效果最好。

2.7 SparkR

SparkR是AMPLab發佈的一個R開發包，使得R擺脫單機運行的命運，能夠做爲Spark的job運行在集羣上，極大得擴展了R的數據處理能力。

SparkR的幾個特性：

l 提供了Spark中彈性分佈式數據集（RDD）的API，用戶能夠在集羣上經過R shell交互性的運行Spark job。

l 支持序化閉包功能，能夠將用戶定義函數中所引用到的變量自動序化發送到集羣中其餘的機器上。

l SparkR還能夠很容易地調用R開發包，只須要在集羣上執行操做前用includePackage讀取R開發包就能夠了，固然集羣上要安裝R開發包。

2.8 Tachyon

Tachyon是一個高容錯的分佈式文件系統，容許文件之內存的速度在集羣框架中進行可靠的共享，就像Spark和 MapReduce那樣。經過利用信息繼承，內存侵入，Tachyon得到了高性能。Tachyon工做集文件緩存在內存中，而且讓不一樣的 Jobs/Queries以及框架都能內存的速度來訪問緩存文件」。所以，Tachyon能夠減小那些須要常用的數據集經過訪問磁盤來得到的次數。Tachyon兼容Hadoop，現有的Spark和MR程序不須要任何修改而運行。