溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
今天就跟大家聊聊有關如何進行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應用程序的計算。
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. 復雜的批量處理（Batch Data Processing），偏重點在于處理海量數據的能力，至于處理速度可忍受，通常的時間可能是在數十分鐘到數小時；
2. 基于歷史數據的交互式查詢（Interactive Query），通常的時間在數十秒到數十分鐘之間
3. 基于實時數據流的數據處理（Streaming Data Processing），通常在數百毫秒到數秒之間
目前對以上三種場景需求都有比較成熟的處理框架，第一種情況可以用Hadoop的MapReduce來進行批量海量數據處理，第二種情況可以Impala進行交互式查詢，對于第三中情況可以用Storm分布式處理框架處理實時流式數據。以上三者都是比較獨立，各自一套維護成本比較高，而Spark的出現能夠一站式平臺滿意以上需求。
通過以上分析，總結Spark場景有以下幾個：
lSpark是基于內存的迭代計算框架，適用于需要多次操作特定數據集的應用場合。需要反復操作的次數越多，所需讀取的數據量越大，受益越大，數據量小但是計算密集度較大的場合，受益就相對較小
l由于RDD的特性，Spark不適用那種異步細粒度更新狀態的應用，例如web服務的存儲或者是增量的web爬蟲和索引。就是對于那種增量修改的應用模型不適合
l數據量不是特別大，但是要求實時統計分析需求
演進時間表：
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作為后續算子的計算平臺
目前大數據在互聯網公司主要應用在廣告、報表、推薦系統等業務上。在廣告業務方面需要大數據做應用分析、效果分析、定向優化等，在推薦系統方面則需要大數據優化相關排名、個性化推薦以及熱點點擊分析等。這些應用場景的普遍特點是計算量大、效率要求高。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已經廣泛使用在優酷土豆的視頻推薦（圖計算）、廣告業務等。
運行環境 | 模式 | 描述 |
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 |
術語 | 描述 |
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被提交的時候計算才被觸發。 |
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的數學計算等等。
前面介紹了Spark Core的基本情況，以下總結一下Spark內核架構：
l 提供了有向無環圖（DAG）的分布式并行計算框架，并提供Cache機制來支持多次迭代計算或者數據共享，大大減少迭代計算之間讀取數據局的開銷，這對于需要進行多次迭代的數據挖掘和分析性能有很大提升
l 在Spark中引入了RDD (Resilient Distributed Dataset) 的抽象，它是分布在一組節點中的只讀對象集合，這些集合是彈性的，如果數據集一部分丟失，則可以根據“血統”對它們進行重建，保證了數據的高容錯性；
l 移動計算而非移動數據，RDD Partition可以就近讀取分布式文件系統中的數據塊到各個節點內存中進行計算
l 使用多線程池模型來減少task啟動開稍
l 采用容錯的、高可伸縮性的akka作為通訊框架
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的整個流程。
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）的效率更高。
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。
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的代碼；盡管增加了編寫代碼的難度，但對于用戶來說接口統一。
BlinkDB 是一個用于在海量數據上運行交互式 SQL 查詢的大規模并行查詢引擎，它允許用戶通過權衡數據精度來提升查詢響應時間，其數據的精度被控制在允許的誤差范圍內。為了達到這個目標，BlinkDB 使用兩個核心思想:
l一個自適應優化框架，從原始數據隨著時間的推移建立并維護一組多維樣本；
l一個動態樣本選擇策略，選擇一個適當大小的示例基于查詢的準確性和（或）響應時間需求。
和傳統關系型數據庫不同，BlinkDB是一個很有意思的交互式查詢系統，就像一個蹺蹺板，用戶需要在查詢精度和查詢時間上做一權衡；如果用戶想更快地獲取查詢結果，那么將犧牲查詢結果的精度；同樣的，用戶如果想獲取更高精度的查詢結果，就需要犧牲查詢響應時間。用戶可以在查詢的時候定義一個失誤邊界。
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這個平臺
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效果最好。
SparkR是AMPLab發布的一個R開發包，使得R擺脫單機運行的命運，可以作為Spark的job運行在集群上，極大得擴展了R的數據處理能力。
SparkR的幾個特性：
l 提供了Spark中彈性分布式數據集（RDD）的API，用戶可以在集群上通過R shell交互性的運行Spark job。
l 支持序化閉包功能，可以將用戶定義函數中所引用到的變量自動序化發送到集群中其他的機器上。
l SparkR還可以很容易地調用R開發包，只需要在集群上執行操作前用includePackage讀取R開發包就可以了，當然集群上要安裝R開發包。
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和單節點的本地文件系統，以后將支持更多的文件系統。
看完上述內容，你們對如何進行spark原理及生態圈分析有進一步的了解嗎？如果還想了解更多知識或者相關內容，請關注億速云行業資訊頻道，感謝大家的支持。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
