Spark streaming动态调整资源调研报告

一、需求背景:

我们希望spark streaming根据不同时间段的数据量不同（例如高峰期和低谷期），自动调整spark的计算资源（包含CPU和memory大小）。从而，可以在高峰期自动增加计算资源以提升处理能力，在数据量低谷时候自动缩减所需资源量，减少资源浪费。

二、 调研情况：

2.1 spark on mesos的资源伸缩原理

spark 1.5开始为standalone模式和mesos的粗粒度模式提供了executor的动态管理，具体表现为：如果executor在一段时间内空闲就会移除这个executor。

• 动态申请executor

如果有新任务处于等待状态，并且等待时间超过Spark.dynamicAllocation.schedulerBacklogTimeout(默认1s)，则会依次启动executor,每次启动1,2,4,8…个executor（如果有的话）。启动的间隔由spark.dynamicAllocation.sustainedSchedulerBacklogTimeout控制(默认与schedulerBacklogTimeout相同)。

• 动态移除executor

executor空闲时间超过spark.dynamicAllocation.executorIdleTimeout设置的值(默认60s )，该executor会被移除，除非有缓存数据。

Spark streaming动态调整资源-调研报告_spark


2.2 配置项修改操作

开启Spark动态资源分配的两个必要条件：
（1）代码中要有两个属性

.config("spark.dynamicAllocation.enabled", "true")
.config("spark.shuffle.service.enabled", "true")

（2）Spark的Worker要有如下配置：
打开worker的$SPARK_HOME/conf/spark-defaults.conf
添加：

spark.shuffle.service.enabled true

1启动Spark集群（StandAlone模式）
调用spark job，当任务执行完成后，等待60s，你会发现任务申请的资源（Executor）都自动释放了！

PS：一些有用的参数：

spark.dynamicAllocation.executorIdleTimeout 默认60s，如果executor超过这个时间未执行任务，则自动释放资源
spark.dynamicAllocation.initialExecutors    spark.dynamicAllocation.minExecutors 默认0，JOB申请的executor最小个数，默认是0个
spark.dynamicAllocation.maxExecutors 默认infinite，JOB申请的executor最大个数，默认是无限个
spark.dynamicAllocation.minExecutors 默认等于最小个数


三、实操技术路线

3.1当前状态

当前，spark的版本为：spark:2.4.0-2.2.1-3-hadoop-2.6 ，spark运行依赖于mesos作为资源调度框架；
因此，如果改为弹性资源伸缩的方式，只需要修改相应的配置即可。

3.2 技术路线

需要在集群上模拟测试。
第一步：
在业务的detect-trialproduction.json配置文件中，或者jenkins中修改相应的配置参数，重新将业务程序1的spark streaming模拟测试程序运行；
具体改变参数，在json中添加

"env": {  
	"default.parallelism": "50",  
	"dynamicAllocation.enabled": "true", 
	"shuffle.service.enabled": "true", 
	"dynamicAllocation.executorIdleTimeout": "60", 
	"dynamicAllocation.initialExecutors": "1", 
	"dynamicAllocation.maxExecutors": "6",
	"dynamicAllocation.minExecutors": "1",
	"dynamicAllocation.schedulerBacklogTimeout": "120",
}

附件1 常见参数列表


【注意事项】：关于参数设置
关于spark程序动态资源分配的一些理解

第二步：运行之后，查看初始化的executor的数量是否为给定的数量（做好记录）；
首先给定小的数据量，保证spark（ML）按时处理完成，查看此时executor数量，待稳定处理一段时间之后（期间做好executor数量记录），增加spark的数据量用来模拟高峰期的数据（通过增加给kafka实时发送的数据量），此时查看executor的数量，并做好记录。

第三步：减少spark摄入的kafka实时数据量，查看executor的数量是否相应的缩小。验证资源在小数据量时候的弹性缩容情况；

总结：通过最终的报告情况，验证spark steaming的弹性资源调整情况；