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应用程序的计算。编程
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的整个流程。
图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吞吐量比较图
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和单节点的本地文件系统,之后将支持更多的文件系统。
参考资料:
(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最佳学习路径(做者:黄忠)