Spark生态系统：扩展Spark功能的工具集

Spark的设计目的是全栈式地解决批处理、结构化数据查询、流计算、图计算和机器学习业务场景，此外其通用性还体现在对存储层（如HDFS、cassandra^[8]）和资源管理层（Mesos^[9]、YARN）的支持。Spark生态系统如图1-6所示，在Spark Core的上层有支持SQL查询的子项目Spark SQL、支持机器学习MLlib库、支持图计算的GraphX以及支持流计算的Spark Streaming等。这样的生态圈让Spark的核心RDD抽象数据集能在不同应用中使用，大大减少了数据转换的消耗和运维管理的资源占用。

图1-6 Spark生态系统

图1-6所示的生态系统被AMPLab称为伯克利数据分析栈（Berkeley Data Analytics Stack，BDAS），下面对BDAS中的主要项目进行介绍。

1.Spark

作为Spark生态系统的核心，Spark主要提供基于内存计算的功能，不仅包含Hadoop的计算模型MapReduce，还包含很多其他的API，如reduceByKey、groupByKey、foreach、join和filter等。Spark将数据抽象为RDD，有效地扩充了Spark编程模型，使Spark成为多面手，能让交互式查询、流处理、机器学习和图计算无缝交叉融合，极大地扩展了Spark的业务应用场景，同时Spark使用函数式编程语言Scala，使编程更简洁高效。

2.SQL/Shark

Shark是为了将Hive应用移植到Spark平台下而出现的数据仓库。Shark在HQL（一般将Hive上对SQL支持的语言称为HQL）方面重用了Hive的HQL解析、逻辑计划翻译、执行计划优化等逻辑，可以认为仅将底层物理执行计划从Hadoop的MapReduce作业转移到Spark作业，此外还依赖Hive Metastore和Hive SerDe。这样做会导致执行计划过于依赖Hive，不利于添加新的优化策略，因此为了减少对Hive本身框架的依赖，引入了Spark SQL。

Spark SQL仅依赖HQL Parser、Hive metostore和Hive SerDe，即说明在解析SQL生成抽象语法数（Abstract Syntax Tree，AST）后的部分都是由Spark SQL自身的Calalyst负责（图1-7所示为Spark SQL与Hive之间的关系），利用scala模式匹配等函数式语言的特性，让Catalyst开发的执行计划优化策略比Hive更简洁。除了HQL以外，Spark SQL还内建了一个精简的SQL parser，以及一套Scala特定领域语言（Domain Specific Language，DSL）。也就是说，如果只是使用Spark SQL内建的SQL方言或Scala DSL对原生RDD对象进行关系查询，用户在开发Spark应用时完全不需要依赖Hive的任何东西，因而日后的发展趋势重点在Spark SQL，对Shark的支持会逐渐淡化。

Spark SQL从Spark 1.3开始支持提供一个抽象的编程结构DataFrames，能充当分布式SQL查询引擎。DataFrame本质就是一张关系型数据库中的表，但是底层有很多方面的优化，它能从多种数据源中转化而来，例如结构型数据文件（如Avro，Parquet，ORC，JSON和JDBC）、Hive表、外部数据库或已经存在的RDD。对于Spark SQL，本书将在之后的第4章4.1节中对其展开进行更详细的介绍。

图1-7 Spark SQL和Hive的关系

3.Spark Streaming

Spark Streaming是基于Spark的上层应用框架，使用内建API，能像写批处理文件一样编写流处理任务，易于使用，它还提供良好的容错特性，能在节点宕机情况下同时恢复丢失的工作和操作状态。

在处理时间方面，Spark Streaming是基于时间片的准实时处理，能达到秒级延迟，吞吐量比Storm大，此外还能和Spark SQL与Spark MLlib联合使用，构建强大的流状态运行即席（ad-hoc）查询和实时推荐系统。对于Spark Streaming，本书将在之后第4章4.2节对其展开进行更详细的介绍。(www.xing528.com)

4.GraphX

GraphX是基于Spark的上层分布式图计算框架，提供了类似Goole图算法引擎Pregel的功能，主要处理社交网络等节点和边模型的问题。因为Spark能很好地支持迭代计算，故处理效率优势明显。GraphX的较新版本（Spark 1.4.1）支持PageRank、SVD++和三角形计数等算法。目前国内的淘宝技术部在GraphX方面的应用成果很多，可以参考http：//rdc.taobao.org了解更多信息。对于GraphX，本书将在之后第4章4.3节对其展开进行更详细的介绍。

5.MLlib

MLlib是Spark生态系统在机器学习领域的重要应用，它充分发挥Spark迭代计算的优势，比传统MapReduce模型算法快一百倍以上。

MLlib 1.3实现了逻辑回归、线性SVM、随机森林、K-means、奇异值分解等多种分布式机器学习算法，充分利用RDD的迭代优势，能对大规模数据应用机器学习模型，并能与Spark Streaming、Spark SQL进行协作开发应用，让机器学习算法在基于大数据的预测、推荐和模式识别等方面应用更广泛。对于MLlib以及其中支持的算法，本书将在之后第4章4.4节对其展开进行更详细的介绍。

6.Tachyon

Tachyon是基于内存的分布式文件系统。过去，Spark的计算功能和内存管理都在JVM中，导致JVM负载较高，同时各任务共享数据也不方便，当JVM崩溃后很多缓冲数据也会丢失，为了解决上述问题，从而衍生出Tachyon技术。

Tachyon的主要设计目的是分离Spark的计算功能和内存管理功能，使内存管理脱离JVM，专门设计Tachyon在JVM外管理内存数据。这样不仅解决了Spark在数据共享、缓存数据丢失情况下效率较低的问题，还能减少JVM因为数据量过多导致经常的GC垃圾收集，有效地提升了Spark的计算效率。从另一个角度看，在Spark计算框架和基于磁盘的HDFS之间Tachyon可看成是内存与硬盘之间的缓存，以有效地提升数据读取速度。

7.Mesos

Mesos是一个集群管理器，与YARN功能类似，提供跨分布式应用或框架的资源隔离与共享，可在其上运行Hadoop、Hypertable（一种类似Google公司Bigtable的数据库）、Spark。Mesos使用分布式应用程序协调服务Zookeeper实现容错，同时利用Linux的容器隔离任务，支持不同的资源分配计划。

8.YARN

YARN（Yet Another Resource Negotiator）最初是为Hadoop生态设计的资源管理器，能在其上运行Hadoop、Hive、pig（pig是一种基于Hadoop平台的高级过程语言）、Spark等应用框架。在Spark使用方面，YARN与Mesos很大的不同是Mesos是AMPlab开发的资源管理器，对Spark的支持力度很大，但国内的主流仍是YARN，主要是YARN对Hadoop生态系统的适用性更好。

9.BlinkDB

BlinkDB是一个用于在海量数据上运行交互式SQL近似查询的大规模并行查询引擎。它允许用户在查询结果精度和时间上作出权衡，其数据的精度被控制在允许的误差范围内。BlinkDB达到这样目标的两个核心思想，一是提供一个自适应优化框架，从原始数据随着时间的推移建立并维护一组多维样本，二是使用一个动态样本选择策略，选择一个适当大小的示例，基于查询的准确性和响应时间来实现需求。