spark性能如何监控 spark 性能

1.简介

Apache Spark是一个快速、通用的大数据处理引擎。下面介绍一下Spark的几个特点。

• 运行速度：相比于Hadoop的MapReduce，基于内存时要快100倍左右，基于磁盘是也要快10倍左右。
• 易用性：Spark提供了超过80多种高级操作，使得构建并行操作变得简单。可以使用Java、Scala、Python或者R语言快速编写Spark程序。
• 通用性：Spark提供了一系列库，包含SQL、Streaming（流处理）、MLlib（机器学习）和GraphX（图计算）。你可以在应用中融合以上所有库。
• 适用性：Spark程序可以运行在Hadoop、Mesos、standalone或者云上。它还可以访问存储在HDFS、Cassandra、HBase和S3中的数据。

2.背景

    过去多年中，新的数据源和数据设备正在迅速产生大量的信息，单台机器的处理能力和I/O性能并不能赶上数据的增长，越来越多的机构将计算扩展到集群中，但集群给编程带来了很多挑战。

• 并行化：集群要求我们以并行化的方式重写应用程序，以便利用更大范围节点的计算能力。
• 对单节点失败的处理：节点宕机以及个别节点计算缓慢在集群环境中非常普遍，这会极大的影响程序性能。
• 集群在多数情况下会被多个用户分享，如何动态的进行计算资源的分配，也会干扰程序的执行。

    应运而生的Google的MapReduce给我们展示了一个简单通用和自动容错的批处理计算模型，但它并不适合于迭代式、交互式和流计算等。因此又产生了不同于MapReduce的专有的数据处理模型，如Storm、Impala、GraphLab。为了应对不同类型的作业，需要一系列不同的处理框架才能很好的完成。但这些专有系统也有一些不足。

• 重复工作：同样的问题在许多专有系统中被重复解决，比如分布式作业和容错，不能重用。
• 组合问题：在不同的系统之间进行组合计算是一件费力不讨好的事情。一些情况下中间数据集非常大，移动成本很高，需要复制到稳定的存储系统中，以便在不同的计算引擎中共享，然而这样的代价可能比计算本身还要大。
• 适用范围局限性：如果一个应用不适合一个专有计算系统，那么使用者只能选择更换应用系统或者计算系统。
• 资源分配：在不同计算引擎之间进行资源的动态共享是比较困难的，因为大多数计算引擎都会假设它们在程序运行结束之前拥有相同的机器节点的资源。
• 管理问题：对于多个专有系统，需要花费更多精力和时间来管理和部署，终端使用者需要学习多种API和系统模型。

    针对MapReduce和专有系统的不足，伯克利大学退出了全新的统一大数据处理框架Spark，创新性的提出了RDD概念（一种新的抽象的弹性数据集），某种程度上是对MapReduce模型的一种扩展。MapReduce不适合于迭代式、交互式和流处理，其主要原因是缺乏一种特性，即在并行计算的各个阶段进行有效的数据共享，这种共享就是RDD的本质。

    以前对于集群处理的容错方式是将计算构建成为一个有向无环图的任务集。而这只能允许它们有效的重新计算部分DAG。在单独的计算之间（在迭代的计算步骤之间），除了复制文件，这些模型没有提供其他的存储抽象，这就显著的增加了在网络之间复制文件的代价。RDD能够适应当前大部分的数据并行算法和编程模型。这里重点列出如下四类模型。

• 迭代算法：这是目前专有系统实现的非常普遍的一种应用场景，比如迭代算法可以用于图处理和机器学习。RDD能够很好的实现这些模型，包括Pregel、HaLoop和GraphLab等。
• 关系型查询：对于MapReduce而言，对比并行数据库进行交互式查询，有其内在的缺点，比如由于其容错的模型而导致速度很慢。利用RDD模型，可以通过实现许多通用的数据库引擎特性，从而获得非常好的性能。
• MapReduce批处理：RDD提供的接口是MapReduce的超集，可以有效的运行利用MapReduce实现的应用程序，另外RDD还适合更加抽象的基于DAG的应用程序，比如DryadLINQ。
• 流式处理：目前的流式系统也只提供了有限的容错处理，需要消耗系统非常大的拷贝代价或者非常长的容错时间。特别是在目前的系统中，基本都是基于连续计算的模型，常驻的有状态的操作会处理到达的每一条记录。为了恢复失败的节点，它们需要为每一个操作复制两份操作，或者将上游的数据进行代价非常大的操作重放。利用RDD实现一种新的模型——离散数据流（D-Stream），可以克服上面的问题。D-Stream将流式计算当做一系列的短小而确定的批处理操作，而不是常驻的有状态的操作，将两个离散流之间的状态保存到RDD中。离散流模型能够允许通过RDD的继承关系图（lineage）进行并行性的恢复而不需要进行数据拷贝。