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執行模式

1.6.2 Spark常用術語

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最佳學習路徑（作者：黃忠）