Spark Streaming - Block数据存储

之前介绍了在Spark Streaming的环境中,如何启动Receiver进行数据接收,那么当我们Receiver启动了之后,就会进行数据接收,接受的数据就会进行相应的存储等待后续的计算Job进行调用(这也是Spark Streaming叫做”micro-batch”的一个特色)。所以数据存储过程需要我们深度挖一下。

Spark Streaming 数据存储方式

资深老玩家只要看到在Receiver里面调用store() 来存储我们接收到的Block数据的时候,就领悟到实际上是利用ReceiverSupervisor来进行存储,那么我们就从ReceiverSupervisor看起走。

  1. 下面是ReceiverSupervisor提供出来的数据存储的相应接口

        /** Push a single record of received data into block generator. */
    

def pushSingle(data: Any) {
defaultBlockGenerator.addData(data)
}

/** Store an ArrayBuffer of received data as a data block into Spark's memory. */
def pushArrayBuffer(
arrayBuffer: ArrayBuffer[_],
metadataOption: Option[Any],
blockIdOption: Option[StreamBlockId]
) {
pushAndReportBlock(ArrayBufferBlock(arrayBuffer), metadataOption, blockIdOption)
}

/** Store an iterator of received data as a data block into Spark's memory. */
def pushIterator(
iterator: Iterator[_],
metadataOption: Option[Any],
blockIdOption: Option[StreamBlockId]
) {
pushAndReportBlock(IteratorBlock(iterator), metadataOption, blockIdOption)
}

/** Store the bytes of received data as a data block into Spark's memory. /
def pushBytes(
bytes: ByteBuffer,
metadataOption: Option[Any],
blockIdOption: Option[StreamBlockId]
) {
pushAndReportBlock(ByteBufferBlock(bytes), metadataOption, blockIdOption)
}
```
我们看到除了
pushSingle* 跟大家不一样以外,几乎都是调用pushAndReportBlock来完成的存储,其实pushSingle最后也是调用pushAndReportBlock来完成的。那么这里defaultBlockGenerator.addData(data)做了什么呢,主要是就是要有规律的产生Block数据,这里剧透一个很关键的事情: 一份Block的数据就对应RDD里面的一个partition, partition就意味着task的数目,为了控制住partition以及task合理,这里对于单个的数据,我们就需要hold住下,有规律的产生Block。
BlockGenerator里面就有这两个线程: 一个周期性的把前一个batch的数据构造成一个Block, 一个就负责把这个Block的数据push到BlockManager.

**关键的一个主角参数出现一个:  spark.streaming.blockInterval ,他就是控制产生Block的周期,默认为200ms,如果大家的流式数据量很大的话,那么就考虑降低这个参数,从而获得大量的partition以及task上面的并发。**

那么接下来我们还是看下**pushAndReportBlock**做了什么事情吧, 因为不管存single 还是 存一堆的 都是调用了他。
  1. pushAndReportBlock做了两件事调receivedBlockHandler帮他完成真正存储过程,并且通过之前跟master建立好的链trackerEndpoint汇报说我已经添加了一个Block.

val blockId = blockIdOption.getOrElse(nextBlockId) // nextBlockId = streamId + newBlockId.getAndIncrement() 来取一个唯一的Id
.....
val blockStoreResult = receivedBlockHandler.storeBlock(blockId, receivedBlock)
.....
trackerEndpoint.askWithRetryBoolean


    我们先看下接下来看下 ReceivedBlockHandler如何存Block, 然后再看下汇报给master, master又做了什么对于这个Block做了什么
    
3.  在ReceivedBlockHandler里面进行存储的时候,真正存储的主角就出现啦 ---**BlockManager**,首先这里需要讲清楚一点,我一开始也没有理解透的,后来翻了好多代码才明白的,就是这个BlockManager是如何每个Executor都有一个的?
    ```java
  private val host = SparkEnv.get.blockManager.blockManagerId.host
  private val executorId = SparkEnv.get.blockManager.blockManagerId.executorId
从上面代码不难看出blockManager是从一个全局SparkEnv中得到,当每个Executor启动的时候就会创建自己Executor的SparkEnv,这时候就会有BlockManager产生(先立FLAG在后面就会讲到Executor创建BlockManager的整个流程)。机智的我,一开始一直以为这个SparkEnv来自于master(创建这个ReceiverSupervisor的时候,从master序列化过来的), 后来发现怎么也绕不通这个流程,后来无意翻到Executor的代码才发现原来每个Executor构造自己jvm执行环境的时候就创建了自己的SparkEnv.
  1. 重点来了,吃瓜群众终于等到了BlockManager如何存储数据的了。那我们就聊下这个流程吧。
    a. 第一步,我们会通过BlockInfoManager获得写入这个Block的锁,当已经有人在写入同一个Block的时候,那么就会进行等待直到有人已经成功写入,这时候我们写入操作会变成一个读取操作(获取一个读锁接着读),同时会返回给我们告诉这个Block已经被人捷足先登啦,这次写入就返回失败,如果一切顺利,那么就会拿到这个BlockId的写锁。

b. 第二步,如果存储等级可以level.useMemory , 那么就先利用memoryStore放入内存,如果放不下就会利用diskStore来存入磁盘里面。如果存储等级为level.useDisk 就直接存入磁盘中, 不管是数据最后存入memory 还是 disk, 都会去check存储的状态,顺利存储就会通知master

c.第三步, 根据level.replication > 1来去判断是否要进行replicate, 如果要进行replicate,就会replicate(blockId, bytesToReplicate, level, remoteClassTag) 来完成block到其他node的replicate.

存储到本Executor的blockManager的过程就完成,接下来我们会看下汇报给master之后,汇报给master的目的其实就是为了构造分布式任务的时候,master可以做到分布式调配。
  1. 大家还记得我们是通过下面这个方法, 从Receiver端告诉master,Block已经加成功
    javatrackerEndpoint.askWithRetry[Boolean](AddBlock(blockInfo))
    注意这里的blockInfo里面主要有个carry信息: 成功存储的BlockId信息

    在这之前有那么一个东西叫做 ReceiverTracker, 他是在JobScheduler里面初始化的。这家伙就会监听这种Block成功加入的消息。
    这家伙接受到消息之后就会通过专门的ReceivedBlockTracker来进行记录,
    记录主要就是StreamId和这个BlockId 存入streamIdToUnallocatedBlockQueues里面,为什么叫unallocated, 就是代表Streaming的job还没有来进行处理这些blockIds,等着被收割的。

    后续最要的工作的就留给Spark Streaming Job的讲解啦, 下面贴一个Store存储的流程图,一言不合就上图.

StoreFlow.png
最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 213,864评论 6 494
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 91,175评论 3 387
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 159,401评论 0 349
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 57,170评论 1 286
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 66,276评论 6 385
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 50,364评论 1 292
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,401评论 3 412
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 38,179评论 0 269
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,604评论 1 306
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,902评论 2 328
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,070评论 1 341
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,751评论 4 337
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 40,380评论 3 319
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,077评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,312评论 1 267
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 46,924评论 2 365
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 43,957评论 2 351

推荐阅读更多精彩内容