Spark论文思想之-总结

6 总结

新世纪的大数据计算平台应该是什么样子的？
　　论文当中给出了一个概念：对计算的简单抽象，对数据进行粗粒度批处理同时提供高效数据共享，可以在广泛的工作负载中表现出色的性能，并对现存处理系统取得实质的进步。
　　Spark引擎是轻量级的，基于Spark引擎实现的其它模型也很小。在大数据集群计算的困难部分（容错、调度、多租户），这种小而通用抽象更能适应需求的快速变化。
　　可以看出，集群应用在朝着复杂化的方向发展，不同计算方式、处理模式的联合被迫切需要。（如机器学习和SQL的联合，交互处理与流式处理模式的联合等）。这些需要在各自领域都有可胜任的专业的处理系统，而且性能出众。但要想将这些各尽其职的系统进行联合，代价很庞大，原因在于系统之间的数据的共享上。这里我们就不再赘述基于RDD的系统是怎么解决这些问题的了，更值得我们关注的应该是一个出色的大数据处理系统所面对的挑战与难题。诸如高效数据共享、容错、延迟、计算类型与处理模式各自的联合、处理粒度、多租户等等。

6.1 需要get的内容

  数据共享的重要性：在计算机的发展过程中，网络带宽、存储带宽和CPU强大的计算能力之间依然存在很大差距。这使得数据共享方式极大地影响着分布式应用的响应能力。大部分系统主要侧重于启用特定的数据流模式，而RDD使数据集成为一流原语，并为用户提供足够的机制来控制其属性（分区及持久化等），通过控制这些属性最大限度地优化瓶颈资源，以此提高计算性能，同时保持接口足够抽象以自动提供容错。

  单一应用在数据共享设置下的性能评估：真实的部署其实都是更复杂的，比如说先应用MapReduce进行解析，然后在结果上应用机器学习算法。其次，大部分的部署都是多个应用共享资源的，这就要求执行模型能够在资源动态共享、撤销、落后者缓解方面表现良好。否则，带来的就是响应能力差。
　　假定有个机器学习算法的实现，运用一个比Spark快5倍左右的执行模型来执行，例如MPI（这一系统需要提前分配空间）。这一专业系统在端到端的工作流负载中，比如先进行MapReduce解析数据，然后执行机器学习算法的专业系统，依然会很慢。因为这需要通过外部可靠存储来提供数据共享（比如MapReduce批处理将数据输出到HDFS上，然后机器学习算法加载数据进行算法训练）。而且，对于这种专业系统，需要提前分配固定空间，这对于多租户部署来讲，要么引发应用阻塞在队列，要么就是造成资源空间的浪费。这降低了多租户集群的响应，但是在集群层面上来讲，RDD是一种细粒度的执行模型，单一可在任一节点进行灵活执行，多任务可在多节点并行执行。
　　瓶颈优化：对于通用处理引擎的设计，通常是在瓶颈资源上下功夫。如果用户可以控制瓶颈资源优化，就可以带来更好的性能。在Cloudera发布Impala的时候，伯克利AMPLab实验室将其与Shark进行对比，发现它们在很多查询中表现的性能几乎一致，这是为什么呢？因为这些查询中的大多查询要么是I/O瓶颈的、要么是带宽瓶颈的，而这两个查询系统都最大限度利用了有限资源。
　　通用性也并不代表低级，如RDD通过让用户控制分区来优化网络利用率，这更多地是以共同模式（比如协分区）来实现这一点，而并不是要用户手动选择哪个数据在哪个机器上，因而也就带来了自动数据均衡和容错能力。
　　简单设计组成：构建于一系列核心接口之上，也是Spark和RDD如此通用的原因之一。在接口层面上，RDD只在窄依赖和宽依赖的两种转换类型之间进行区分。在执行过程中，数据通过简单标准的接口（数据记录的迭代器）进行数据传递，这允许不同数据格式及处理功能高效混合。为了进行任务调度，它们被映射为非常简单的模型（细粒度的、无状态的任务），大量的算法被开发出来用以提供公平的资源共享、数据本地性、落后者缓解以及执行的可扩展性。由于细粒度任务模型的简单性，这些调度算法本身也相互组合。

6.2 再谈局限

  通信延迟：为了保证计算的确定性，为每个时间步进行的同步带来了额外的延迟。官方工作方向的第一条主线是系统挑战，要看在内存集群计算系统的延迟究竟有多低。较新的数据中心网络可能有微秒级的延迟。对于优化的代码库，具有几毫秒的时间步延迟是合理的。（在当前的基于JVM的Spark系统中，运行时Java使得延迟更高）。工作方向的第二条主线：利用延迟隐藏技术，在RDD上，通过跨block来划分任务以及推测其它节点的响应来执行更严密地应用同步。

  新的通信模式：也就是讲，目前的RDD实现的是点对点的跨节点的shuffle通信模式。这是一种all-to-all的形式，自然会有I/O瓶颈等代价昂贵的开销。其它的通信模式或许也可以带来好处，如广播broadcast及all-to-one聚合。如果可以这么做，那么也可能为新的运行时优化以及容错方案创造条件。

  异步：基于RDD的计算是同步的并且是确定性的，同步是指时间步内map都完成后reduce任务才开始启动，上一篇文章提到过。但是并不是说RDD的异步计算是不可能的，相反，可以适合模型内的异步计算步骤，并保留计算之间的容错恢复保证。

  细粒度更新：RDD提供粗粒度的并行数据操作，但是用来进行细粒度的更新也是可能的，比如key-value存储的更新，通过将这些更新组合成批的形式。其所具有的运行时低延迟，或许会带来和传统数据库设计的惊喜比较。

  版本跟踪：RDD被定义成不可变数据集，意在使沿袭图依赖能够指向特定的版本，以便进行容错恢复。所以，这里有显著的空间在这一抽象下使用可变数据集并且使用更有效的版本追踪方案。

6.3 实际系统问题

• 调试：分布式系统有时候遇到问题很难调试，特别是作用于大的而且并不精确的数据集的时候。官方在探索的方法是通过RDD沿袭图信息对应用的部分（发生异常毁掉的任务、或者是仅执行图中产生特定输出的小部分）进行重放调试。相似的工具也可以在二次运行时修改沿袭图，例如：通过添加日志代码到用户函数或者参数记录来进行污点跟踪。

• 性能调试：性能调优通常要比准确性调试难的多，一部分原因来自于开发者并不清楚什么因素的调整能带来更好的性能，或者是对于怎样才算是最佳性能并没有一个好的直觉。诸如通信开销、不同数据形式带来的内存开销、数据倾斜等都会对并行应用产生显著影响。所以，能不能开发出个工具自动探测出低效性能、甚至能够监控程序执行并向用户展示足够的信息以识别问题？

• 调度策略：从集群的层面来讲，Spark应用中任务是细粒度的，这就使得RDD模型支持非常灵活的运行时任务放置。这一特性已经被用于实现诸如多租户资源共享等。但是，在多应用的情况下，怎么实现一个好的调度策略是一个挑战。比如，在一个Spark Streaming应用中有多个流，怎么强有力地保证优先级或者任务的最后期限。如果还需要在流上进行交互式查询又会怎么样？给定RDD或者D-Stream沿袭图，程序能否自行决定checkpoint哪个RDD或者D-Stream来最小化执行之间。应用是越来越复杂化的，用户对响应快的接口的需求越来越迫切。好的调度策略才能实现好的性能。

• 存储管理：前边讲到过，在集群环境中，如果给应用分配固定内存，要么会导致任务阻塞在队列、要么造成资源浪费。所以，给应用预先分配合适的固定内存是挑战巨大的，这和应用的优先级以及使用模式也有很大关系。同时，存储级别也是多样的，有内存存储、固态硬盘、机械硬盘等等。大多数情况下都是在速度和空间开销上进行取舍权衡。比如说在内存中压缩存储，需要额外的CPU时间来进行对象解压，这是一种额外开销，但是节省了内存空间。在RDD沿袭图下，某些RDD在需要时进行重计算可能更加高效，只需应用map函数到其父RDD上即可，计算又足够快，所以几乎不牺牲性能。一般来讲，经过昂贵操作得来的RDD总是需要复制存储。因为总是可以通过沿袭图重新计算丢失的数据，因此存储管理策略总是有很大空间。

  总之，当我们接触和使用大数据计算能力的时候，如果我们能够清晰的知道计算框架的优势和不足，那么在使用过程中就会更加得心应手。当我们知道这些挑战，并试图解决或者学习到解决这些挑战的方法的时候，自身也能取得一些进步。