Spark系列1：开篇之组件云集

引言

Spark的生态系统如图1.1所示，作为开源的分布式计算框架，Spark主要包括Spark Core和在Spark Core基础之上建立的应用框架Spark SQL、Spark Streaming、MLlib和GraphX。图1.1的生态系统被AMPlab称为伯克利数据分析栈，下边对其中主要组件进行简单介绍。

图1.1 Spark生态系统

Spark SQL在设计之初是为了将Hive数据仓库移植到Spark平台（对Shark的优化），为了避免过于依赖HIve，Spark SQL仅依赖于HQL Parser、HIve metostore和Hive SerDe，由Hive解析器生成语法树，之后的查询过程有Spark计算框架完成。

在Spark1.3开始支持DataFrames，使得Spark SQL能够充当分布式SQL查询引擎，后续笔者会对其进行详细介绍。

作为Spark的流处理框架（准流处理），Spark Streaming具有可扩展性、高吞吐量和可容错性等特点，Spark Streaming输入的数据来源可以是Kafka、Flume、Twitter、ZeroMQ、Kinesis等消息系统，也可是是传统TCP传输的原始数据，经过Spark一些列算子（类似于批处理算子）处理以后，最终将结果存储到文件系统、数据库或者实时监控界面中。如图1.2所示：

图1.2  Spark Streaming的输入与输出

GraphX是基于Spark的上层分布式图计算框架，主要处理社交网站等节点和边模型的问题，因为Spark能很好支持迭代计算，处理效率非常高，目前国内淘宝在图计算方面的应用较多，后续笔者会展开进行详细讨论。

作为Spark在机器学习领域的重要应用，MLlib实现了逻辑回归、SVM、随机森林、K-means、奇异值分解等多种机器学习算法，充分发挥Spark在迭代计算上的优势，比传统的MapReduce模型要快一百倍以上，能对大规模的数据应用机器学习模型，能让机器学习算法在基于大数据的预测、推荐和模式识别等方面应用广泛。

在过去的Spark基于内存的计算的模式中往往所存在以下几个问题：

• 当两个Spark作业需要共享数据时，必须通过写磁盘操作。比如：作业1要先把生成的数据写入HDFS，然后作业2再从HDFS把数据读出来。在此，磁盘的读写可能造成性能瓶颈。

• 由于Spark会利用自身的JVM对数据进行缓存，当Spark程序崩溃时，JVM进程退出，所缓存数据也随之丢失，因此在工作重启时又需要从HDFS把数据再次读出。

• 当两个Spark作业需操作相同的数据时，每个作业的JVM都需要缓存一份数据，不但造成资源浪费，也极易引发频繁的垃圾收集，造成性能的降低。

为了解决上述问题，Tachyon诞生了，Tachyon设计的主要目的是将计算功能与内存管理功能分离，使内存管理脱离JVM，这样的设计能提升Spark的计算效率。后续笔者会对Tachyon的原理进行详细的分析。