Spark:分布式容错的内存计算框架
Resilient Distributed Datasets: A Fault-Tolerant Abstraction forIn-Memory Cluster Computing
Spark是目前大数据领域较为火热的批处理框架之一（也支持流处理），经过论文阅读，不难发现Spark的核心原理并不复杂，通过简单的抽象，有效的解决了内存计算问题，我想这就是Spark流行起来的原因之一，如果要理解Spark，最关键一步的是理解RDD这一抽象内存模型。
RDDs（Resilient Distributed Datasets）
Spark中将计算操作的基本内存数据单元抽象为一个只读、分区的数据集-弹性分布数据集（RDD），将一次Spark任务定义为RDD经过一系列操作不断变换状态的过程，如下图所示：
- 每一步操作将一个RDD转化为另一个逻辑上的RDD（例如map、filter、join等）
- 不同RDD之间通过操作链接起来，形成一个RDD转换父子关系链
- Spark通过记录RDD转化的父子关系以及操作类型，实现容错（在RDD丢失后，根据计算链重新计算）
系统中通过五个元信息定义一个RDD：一系列分区、一系列父RDD依赖、转化操作、元数据（分区放置、分区信息），依赖关系如下图，分为一对一（narrow）和多对一（wide）。
与其他分布式内存数据存储（kv数据库）的区别在于：
- RDD在状态变更逻辑上更加”粗“（Coarse-grained），执行的操作一般是对于RDD中所有元素执行的统一操作（如：过滤特定单词、计数）
- 如KV内存数据库等状态变更逻辑上粒度更加”细“（Fine-grained），执行操作一般是修改某一个表项或者某一个键值
RDD的“粗”来自于批处理任务的特点，也为Spark带来了许多优势：
- 批处理实际上就是一批数据执行某种操作到另一种批数据的过程，这与RDD变换的逻辑是一致的
- RDD理论上不需要checkpoint机制进行容错，可以通过记录RDD变换操作，在特定RDD丢失后，直接重新计算获得丢失RDD
- 另外由于RDD的隔离性（计算并不修改RDD，而是生成RDD），可以通过复制RDD到其他机器解决“stragglers”问题
在了解过RDD以后，心里不由自如的冒出这么个想法：在批处理环境下内存编程模型就应该是这样，简单且有效；然而想出从批处理->抽象模型这一步是真的太难。
Spark实现
论文中简单介绍了基于RDD模型实现的Spark框架，省略了许多实现细节，且由于论文发表较早，其描述的实现机制肯定与目前Spark内部细节还是有较大差异，简单理解即可，基本框架图如下：
- 对于每个Spark程序，采用一个Driver进程+多个Worker进程的实现方式。
- Driver负责追踪RDD计算链（RDDs’ lineage）
- Worker负责执行计算、在内存中存储RDD
RDD被实现为由元素类型决定的静态类型对象（如RDD[int]），支持的一系列transformation和action操作：
- transformation操作包括map、reduceByKey等，采用“懒执行”机制，即不真正执行，只是记录操作、定义新RDD
- action操作包括count、collect等，直接执行，返回给用户结果
Spark中任务的执行通过一个中心调度器（scheduler），进行任务分配和RDD分区
- 当执行action类型操作时，scheduler构建DAG图，并划分stage
- 按照传输计算不传输数据的元组，尽量按照数据分布分配计算任务（例如具有依赖关系的父子RDD partition分布在一台机器上）
Checkpointing-wide dependency容错
当存在wide dependency的子RDD失效时（例如Page Rank中distinct() rdd结果丢失），由于其依赖于所有的上层RDD，所以需要重新在所有依赖的父RDD上重新执行相同操作，此类型错误恢复执行的成本过高。
Spark提供API支持Checkpointing机制持久化RDD,但是Spark将持久化的时机交给用户决定，由用户主动调用持久化API进行Checkpointing
总结
Spark实际上就是将maprudce模型迁移到内存中，降低了任务中间结果输入输出的IO成本，其适用于例如pagerank、逻辑回归等的需要进行迭代计算的任务（中间结果不重要），如果将类似任务在mapreduce做，每一次迭代相当于一个mapreduce任务。Spark使用的RDD模型同样存在以下局限：
- 不合适处理数据状态局部更新的应用（web site interactions, 增量采集数据的网络爬虫）
- 不支持处理流式数据