SparkStreaming消费上游kafka再生产给下游kafka场景下的executor nums设置问题

公司生产环境下原本kafka topic是0.8版本,4分区

由于数据量过大,所以需要逐渐往kafka topic 1.0版本(24分区)迁移,出现的场景如下:

kafka topic 0.8(4分区) —> Spark Streaming(Spark Submit脚本)—> kafka topic 1.0(24分区)

在SparkSubmit脚本中可以申请资源量,例如executor nums申请为24.

这里就涉及到一个资源量的占用和效率问题,Spark申请的资源量为资源上限,实际运行任务占用的资源量依据实际而定,例如资源量申请为100,实际资源使用量为60,那剩下40资源量就等于空闲,占用yarn队列总资源量,所以可以把Spark总资源量申请为60,这样并不会影响任务运行效率。

原理如下:

Spark消费上游kafka数据时候,是强制的一对一消费,也就是上游4分区,对应Spark的4个core(即4个executors)

然后Spark往下游kafka生产数据时,是4个有数据的core,随机往下游24个分区中写数据

所以至始至终只有4个core在并行运行任务。

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

这种情况下,

把Spark的executor nums设置为4,既能满足任务需要,又最小程度占用队列资源。

但是这样有个风险是,如果数据量过大,4个分区可能处理不过来,有两种解决方案:
1. 给上游kafka topic扩大分区数,扩大到24;

2. 上游kafak分区数不扩大的情况下,在sparkStreaming里通过重分区算子,把分区数shuffle成24。

  • 1
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值