Spark Streaming 数据产生与导入相关的内存分析

前言

我这篇文章会分几个点来描述Spark Streaming 的Receiver在内存方面的表现。

  • 一个大致的数据接受流程
  • 一些存储结构的介绍
  • 哪些点可能导致内存问题,以及相关的配置参数

另外,有位大牛写了Spark Streaming 源码解析系列,我觉得写的不错,这里也推荐下。

我在部门尽力推荐使用Spark Streaming做数据处理,目前已经应用在日志处理,机器学习等领域。这期间也遇到不少问题,尤其是Kafka在接受到的数据量非常大的情况下,会有一些内存相关的问题。

另外特别说明下,我们仅仅讨论的是High Level的Kafka Stream,也就是输入流通过如下方式创建:

 KafkaUtils.createStream

并且不开启WAL的情况下。

数据接受流程

启动Spark Streaming(后续缩写为SS)后,SS 会选择一台Executor 启动ReceiverSupervisor,并且标记为Active状态。接着按如下步骤处理:

  1. ReceiverSupervisor会启动对应的Receiver(这里是KafkaReceiver)
  2. KafkaReceiver 会根据配置启动新的线程接受数据,在该线程中调用 ReceiverSupervisor.store 方法填充数据,注意,这里是一条一条填充的。
  3. ReceiverSupervisor 会调用 BlockGenerator.addData 进行数据填充。

到目前为止,整个过程不会有太多内存消耗,正常的一个线性调用。所有复杂的数据结构都隐含在 BlockGenerator 中。

BlockGenerator 存储结构

BlockGenerator 会复杂些,这里有几个点,

  1. 维护了一个缓存 currentBuffer ,就是一个无限长度的ArrayBuffer。currentBuffer 并不会被复用,而是每次都会新建,然后把老的对象直接封装成Block,BlockGenerator会负责保证currentBuffer 只有一个。currentBuffer 填充的速度是可以被限制的,以秒为单位,配置参数为 spark.streaming.receiver.maxRate。这个是Spark内存控制的第一道防线,填充currentBuffer 是阻塞的,消费Kafka的线程直接做填充。
  2. 维护了一个 blocksForPushing 队列, size 默认为10个(1.5.1版本),可通过 spark.streaming.blockQueueSize 进行配置。该队列主要用来实现生产-消费模式。每个元素其实是一个currentBuffer形成的block。
  3. blockIntervalTimer 是一个定时器。其实是一个生产者,负责将currentBuffer 的数据放到 blocksForPushing 中。通过参数 spark.streaming.blockInterval 设置,默认为200ms。放的方式很简单,直接把currentBuffer做为Block的数据源。这就是为什么currentBuffer不会被复用。
  4. blockPushingThread 也是一个定时器,负责将Block从blocksForPushing取出来,然后交给BlockManagerBasedBlockHandler.storeBlock 方法。10毫秒会取一次,不可配置。到这一步,才真的将数据放到了Spark的BlockManager中。

步骤描述完了,我们看看有哪些值得注意的地方。

currentBuffer

首先自然要说下currentBuffer,如果200ms期间你从Kafka接受的数据足够大,则足以把内存承包了。而且currentBuffer使用的并不是spark的storage内存,而是有限的用于运算存储的内存。 默认应该是 heap*0.4。除了把内存搞爆掉了,还有一个是GC。导致receiver所在的Executor 极容易挂掉,处理速度也巨慢。 如果你在SparkUI发现Receiver挂掉了,考虑有没有可能是这个问题。

blocksForPushing

blocksForPushing 这个是作为currentBuffer 和BlockManager之间的中转站。默认存储的数据最大可以达到 10*currentBuffer 大小。一般不打可能,除非你的 spark.streaming.blockInterval 设置的比10ms 还小,官方推荐最小也要设置成 50ms,你就不要搞对抗了。所以这块不用太担心。

blockPushingThread

blockPushingThread 负责从 blocksForPushing 获取数据,并且写入 BlockManager 。这里很蛋疼的事情是,blockPushingThread只写他自己所在的Executor的 blockManager,也就是每个batch周期的数据都会被 一个Executor给扛住了。 这是导致内存被撑爆的最大风险。 也就是说,每个batch周期接受到的数据最好不要超过接受Executor的内存(Storage)的一半。否则有你受的。我发现在数据量很大的情况下,最容易挂掉的就是Receiver所在的Executor了。 建议Spark-Streaming团队最好是能将数据写入到多个BlockManager上。

StorageLevel 的配置问题

另外还有几个值得注意的问题:

  • 如果你配置成Memory_Disk ,如果Receiver所在的Executor一旦挂掉,你也歇菜了,整个Spark Streaming作业会失败。失败的原因是一部分block找不到了。
  • 如果你配置成Memory_Disk_2,数据会被replication到不同的节点。一般而言不会出现作业失败或者丢数据。但解决不了Receiver也容易挂的问题,当然还是主要还是内存引起的。
  • 最好是采用默认设置 MEMORY_AND_DISK_SER_2 比较靠谱些。
  • 这里面还有一个风险点就是,如果某个batch processing延迟了,那么对应的BlockManager的数据不会被释放,然后下一个batch的数据还在进,也会加重内存问题。

动态控制消费速率以及相关论文

另外,spark的消费速度可以设置上限以外,亦可以根据processing time 来动态调整。通过 spark.streaming.backpressure.enabled 设置为true 可以打开。算法的论文可参考: Socc 2014: Adaptive Stream Processing using Dynamic Batch Sizing ,还是有用的,我现在也都开启着。

Spark里除了这个 Dynamic,还有一个就是Dynamic Allocation,也就是Executor数量会根据资源使用情况,自动伸缩。我其实蛮喜欢Spark这个特色的。具体的可以查找下相关设计文档。

后话

接下来一篇文章会讲一些解决方案。

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏猿人谷

HDFS详解

【一】HDFS简介 HDFS的基本概念1.1、数据块(block) HDFS(Hadoop Distributed File System)默认的最基本的存储...

33410
来自专栏大数据

大数据干货系列(三)-Hadoop2.0总结

本文共计810字,预计阅读时长五分钟 Hadoop2.0总结 一、本质 Hadoop2.0,相比于Hadoop1.0,最明显的区别是YARN系统和HDFS2.0...

2029
来自专栏分布式系统和大数据处理

安装和配置Spark(单节点)

Apache Spark被称为第三代大数据处理平台,也当前应用最广泛的大数据处理方案,这篇文章将介绍如何在Linux系统(Cent OS7)上以单机模式(Sta...

7825
来自专栏闵开慧

hadoop源码解析1 - hadoop中各工程包依赖关系

1 hadoop中各工程包依赖简述     Google的核心竞争技术是它的计算平台。Google的大牛们用了下面5篇文章,介绍了它们的计算设施。     G...

3285
来自专栏星汉技术

原 Spark简介及完全分布式安装

3486
来自专栏星回的实验室

打造自己的MapReduce[一]:Hadoop集群搭建

那就是我在这里的每一篇文开头都必然是:最近工作好忙,又断更很久了……Anyway,这也不能成为偷懒的理由。我可能对记录技术有些固执的误解,总认为是要待到整理出一...

1111
来自专栏数据和云

Hadoop 面试,来看这篇就够了

原文链接 | http://www.jianshu.com/p/c97ff0ab5f49

1172
来自专栏美团技术团队

HDFS NameNode重启优化

一、背景 在Hadoop集群整个生命周期里,由于调整参数、Patch、升级等多种场景需要频繁操作NameNode重启,不论采用何种架构,重启期间集群整体存在可用...

5687
来自专栏Hadoop实操

Cloudera产品支持生命周期策略

本文主要介绍Cloudera企业版产品支持的生命周期,包括CDH每个版本终止支持的预计日期。了解该策略主要是方便大家在规划搭建/升级CDH集群时的版本选择,不代...

2553
来自专栏美图数据技术团队

Spark Streaming VS Flink

本文从编程模型、任务调度、时间机制、Kafka 动态分区的感知、容错及处理语义、背压等几个方面对比 Spark Stream 与 Flink,希望对有实时处理...

1621

扫码关注云+社区

领取腾讯云代金券