Spark入門實戰系列--1.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還沒有太多大項目的檢驗，離這個目标還有很大路要走。
Spark使用Scala語言進行實作，它是一種面向對象、函數式程式設計語言，能夠像操作本地集合對象一樣輕松地操作分布式資料集（Scala 提供一個稱為 Actor 的并行模型，其中Actor通過它的收件箱來發送和接收非同步資訊而不是共享資料，該方式被稱為：Shared Nothing 模型）。在Spark官網上介紹，它具有運作速度快、易用性好、通用性強和随處運作等特點。
l運作速度快
Spark擁有DAG執行引擎，支援在記憶體中對資料進行疊代計算。官方提供的資料表明，如果資料由磁盤讀取，速度是Hadoop MapReduce的10倍以上，如果資料從記憶體中讀取，速度可以高達100多倍。
l易用性好
Spark不僅支援Scala編寫應用程式，而且支援Java和Python等語言進行編寫，特别是Scala是一種高效、可拓展的語言，能夠用簡潔的代碼處理較為複雜的處理工作。
l通用性強
Spark生态圈即BDAS（伯克利資料分析棧）包含了Spark Core、Spark SQL、Spark Streaming、MLLib和GraphX等元件，這些元件分别處理Spark Core提供記憶體計算架構、SparkStreaming的實時處理應用、Spark SQL的即席查詢、MLlib或MLbase的機器學習和GraphX的圖處理，它們都是由AMP實驗室提供，能夠無縫的內建并提供一站式解決平台。
l随處運作
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程式不需要任何修改而運作。
在2013年4月，AMPLab共享了其Tachyon 0.2.0 Alpha版本的Tachyon，其宣稱性能為HDFS的300倍，繼而受到了極大的關注。Tachyon的幾個特性如下：
lJAVA-Like File API
Tachyon提供類似JAVA File類的API,
l相容性
Tachyon實作了HDFS接口，是以Spark和MR程式不需要任何修改即可運作。
l可插拔的底層檔案系統
Tachyon是一個可插拔的底層檔案系統，提供容錯功能。tachyon将記憶體資料記錄在底層檔案系統。它有一個通用的接口，使得可以很容易的插入到不同的底層檔案系統。目前支援HDFS，S3，GlusterFS和單節點的本地檔案系統，以後将支援更多的檔案系統。
參考資料：
（1）Spark官網 http://spark.apache.org
（2）Spark生态圈參考《Spark1.0.0 生态圈一覽》 http://blog.csdn.net/book_mmicky/article/details/29362405
（3）Spark應用案例參考《大資料計算新貴Spark在騰訊雅虎優酷成功應用解析》 http://www.csdn.net/article/2014-06-05/2820089
（4）Spark Streming介紹參考《Spark Streaming：大規模流式資料處理的新貴》http://www.csdn.net/article/2014-01-28/2818282-Spark-Streaming-big-data
（5）Spark SQL介紹《sparkSQL1.1入門》 http://blog.csdn.net/bluejoe2000/article/details/41247857
（6）GraphX參考《快刀初試：Spark GraphX在淘寶的實踐》 http://www.csdn.net/article/2014-08-07/2821097
（7）GraphX參考《基于Spark的圖計算架構 GraphX 入門介紹》 http://suanfazu.com/t/ji-yu-sparkde-tu-ji-suan-kuang-jia-graphx-ru-men-jie-shao/244
（8）【Spark專刊】Spark最佳學習路徑（作者：黃忠）
文章轉自：https://www.cnblogs.com/shishanyuan/archive/2015/08/04/4700615.html