1月24日，一场基于Spark和Redis组成的分布式系统实践分享由Spark资深布道者陈超和豌豆荚资深系统架构师刘奇联手打造。 陈超：Spark Ecosystem & Internals 陈超（@CrazyJvm），Spark布道者 在分享中，陈超首先简短的介绍了Spark社区在2014年的发展：目前Spark的发布版本是1.2，整个2014年Spark共发布了3个主要版本——1.0、1.1、1.2。随后，陈超对Spark生态圈进行了详细的分析： Spark：What & Why？Spark是一个非常快，并且普适性非常强的一个大数据处理引擎。谈到Spark，首先就是一些常见特性：速度快、易用、通用和兼容Hadoop。首先通用，Spark可以支撑批处理、流计算、图计算、机器学习等众多应用场景；其次，与Hadoop良好的兼容。鉴于大多数的企业仍选用HDFS来存数据，Spark的设计与HDFS有着非常好的兼容性——假如数据存储在HDFS，那么不做任何数据迁移工作就可以直接使用Spark。 Spark vs. Hadoop
对于为什么要选择Spark，如上图所示，陈超从迭代计算和HDFS同批数据的多维度查询两个方面将之与Hadoop进行了对比：
而在这两种场景中，Spark可以使用内存缓存中间/常用数据，从而在避免磁盘IO开销的同时，还将大幅度提高性能。 Why Spark is so Fast？ Spark一直以快速著称，那么除下之前所说的内存，又是什么特性让Spark可以如此之快？在这里，陈超提到了DAG（有向无环图，下文详细介绍）、Thread Model（线程模型）和Optimization（比如延迟调度）3个方面。 Thread Model。Hadoop基于进程模型，每次启动一个task都需要新启动一个子JVM进行计算，可能也会存在JVM Reuse，这里即使避开JVM Reuse中存在的问题不谈，每次JVM启动时已经造成了不菲的开销。而Spark在应用程序启动时就启动了线程池，所以任务的启动开销非常小。 Optimization——延迟调度。当任务下达到某台主机时，恰好该主机的计算资源（CPU、内存等）已被耗尽，这个时候，Spark会采用延迟调度的机制，让其等待一小会，而不是将该台主机上需要计算的数据通过网络传输到另外的主机上。使用这个机制，在计算数据体积非常大时，有着很大的优势。 也就是所谓的“让计算跟着数据走，而不是数据跟着计算走”。 Spark解析伯克利数据分析协议栈
其中包括：资源管理框架，Apache YARN、Apache Mesos；基于内存的分布式文件系统，Tachyon；随后是Spark，更上面则是实现各种功能的系统，比如机器学习MLlib库，图计算GraphX，流计算Spark Streaming。再上面比如：SparkR，分析师的最爱；BlinkDB，我们可以强迫它几秒钟内给我们查询结果。 正是这个生态圈，让Spark可以实现“one stack to rule them all”，它既可以完成批处理也可以从事流计算，从而避免了去实现两份逻辑代码。而整个Spark的理论基础就是RDD： RDD的核心理念 RDD可以想象为一个个的partitions，退一步也可理解为一个非常大的List(1,2,....9)，使用3个Partion分别保存这个List的3个元素，而每个partition（或者split）都会有一个函数去计算。同时，RDD之间是可以相互依赖的。然后，可以为Key-value RDD指定partitioner, RDD中的每个split也都有各自的preferred location。 最后一个preferred locations，这个理念存在于当下的众多分布式系统中，也就是计算跟着数据走。通常情况下，转移计算的时间远远小于转移数据的时间。对于Hadoop来说，因为数据在磁盘中，磁盘本地性通常达到了顶峰，而对于Spark来讲，因为数据（可以）保存在内存中，所以内存本地性才具备最高优先级。 |
