重学Spark之RDD

Biu_
1,038 阅读10分钟

什么是RDD？

RDD（Resilient Distributed Dataset）叫做弹性分布式数据集，是Spark中最基本的数据抽象，它代表一个不可变、可分区、里面的元素可并行计算的集合。

Spark的惰性机制

RDD将操作分为两类：transformation与action。无论执行了多少次transformation操作，RDD都不会真正执行运算，只有当action操作被执行时，运算才会触发。
正是因为懒惰执行，spark才能更有效的运行于于内存，使得高效的共享内存机制避免了大量中间结果，从而避免了磁盘写入写出带来的性能消耗，同时内部的存储对象可以是JAVA对象也避免了不必要的序列化和反序列化。

宽依赖和窄依赖

窄依赖：是指每个父RDD的一个Partition最多被子RDD的一个Partition所使用，例如map、filter、union等操作都会产生窄依赖；（不会产生shuffle）
窄依赖可以分为两种情况：
  • 1个子RDD的分区对应于1个父RDD的分区，比如map，filter，union等算子
  • 1个子RDD的分区对应于N个父RDD的分区，比如co-partioned join

宽依赖：是指一个父RDD的Partition会被多个子RDD的Partition所使用，例如groupByKey、reduceByKey、sortByKey等操作都会产生宽依赖；（会产生shuffle）
宽依赖可以分为两种情况：
  • 1个父RDD对应非全部多个子RDD分区，比如groupByKey，reduceByKey，sortByKey等算子
  • 1个父RDD对应所有子RDD分区，比如未经协同划分的join

RDD运行原理

  1. 创建 RDD 对象，提交之后根据RDD的依赖关系构建DAG图，DAG图提交给DAGScheduler进行解析。
  2. DAGScheduler是面向调度阶段的高层次调度器，DAGScheduler把DAG拆分成相互依赖的调度阶段，拆分调度阶段是以RDD的依赖是否为宽依赖，当遇到宽依赖就划分为新的调度阶段。每个调度阶段包含一个或者多个任务，这些任务形成任务集合，提交给底层TaskScheduler进行调度运行。另外DAGScheduler还记录了哪些RDD被存入磁盘等物化动作，同时寻求任务的最优调度优化，列如数据本地型。DAGScheduler还监控运行调度过程，如果某个调度阶段运行失败，则需要重新提交该调度阶段。
  3. 每个TaskScheduler只为一个SparkContext实例服务，TaskScheduler接受来自DAGScheduler发送过来的任务集合，TaskScheduler收到任务集合之后就把该任务集合以任务的形式一个一个方法到Worker节点中运行，如果某个任务运行失败，TaskScheduler要负责重试。如果TaskScheduler发现某个任务一直未运行完成，就可能启动同样的任务运行同样的一个任务，哪个任务先运行完成就用哪个任务的结果。
  4. Worke中的Executor收到TaskScheduler发送过来的任务之后，以多线程的方式进行运行，每一个线程负责一个任务。任务结束之后要返回结果给TaskScheduler，不同的类型任务返回 的结果不同。ShuffleMapTask返回的是一个MapStatus对象，而不是结果本身；ResultTask根据结果大小的不同，返回的方式不同。

DAG

在spark中，会根据RDD之间的依赖关系将DAG图（有向无环图）划分为不同的阶段，对于窄依赖，由于partition依赖关系的确定性，partition的转换处理就可以在同一个线程里完成，窄依赖就被spark划分到同一个stage中，而对于宽依赖，只能等父RDD shuffle处理完成后，下一个stage才能开始接下来的计算。

因此spark划分stage的整体思路是：从后往前推，遇到宽依赖就断开，划分为一个stage；遇到窄依赖就将这个RDD加入该stage中。因此在图2中RDD C,RDD D,RDD E,RDD F被构建在一个stage中,RDD A被构建在一个单独的Stage中,而RDD B和RDD G又被构建在同一个stage中。
这种分发方式可以使不同分区实现不同的流水线操作，有利于高效的运行与容错机制，想象一下，当运行时当C1-->D1运行结束时候，就可以直接运行D1-->F1的操作了，这样进行的并行计算有效的提升了计算性能。同时当出现错误时候，良好的stage划分也减少了重新计算所带来的成本。

Partition

partition（分区）是 Spark 中的重要概念，它是RDD的最小单元，RDD是由分布在各个节点上的partition 组成的。partition的数量决定了task的数量，每个task对应着一个partition。
例如，使用 Spark 来读取本地文本文件内容，读取完后，这些内容将会被分成多个partition，这些partition就组成了一个RDD，同时这些partition可以分散到不同的机器上执行。
Partition 数量的影响：
  • 如果 partition 数量太少，则直接影响是计算资源不能被充分利用。例如分配 8 个核，但 partition 数量为 4，则将有一半的核没有利用到。
  • 如果 partition 数量太多，计算资源能够充分利用，但会导致 task 数量过多，而 task 数量过多会影响执行效率，主要是 task 在序列化和网络传输过程带来较大的时间开销。

RDD持久化

Spark非常重要的一个功能特性就是可以将RDD持久化在内存中。当对RDD执行持久化操作时，每个节点都会将自己操作的RDD的partition持久化到内存中，并且在之后对该RDD的反复使用中，直接使用内存缓存的partition。这样的话，对于针对一个RDD反复执行多个操作的场景，就只要对RDD计算一次即可，后面直接使用该RDD，而不需要反复计算多次该RDD。
  • 要持久化一个RDD，只要调用其cache()或者persist()方法即可。在该RDD第一次被计算出来时，就会直接缓存在每个节点中。而且Spark的持久化机制还是自动容错的，如果持久化的RDD的任何partition丢失了，那么Spark会自动通过其源RDD，使用transformation操作重新计算该partition。
  • cache()和persist()的区别在于，cache()是persist()的一种简化方式，cache()的底层就是调用的persist()的无参版本，同时就是调用persist(MEMORY_ONLY)，将数据持久化到内存中。如果需要从内存中清楚缓存，那么可以使用unpersist()方法。
  • Spark自己也会在shuffle操作时，进行数据的持久化，比如写入磁盘，主要是为了在节点失败时，避免需要重新计算整个过程。

RDD持久化策略

RDD持久化是可以手动选择不同的策略的。比如可以将RDD持久化在内存中、持久化到磁盘上、使用序列化的方式持久化，多持久化的数据进行多路复用。只要在调用persist()时传入对应的StorageLevel即可。

对于内存使用LRU回收算法来进行管理，当计算得到一个新的RDD分区，但没有足够空间来存储时，系统会从最近最少使用的RDD回收其一个分区的空间。
除非该RDD是新分区对应的RDD，这种情况下Spark会将旧的分区继续保留在内存中，防止同一个RDD的分区被循环调入/调出。
如何选择RDD持久化策略？
  1. 默认情况下，性能最高的当然是MEMORY_ONLY，但前提是内存必须足够足够大，可以绰绰有余地存放下整个RDD的所有数据。因为不进行序列化与反序列化操作，就避免了这部分的性能开销；对这个RDD的后续算子操作，都是基于纯内存中的数据的操作，不需要从磁盘文件中读取数据，性能也很高；而且不需要复制一份数据副本，并远程传送到其他节点上。但是这里必须要注意的是，在实际的生产环境中，恐怕能够直接用这种策略的场景还是有限的，如果RDD中数据比较多时（比如几十亿），直接用这种持久化级别，会导致JVM的OOM内存溢出异常。
  2. 如果使用MEMORY_ONLY级别时发生了内存溢出，那么建议尝试使用MEMORY_ONLY_SER级别。该级别会将RDD数据序列化后再保存在内存中，此时每个partition仅仅是一个字节数组而已，大大减少了对象数量，并降低了内存占用。这种级别比MEMORY_ONLY多出来的性能开销，主要就是序列化与反序列化的开销。但是后续算子可以基于纯内存进行操作，因此性能总体还是比较高的。此外，可能发生的问题同上，如果RDD中的数据量过多的话，还是可能会导致OOM内存溢出的异常。
  3. 如果纯内存的级别都无法使用，那么建议使用MEMORY_AND_DISK_SER策略，而不是MEMORY_AND_DISK策略。因为既然到了这一步，就说明RDD的数据量很大，内存无法完全放下。序列化后的数据比较少，可以节省内存和磁盘的空间开销。同时该策略会优先尽量尝试将数据缓存在内存中，内存缓存不下才会写入磁盘。
  4. 通常不建议使用DISK_ONLY和后缀为_2的级别：因为完全基于磁盘文件进行数据的读写，会导致性能急剧降低，有时还不如重新计算一次所有RDD。后缀为_2的级别，必须将所有数据都复制一份副本，并发送到其他节点上，数据复制以及网络传输会导致较大的性能开销，除非是要求作业的高可用性，否则不建议使用。

Checkpoint机制

当RDD使用cache机制从内存中读取数据，如果数据没有读到，会使用checkpoint机制读取数据。此时如果没有checkpoint机制，那么就需要找到父RDD重新计算数据了，因此checkpoint是个很重要的容错机制。
val data = sc.textFile("/tmp/spark/1.data").cache() // 注意要cache 
sc.setCheckpointDir("/tmp/spark/checkpoint")
data.checkpoint 
data.count

checkpoint 写流程

RDD checkpoint 过程中会经过以下几个状态：
[ Initialized –> marked for checkpointing –> checkpointing in progress –> checkpointed ]
  • 首先 driver program 需要使用 rdd.checkpoint() 去设定哪些 rdd 需要 checkpoint，设定后，该 rdd 就接受 RDDCheckpointData 管理。用户还要设定 checkpoint 的存储路径，一般在 HDFS 上。
  • marked for checkpointing：初始化后，RDDCheckpointData 会将 rdd 标记为 MarkedForCheckpoint。
  • checkpointing in progress：每个 job 运行结束后会调用 finalRdd.doCheckpoint()，finalRdd 会顺着 computing chain 回溯扫描，碰到要 checkpoint 的 RDD 就将其标记为 CheckpointingInProgress，然后将写磁盘（比如写 HDFS）需要的配置文件（如 core-site.xml 等）broadcast 到其他 worker 节点上的 blockManager。完成以后，启动一个 job 来完成 checkpoint（使用 rdd.context.runJob(rdd, CheckpointRDD.writeToFile(path.toString, broadcastedConf))）。
  • checkpointed：job 完成 checkpoint 后，将该 rdd 的 dependency 全部清掉，并设定该 rdd 状态为 checkpointed。然后，为该 rdd 强加一个依赖，设置该 rdd 的 parent rdd 为 CheckpointRDD，该 CheckpointRDD 负责以后读取在文件系统上的 checkpoint 文件，生成该 rdd 的 partition。

checkpoint 读流程

  • 如果 一个 RDD 被checkpoint了， 那么这个 RDD 中对分区和依赖的处理都是使用的 RDD 内部的 checkpointRDD 变量， 具体实现是 ReliableCheckpointRDD 类型。 这个是在 checkpoint 写流程中创建的。依赖和获取分区方法中先判断是否已经checkpoint， 如果已经checkpoint了， 就斩断依赖， 使用ReliableCheckpointRDD， 来处理依赖和获取分区。
  • 如果没有，才往前回溯依赖。 依赖就是没有依赖， 因为已经斩断了依赖， 获取分区数据就是读取 checkpoint 到 hdfs目录中不同分区保存下来的文件。
在以下两种情况下，RDD需要加检查点。
  1. DAG中的Lineage过长，如果重算，则开销太大（如在PageRank中）。
  2. 在宽依赖上做Checkpoint获得的收益更大。
avatar
文章
阅读
粉丝