Spark技术内幕:Storage 模块整体架构

Storage模块负责了Spark计算过程中所有的存储,包括基于Disk的和基于Memory的。用户在实际编程中,面对的是RDD,可以将RDD的数据通过调用org.apache.spark.rdd.RDD#cache将数据持久化;持久化的动作都是由Storage模块完成的。包括Shuffle过程中的数据,也都是由Storage模块管理的。可以说,RDD实现了用户的逻辑,而Storage则管理了用户的数据。本章将讲解Storage模块的实现。

1.1     模块整体架构

org.apache.spark.storage.BlockManager是Storage模块与其他模块交互最主要的类,它提供了读和写Block的接口。 这里的Block,实际上就对应了RDD中提到的partition,每一个partition都会对应一个Block。每个Block由唯一的Block ID(org.apache.spark.storage.RDDBlockId) 标识,格式是"rdd_" + rddId + "_" + partitionId。

BlockManager会运行在Driver和每个Executor上。而运行在Driver上的BlockManger负责整个Job的Block的管理工作;运行在Executor上的BlockManger负责管理该Executor上的Block,并且向Driver的BlockManager汇报Block的信息和接收来自它的命令。

各个主要类的功能说明:

1)       org.apache.spark.storage.BlockManager: 提供了Storage模块与其他模块的交互接口,管理Storage模块。

2)       org.apache.spark.storage.BlockManagerMaster: Block管理的接口类,主要通过调用org.apache.spark.storage.BlockManagerMasterActor来完成。

3)       org.apache.spark.storage.BlockManagerMasterActor: 在Driver节点上的Actor,负责track所有Slave节点的Block的信息

4)       org.apache.spark.storage.BlockManagerSlaveActor:运行在所有的节点上,接收来自org.apache.spark.storage.BlockManagerMasterActor的命令,比如删除某个RDD的数据,删除某个Block,删除某个Shuffle数据,返回某些Block的状态等。

5)       org.apache.spark.storage.BlockManagerSource:负责搜集Storage模块的Metric信息,包括最大的内存数,剩余的内存数,使用的内存数和使用的Disk大小。这些是通过调用org.apache.spark.storage.BlockManagerMaster的getStorageStatus接口实现的。

6)       org.apache.spark.storage.BlockObjectWriter:一个抽象类,可以将任何的JVM object写入外部存储系统。注意,它不支持并发的写操作。

7)       org.apache.spark.storage.DiskBlockObjectWriter:支持直接写入一个文件到Disk,并且还支持文件的append。实际上它是org.apache.spark.storage.BlockObjectWriter的一个实现。现在下面的类在需要Spill数据到Disk时,就是通过它来完成的:

a)        org.apache.spark.util.collection.ExternalSorter

b)       org.apache.spark.shuffle.FileShuffleBlockManager

8)       org.apache.spark.storage.DiskBlockManager:管理和维护了逻辑上的Block和存储在Disk上的物理的Block的映射。一般来说,一个逻辑的Block会根据它的BlockId生成的名字映射到一个物理上的文件。这些物理文件会被hash到由spark.local.dir(或者通过SPARK_LOCAL_DIRS来设置)上的不同目录中。

9)       org.apache.spark.storage.BlockStore:存储Block的抽象类。现在它的实现有:

a)        org.apache.spark.storage.DiskStore

b)       org.apache.spark.storage.MemoryStore

c)        org.apache.spark.storage.TachyonStore

10)     org.apache.spark.storage.DiskStore:实现了存储Block到Disk上。其中写Disk是通过org.apache.spark.storage.DiskBlockObjectWriter实现的。

11)     org.apache.spark.storage.MemoryStore:实现了存储Block到内存中。

12)     org.apache.spark.storage.TachyonStore:实现了存储Block到Tachyon上。

13)     org.apache.spark.storage.TachyonBlockManager:管理和维护逻辑上的Block和Tachyon文件系统上的文件之间的映射。这点和org.apache.spark.storage.DiskBlockManager功能类似。

14)     org.apache.spark.storage.ShuffleBlockFetcherIterator:实现了取Shuffle的Blocks的逻辑,包括读取本地的和发起网络请求读取其他节点上的。具体实现可以参照《Shuffle模块详解》。

如果您喜欢 本文,那么请动一下手指支持以下博客之星的评比吧。非常感谢您的投票。每天可以一票哦。

点我投票

时间: 2024-11-03 21:52:24

Spark技术内幕:Storage 模块整体架构的相关文章

Spark技术内幕:Master的故障恢复

Spark技术内幕:Master基于ZooKeeper的High Availability(HA)源码实现  详细阐述了使用ZK实现的Master的HA,那么Master是如何快速故障恢复的呢? 处于Standby状态的Master在接收到org.apache.spark.deploy.master.ZooKeeperLeaderElectionAgent发送的ElectedLeader消息后,就开始通过ZK中保存的Application,Driver和Worker的元数据信息进行故障恢复了,它

Spark技术内幕: Task向Executor提交的源码解析

在上文<Spark技术内幕:Stage划分及提交源码分析>中,我们分析了Stage的生成和提交.但是Stage的提交,只是DAGScheduler完成了对DAG的划分,生成了一个计算拓扑,即需要按照顺序计算的Stage,Stage中包含了可以以partition为单位并行计算的Task.我们并没有分析Stage中得Task是如何生成并且最终提交到Executor中去的. 这就是本文的主题. 从org.apache.spark.scheduler.DAGScheduler#submitMissi

我的第一本著作:Spark技术内幕上市!

现在各大网站销售中! 京东:http://item.jd.com/11770787.html 当当:http://product.dangdang.com/23776595.html 亚马逊:http://www.amazon.cn/SparkInternals 前言和目录附上,以便有需要了解的同学: 诞生于2005年的Hadoop解决了大数据的存储和计算问题,已经成为大数据处理的事实标准.但是,随着数据规模的爆炸式增长和计算场景的丰富细化,使得Hadoop越来越难以满足用户的需求.针对不同的计

Spark技术内幕:Master基于ZooKeeper的High Availability(HA)源码实现

     如果Spark的部署方式选择Standalone,一个采用Master/Slaves的典型架构,那么Master是有SPOF(单点故障,Single Point of Failure).Spark可以选用ZooKeeper来实现HA.      ZooKeeper提供了一个Leader Election机制,利用这个机制可以保证虽然集群存在多个Master但是只有一个是Active的,其他的都是Standby,当Active的Master出现故障时,另外的一个Standby Maste

Spark技术内幕:Shuffle Read的整体流程

回忆一下,每个Stage的上边界,要么需要从外部存储读取数据,要么需要读取上一个Stage的输出:而下边界,要么是需要写入本地文件系统(需要Shuffle),以供childStage读取,要么是最后一个Stage,需要输出结果.这里的Stage,在运行时的时候就是可以以pipeline的方式运行的一组Task,除了最后一个Stage对应的是ResultTask,其余的Stage对应的都是ShuffleMap Task. 而除了需要从外部存储读取数据和RDD已经做过cache或者checkpoin

Spark技术内幕:Worker源码与架构解析

首先通过一张Spark的架构图来了解Worker在Spark中的作用和地位: Worker所起的作用有以下几个: 1. 接受Master的指令,启动或者杀掉Executor 2. 接受Master的指令,启动或者杀掉Driver 3. 报告Executor/Driver的状态到Master 4. 心跳到Master,心跳超时则Master认为Worker已经挂了不能工作了 5. 向GUI报告Worker的状态 说白了,Worker就是整个集群真正干活的.首先看一下Worker重要的数据结构: v

Spark技术内幕:Shuffle的性能调优

通过上面的架构和源码实现的分析,不难得出Shuffle是Spark Core比较复杂的模块的结论.它也是非常影响性能的操作之一.因此,在这里整理了会影响Shuffle性能的各项配置.尽管大部分的配置项在前文已经解释过它的含义,由于这些参数的确是非常重要,这里算是做一个详细的总结. 1.1.1  spark.shuffle.manager 前文也多次提到过,Spark1.2.0官方支持两种方式的Shuffle,即Hash Based Shuffle和Sort Based Shuffle.其中在Sp

Spark技术内幕:Client,Master和Worker 通信源码解析

Spark的Cluster Manager可以有几种部署模式: Standlone Mesos YARN EC2 Local 在向集群提交计算任务后,系统的运算模型就是Driver Program定义的SparkContext向APP Master提交,有APP Master进行计算资源的调度并最终完成计算.具体阐述可以阅读<Spark:大数据的电花火石! >. 那么Standalone模式下,Client,Master和Worker是如何进行通信,注册并开启服务的呢? 1. node之间的R

Spark技术内幕:Sort Based Shuffle实现解析

在Spark 1.2.0中,Spark Core的一个重要的升级就是将默认的Hash Based Shuffle换成了Sort Based Shuffle,即spark.shuffle.manager 从hash换成了sort,对应的实现类分别是org.apache.spark.shuffle.hash.HashShuffleManager和org.apache.spark.shuffle.sort.SortShuffleManager. 这个方式的选择是在org.apache.spark.Sp