spark streaming中遇到的问题_stream ends prematurely at 21236117-CSDN博客

本文链接：https://blog.csdn.net/weixin_45896475/article/details/105570761

本文探讨了SparkStreaming中任务数据分配不均的问题，特别是在直接从Kafka拉取数据时，由于数据分布不均导致部分task处理数据量过小，影响集群CPU资源利用率。文章提出了使用DStream.repartition()函数重新分区的解决方案，通过数据shuffle提高并行度，从而更充分地利用集群资源。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

spark streaming中遇到的问题

出现的问题

task数据分配不均

task数据分配不均的原因

由于我这个日志分析系统是使用direct模式从kafka拉取数据的, 在direct模式下, 通过KafkaUtils.createDirectStream(…)获取的DStream中的rdd的分区数是与kafka相对应的topic的分区数是一样的,且分区中的数据分布情况也是一样的.
这就导致了spark streaming获取的rdd的分区中只有一个是有数据的, 而task与分区也是一一对应关系, 所以就造成了只有一个task在处理数据.

解决问题

问题逐渐清晰了, 其实就是线上从kafka获取数据时, kafka中的分区数据分布不均, 导致部分task处理的数据量特别少, 集群cpu资源得不到充分利用.
而解决办法就是, 利用DStream.reparation(partitionNum), 对DStream进行重新分区, 请注意, reparation()函数会对数据做shuffle, 这就相当于将数据分配到了其他机器上.这样就能提高并行度, 提高集群cpu资源利用率.

拓展

1.(提高成本)Direct(直连的方法)需要采用checkpoint或者第三方储存来维护offsets(偏移量),
而Rexeiver-based是通过Zookeeper来维护Offsets,所以用Direct提高了用户的开发成本
2.(监控可视化)Receiver-based方式制定topic制定consumer的消费情况均能通过Zookeeper来监控,而Direct则没有这种便利，如果做到监控并可视化，则需要投入人力开发。