Spark Streaming中的scheduling dela

最近由于疫情在家办公，事情比较多（主要在各种沟通和会上），一直没有更新；正好工作中有个case, 用到啦spark streaming， 所以随手记录一下，遇到的问题；

背景

需要协助SDK的同事，搭建反作弊SDK线下测试环境，所以需要数据团队，协助搭建日志收集、解析、到查询这块的工作，方便SDK开发同学，进行case的测试和分析；日志收集这块没什么可介绍的，采用flume-ng从logserver上，实时抓取数据放入公司kafka集群，spark streaming任务从kafka消费制定的topic，并进行数据过滤、解密、解析等操作，将结果数据放入mysql集群，方便后期即席查询（测试数据比较小，所以选择了MYSQL）。事情比较简单清晰，但是在spark Streaming上线以后，发现随时运行时间的增长，延时会越来越大，这显然违背了当初近实时的初衷，问题出在哪呢？？？

问题的排查

逻辑比较清晰，代码也不复杂，吞吐不存在问题，但是延时确实真是存在的；首先从spark 的web ui, 看看我们能发现什么。从spark 的监控界面，可以清晰的看到，很多Task 都被 queue住啦，很多batch job 等待被调起；从Steaming statistics界面，可以看到Scheduling delay在某一个时刻，开始呈现递增，同时，Processing Time 也有一定的增长（在这里，我们是5S的时间间隔，一般建议是1~10S的时间间隔），Processing Time 已经超过了5S的时间；从hadoop 的Job Tracher页面，查看对应QUEUE的资源占用情况，发现当前资源比较紧张；那先看一下什么是scheduling delay，再去考虑怎么解决~

什么是scheduling delay

官网解释如下：

Scheduling Delay is the time spent from when the collection of streaming jobs for a batch was submittedto when the first streaming job (out of possibly many streaming jobs in the collection) was started.

spark streaming是一种伪实时，底层还是一种微批的概念，所以Scheduling delay可以理解为一个batch从提交，到任务被调起所花费的时间；SO 问题来啦，如果集群的一个queue同时运行的任务比较多，任务会共享同一queue内的集群资源（CPU/内存/网络）；

在我们的应用中，测试环境的数据量并不大，所以我解决方法比较直接；

1）首先降低占用的资源情况，主要是修改在任务提交时，executor的memeory以及executor的个数；

2）提高spark Streaming的interval（由于数据比较小，并且很多时候是空转的情况），从之前的5S提升到30S，降低任务频繁调起的时间消耗；

重新打包，上线运行测试，运行了一段时间，修复之前的延时问题；

TODO

后续如果吞吐量比较大，30S的时间间隔有可能会导致OOM，后续更多可以从算子、或者队集群列隔离等方面，去保证线上吞吐量、延时性要求较高的任务