大数据处理框架
集群环境对于编程来说带来了很多挑战，首先就是并行化：这就要求我们以并行化的方式重写应用程序，以便我们可以利用更大范围节点的计算能力。集群环境的第二个挑战就是对单点失败的处理，节点宕机以及个别节点计算缓慢在集群环境中非常普遍，这会极大地影响程序的性能。最后一个挑战是集群在大多数情况下都会被多个用户分享，那么动态地进行计算资源的分配，也会干扰程序的执行。因此，针对集群环境出现了大量的大数据编程框架。首先我们要提到的就是Google的MapReduce，它给我们展示了一个简单通用和自动容错的批处理计算模型。
但是对于其他类型的计算，比如交互式和流式计算，MapReduce并不适合，这也导致了大量的不同于MapReduce的专有的数据处理模型的出现，比如Storm、Impala和GraphLab。随着新模型的不断出现，似乎对于大数据处理而言，我们应对不同类型的作业需要一系列不同的处理框架才能很好地完成。但是这些专有系统也有一些不足。
- 重复工作：许多专有系统在解决同样的问题，比如分布式作业以及容错。举例来说，一个分布式的SQL引擎或者一个机器学习系统都需要实现并行聚合。这些问题在每个专有系统中会重复地被解决。
- 组合问题：在不同的系统之间进行组合计算是一件费力又不讨好的事情。对于特定的大数据应用程序而言，中间数据集是非常大的，而且移动的成本也非常高昂。在目前的环境中，我们需要将数据复制到稳定的存储系统中（比如HDFS），以便在不同的计算引擎中进行分享。然而，这样的复制可能比真正的计算所花费的代价要大，所以以流水线的形式将多个系统组合起来效率并不高。
- 适用范围的局限性：如果一个应用不适合一个专有的计算系统，那么使用者只能换一个系统，或者重写一个新的计算系统。
- 资源分配：在不同的计算引擎之间进行资源的动态共享是比较困难的，因为大多数的计算引擎都会假设它们在程序运行结束之前拥有相同的机器节点的资源。
- 管理问题：对于多个专有系统，需要花费更多的精力和时间来管理和部署。
尤其是对于终端使用者而言，他们需要学习多种API和系统模型。
Spark
针对MapReduce及各种专有系统中出现的不足，伯克利大学推出了全新的统一大数据处理框架Spark，创新性地提出了RDD概念（一种新的抽象的弹性数据集），在某种程度上Spark是对MapReduce模型的一种扩展。要在MapReduce上实现其不擅长的计算工作（比如迭代式、交互式和流式），看上去是一件非常困难的事情，其实主要的原因是MapReduce缺乏一种特性，即在并行计算的各个阶段进行有效的数据共享，这种共享就是RDD的本质。利用这种有效的数据共享和类似MapReduce的操作接口，上述的各种专有类型计算都能够有效地表达，而且能够获得与专有系统同等的性能。
特别值得一提的是，从前对于集群处理的容错方式，比如MapReduce和Dryad，是将计算构建成为一个有向无环图的任务集。而这只能允许它们有效地重新计算部分DAG。在单独的计算之间（在迭代的计算步骤之间），除了复制文件，这些模型没有提供其他的存储抽象，这就显著地增加了在网络之间复制文件的代价。RDD能够适应当前大部分的数据并行算法和编程模型。
RDD表达能力
可以使用RDD实现很多现有的集群编程模型以及一些以前的模型不支持的新应用。在这些模型中，RDD能够取得和专有系统同样的性能，还能提供包括容错处理、滞后节点（straggler node）处理等这些专有系统缺乏的特性。这里会重点讨论如下四类模型。
- 迭代算法：这是目前专有系统实现的非常普遍的一种应用场景，比如迭代算法可以用于图处理和机器学习。RDD能够很好地实现这些模型，包括Pregel、HaLoop和GraphLab等模型。
- 关系型查询：对于MapReduce来说非常重要的需求就是运行SQL查询，包括长期运行、数小时的批处理作业和交互式的查询。然而对于MapReduce而言，对比并行数据库进行交互式查询，有其内在的缺点，比如由于其容错的模型而导致速度很慢。利用RDD模型，可以通过实现许多通用的数据库引擎特性，从而获得非常好的性能。
- MapReduce 批处理：RDD提供的接口是MapReduce的超集，所以RDD可以有效地运行利用MapReduce实现的应用程序，另外RDD还适合更加抽象的基于DAG的应用程序，比如DryadLINQ。
- 流式处理：目前的流式系统也只提供了有限的容错处理，需要消耗系统非常大的拷贝代价或者非常长的容错时间。特别是在目前的系统中，基本都是基于连续计算的模型，常驻的有状态的操作会处理到达的每一条记录。为了恢复失败的节点，它们需要为每一个操作复制两份操作，或者是将上游的数据进行代价非常大的操作重放。利用RDD实现一种新的模型——离散数据流（D-Stream），可以克服上面的这些问题。D-Stream将流式计算当作一系列的短小而确定的批处理操作，而不是常驻的有状态的操作，将两个离散流之间的状态保存在RDD中。离散流模型能够允许通过RDD的继承关系图（lineage）进行并行性的恢复而不需要进行数据拷贝。
Spark子系统
如果按照目前流行的大数据处理场景来划分，可以将大数据处理分为如下三种情况。
- 复杂的批量数据处理（batch data processing），通常的时间跨度为数十分钟到数小时。
- 基于历史数据的交互式查询（interactive query），通常的时间跨度为数十秒到数分钟。
- 基于实时数据流的数据处理（streaming data processing），通常的时间跨度为数百毫秒到数秒。
由于RDD具有丰富的表达能力，所以伯克利在Spark Core的基础之上衍生出了能够同时处理上述三种情形的统一大数据处理平台，如图1-1所示。
- Spark Core：基于RDD提供了丰富的操作接口，利用DAG进行统一的任务规划，使得Spark能够更加灵活地处理类似MapReduce的批处理作业。
- Shark/Spark SQL:兼容Hive的接口HQL，提供了比Hive高出10~100倍的查询速度的分布式SQL引擎。
- Spark Streaming：将流式计算分解成一系列的短小的批处理作业，利用Spark轻量级和低延时的调度框架，可以很好的支持流式处理。目前已经支持的数据输入源包括Kafka、Flume、Twitter、TCP sockets。
- GraphX：基于Spark的图计算框架，兼容Pregel和GraphLab接口，增强了图构建以及图转换功能。
- MLlib:Spark Core 天然地非常适合于迭代式运算，MLlib就是构建在Spark上的机器学习算法库。目前已经可以支持常用的分类算法、聚类算法、推荐算法等。
Spark生态系统的目标就是将批处理、交互式处理、流式处理融合到同一个软件栈中。对于最终的用户或者是开发者而言，Spark生态系统有如下特性。 - Spark生态系统兼容Hadoop生态系统。这个特性对于最终用户至关重要，虽然Spark 通用引擎在一定程度上是用来取代MapReduce系统的，但是Spark能够完美兼容Hadoop生态中的HDFS和YARN等其他组件，使得现有的Hadoop用户能够非常容易地迁移到Spark系统中。图1-2显示了Spark与Hadoop生态的兼容性。
- Spark生态系统学习成本很低。要实现一个相对完整的端到端解决方案，以前需要部署维护多个专有系统，现在只需要一个Spark系统。另外，如果开发者对Spark Core的原理有比较深入的理解，对构架在Spark Core之上的其他组件的运用将会非常容易。图1-3对比了Spark生态和其他大数据专有系统的代码量。在图1-3中的Spark一项中，批处理对应Spark Core，交互式处理对应Shark/Spark SQL，流计算对应Spark Streaming，而图计算对应GraphX。
- Spark 性能表现优异。由于Spark利用DAG进行调度执行规划，所以在多任务计算以及迭代计算中能够大量减少磁盘I/O的时间。另外，对于每一项任务启动一个线程，而不是启动一个进程，大大缩短了任务启动时间。
- Spark有强大的社区支持。Spark近一年多来保持非常迅猛的发展势头，被誉为大数据处理的未来。Spark的创始团队成立了Databricks公司，全力支持Spark 生态的发展。目前Hadoop商业版本发行公司中，已经有Cloudera、Hortonworks、MapR等公司相继宣布支持Spark软件栈。图1-4显示了Spark不同版本发布时对社区做出贡献的贡献者数量变化情况。
- Spark 支持多种语言编程接口。Spark生态本身是使用Scala语言编写的，但是考虑到其流行性，因此Spark从一开始就支持Java和Python接口，方便Spark 程序开发者自由选择。