第17课:Spark Streaming资源动态申请和动态控制消费速率原理剖析

本节课主要谈Spark Streaming两个比较高级的特性:Spark Streaming资源动态申请和动态控制消费速率原理剖析。动态消费速率背后有一套非常复杂的理论,这套理论有一篇非常好的论文, 而动态资源分配背后也有一套理论。因此首先跟大家讲清楚理论是怎么回事情,然后再进行深入的探讨就会容易很多。
我们首先思考一个问题,无论是资源动态分配,还是消费速率动态控制,为什么要动态?Spark在默认情况下是先分配好资源,然后进行计算,是粗粒度的,粗粒度有一个好处:因为资源是提前分配好的,在执行任务的时候,使用分配好的资源就行了。粗粒度不好的地方:从Spark Streaming的角度讲,有高峰值和低峰值,高峰和低峰需要的资源是不一样的,如果对资源的分配是从高峰值的角度去考虑的,那么低峰值的时候会有大量的资源的浪费。
Heron是Twitter公司新开发的实时流式计算框架,Heron可以秒杀storm,在spark以外如再想研究一项技术,那就推荐研究Heron。有几点原因:
1,Heron和Storm都是Twitter公司开发的,Twitter当年开发Storm的时候是为了实时的在线多媒体的交互计算,Twitter是一家社交网络公司,需处理大量的并发消息个性化,对每个用户的消息进行最瞬间的送达以及最瞬间的广告推荐等。为什么推出Heron?因为Twitter的消息量暴增,它的业务量暴增,一家同时开发过Heron和Storm,世界上最深度用过Storm的公司,Twitter现在都不用Storm而转向使用Heron,因此,这是Heron技术值得关注的第一个原因。Heron对新特性的支持,包括资源的动态分配,对硬件更小的消耗及更小的延时。悲剧的一点是Storm以后不需要再用了,Heron可以兼容Storm,Storm原来的代码一行也不用改变,重新编译一下,Heron就可以使用Storm的代码。因为Twitter公司之前那么多业务使用Storm,不能新搞一个框架让业务代码全部重写一遍。理论上讲,所有使用Storm的公司一定会转向Heron。可以想象一下,代码一行不用改,重新编译一下就变成了Heron的代码,硬件消耗降低3倍以上,延时提高了10倍左右,Heron具有Storm的所有功能。所以Storm已经成为历史了,不用再考虑Storm。
2,现在是一个流处理的时代,Spark 2.x对自己的速度,包括对自己的编译器有革命性的变化,当年Spark Streaming推出的时候参考了Storm的想法,在Storm的基础上推出了Spark Streaming。Spark 2.x内核引擎有革命性的变化,Spark Streaming最大的优势在于跟Spark的兄弟框架联手。如果需要完全实时性的,或更高的实时性,Heron是一项值得关注的技术,Heron的开发语言是C++、Java、Python,Heron的配置用了Python的代码,Heron的API级别是Java级别的,我们通常写代码及调试程序的时候基于Java,这也有利于学习Heron。

为什么谈到Heron,因为峰值的问题,很多流处理系统不能很好的进行处理。现在我们考虑Spark Streaming,在资源分配的时候如果按照高峰的峰值进行分配,是粗粒度的,在预分配的时候造成资源的浪费,在低峰值的时候导致大量的浪费。在另外一方面,随着Spark Streaming本身不断的运行,对资源的消耗管理也是我们要考虑的因素,这里我们谈Spark Streaming资源动态申请和动态控制消费速率是高级别的特性,特性的实现对Spark Streaming的运行非常重要的。Spark Streaming本身是基于Spark Core,Spark Core的核心是Spark Context。Spark现在支持资源的动态分配。这里有个配置参数spark.dynamicAllocation.enabled,是否需要开启资源的动态分配,在程序运行的时候进行设置。如果支持动态分配,使用ExecutorAllocationManager,传入参数有ExecutorAllocationClient、listenerBus、_conf 

Spark现在支持资源的动态分配。这里有个配置参数spark.dynamicAllocation.enabled,是否需要开启资源的动态分配,在程序运行的时候进行设置。如果支持动态分配,使用ExecutorAllocationManager,传入参数有ExecutorAllocationClient、listenerBus、_conf。

SparkContext.scala的源代码:

1.            val dynamicAllocationEnabled =Utils.isDynamicAllocationEnabled(_conf)

2.             _executorAllocationManager =

3.               if(dynamicAllocationEnabled) {

4.                 schedulerBackend match {

5.                   case b:ExecutorAllocationClient =>

6.                     Some(newExecutorAllocationManager(

7.                       schedulerBackend.asInstanceOf[ExecutorAllocationClient],listenerBus, _conf))

8.                   case _ =>

9.                     None

10.              }

11.            } else {

12.              None

13.            } 

14.       _executorAllocationManager.foreach(_.start())

15.      ……

16.      Utils.scala的源代码:

17.        def isDynamicAllocationEnabled(conf:SparkConf): Boolean = {

18.          val dynamicAllocationEnabled =conf.getBoolean("spark.dynamicAllocation.enabled", false)

19.          dynamicAllocationEnabled &&

20.            (!isLocalMaster(conf) ||conf.getBoolean("spark.dynamicAllocation.testing", false))

21.        }

 

ExecutorAllocationManager是根据工作负载动态分配和删除executors 的代理。ExecutorAllocationManager保持目标数量的executors,周期性的同步到集群管理。以配置的初始值开始,根据挂起和正在运行的任务的数量进行变化。当当前目标超过当前处理负载的需要时,减少executors 执行器的目标数量,executors 执行器的目标数目减少,可以立即运行所有当前正在运行和正在等待的任务。如果积压任务等待调度响应,那么增加executors的目标数。如果调度队列在N秒内没有耗尽,则添加新的执行器executors。如果队列持续了M秒钟,需添加更多的executors等。每一轮增加的数量从上一轮的指数增长,直到达到上限。上限基于配置的属性和如上所描述的当前的运行和待处理的任务。指数增长的原因有两方面:

(1)在开始的情况下Executors 应缓慢增加,需要额外的Executors的数量变小。否则,

我们可以添加更多的Executors ,而不是需要稍后删除它们。

(2)Executors 应迅速增加。随着时间的推移,Executors 的最大数量非常高。否则,它将采取长时间的负载下进行繁重的工作。

删除策略比较简单:如果executor 空闲时间为k秒,则意味着它没有计划运行任何任务,然后删除它。在这两种情况下都没有重试逻辑,因为我们假设集群管理器最终将完成它异步接收的所有请求。

相关Spark的属性如下:

l  spark.dynamicAllocation.enabled是否启用此功能

l  spark.dynamicAllocation.minExecutors  executors最小的数量

l  spark.dynamicAllocation.maxExecutors  executors最大的数量

l  spark.dynamicAllocation.initialExecutorsexecutors初始化的数量

l  spark.dynamicAllocation.schedulerBacklogTimeout(M) 如果有积压的任务持续时间,增加新的executors

l  spark.dynamicAllocation.sustainedSchedulerBacklogTimeout(N) 如果积压时间持续,增加更多的executors,仅在初始积压超时后才使用此选项

l  spark.dynamicAllocation.executorIdleTimeout(K)  如果executors在此期间处于空闲状态,删除它。

 

ExecutorAllocationManager.scala的源代码:

1.          private[spark] classExecutorAllocationManager(

2.             client:ExecutorAllocationClient,

3.             listenerBus: LiveListenerBus,

4.             conf: SparkConf)

5.           extends Logging {

6.         …..

7.           // Clock used to schedule when executorsshould be added and removed

8.           private var clock: Clock = new SystemClock()

 

有个定时器,定时器不断的去扫描executor的情况:正在运行的Stage,Stage运行在不同的executor中,所谓动态就是指要么增加要么减少executor。例如,减少executor的情况, 判断一个时间如60秒中executor没有一个任务在运行,就把这个executor删掉。这是去掉executor的情况,因为当前的应用程序中运行的所有executor,在Driver中有数据结构对它进行保持引用,每次任务调度的时候循环遍历一下executor可用列表,看一下executor的可用资源,由于有个时钟Clock,有时钟就可以不断的循环,循环检查是否满足增加executor或者删除executor的条件,如果满足条件,就会触发executor的增加和删除。executor的增加和删除非常简单,因为Driver中的ExecutorBackend有对executor的管理关系,例如超时,可以设置一个add的时间,或者评估一下当前的作业资源,如果不够的话申请更多的资源。之所以动态起来,类似于有一个时钟,在固定的周期里检查,如果想删除,就发一个killExecutor的信息,如果想添加,就在具体的Work上启动Executor。

Master的schedule分配资源,是默认的资源分配方式。

Master.scala的源代码:

1.           private def schedule(): Unit = {

2.             if (state !=RecoveryState.ALIVE) {

3.               return

4.             }

5.             // Drivers take strictprecedence over executors

6.             val shuffledAliveWorkers =Random.shuffle(workers.toSeq.filter(_.state == WorkerState.ALIVE))

7.             val numWorkersAlive =shuffledAliveWorkers.size

8.             var curPos = 0

9.             for (driver <-waitingDrivers.toList) { // iterate over a copy of waitingDrivers

10.            // We assign workers to each waiting driverin a round-robin fashion. For each driver, we

11.            // start from the lastworker that was assigned a driver, and continue onwards until we have

12.            // explored all aliveworkers.

13.            var launched = false

14.            var numWorkersVisited = 0

15.            while (numWorkersVisited< numWorkersAlive && !launched) {

16.              val worker =shuffledAliveWorkers(curPos)

17.              numWorkersVisited += 1

18.              if (worker.memoryFree>= driver.desc.mem && worker.coresFree >= driver.desc.cores) {

19.                launchDriver(worker,driver)

20.                waitingDrivers -= driver

21.                launched = true

22.              }

23.              curPos = (curPos + 1) %numWorkersAlive

24.            }

25.          }

26.          startExecutorsOnWorkers()

27.        }

 

在 ExecutorAllocationManager.scala的源代码中也有schedule。在一个固定的时间间隔被调用来调节请求的executor的数量和executor 的运行数量。首先,根据添加时间和当前需要调整我们请求的executor 。然后,如果现有executor 的移除时间已经过期,则Kill executor 。

schedule内部方法将会被周期性的触发,将会周期性的执行。其中 removeTimes 是一个HashMap[String, Long]数据结构。

ExecutorAllocationManager.scala的源代码:

1.          private def schedule(): Unit =synchronized {

2.             val now = clock.getTimeMillis

3.          

4.             updateAndSyncNumExecutorsTarget(now)

5.          

6.             val executorIdsToBeRemoved =ArrayBuffer[String]()

7.             removeTimes.retain { case(executorId, expireTime) =>

8.               val expired = now >=expireTime

9.               if (expired) {

10.              initializing = false

11.              executorIdsToBeRemoved +=executorId

12.            }

13.            !expired

14.          }

15.          if(executorIdsToBeRemoved.nonEmpty) {

16.            removeExecutors(executorIdsToBeRemoved)

17.          }

18.        }

 

在ExecutorAllocationManager运行scheduleTask的时候直接进行schedule,而scheduleTask的运行是在executor.scheduleWithFixedDelay调用的。其中executor是一个线程池。在这个池子中只有一条线程。scheduleWithFixedDelay做了一个定时器,不断的调用schedule。里面有个参数是intervalMillis,默认是100毫秒,每隔100毫秒调整1次。

ExecutorAllocationManager.scala的start源代码:

1.           def start(): Unit = {

2.             listenerBus.addListener(listener)

3.          

4.             val scheduleTask = newRunnable() {

5.               override def run(): Unit = {

6.                 try {

7.                   schedule()

8.                 } catch {

9.                   case ct: ControlThrowable =>

10.                  throw ct

11.                case t: Throwable =>

12.                  logWarning(s"Uncaughtexception in thread ${Thread.currentThread().getName}", t)

13.              }

14.            }

15.          }

16.          executor.scheduleWithFixedDelay(scheduleTask,0, intervalMillis, TimeUnit.MILLISECONDS)

17.       

18.          client.requestTotalExecutors(numExecutorsTarget,localityAwareTasks, hostToLocalTaskCount)

19.        }

20.      ……

21.        private val executor =

22.          ThreadUtils.newDaemonSingleThreadScheduledExecutor("spark-dynamic-executor-allocation")

23.      …..

24.      // Polling loop interval (ms)

25.        private val intervalMillis: Long = 100

 

调整资源的时候考虑一下资源的粒度,增加Executor或减少Executor。一般情况下生产环境下给每个Executor分配的Cores是3到5个,通常设置奇数个。如果动态资源调整,不需要申请很多的Cores。从Spark streaming的角度考虑,Executor动态调整巨大的挑战是Spark streaming是按照Batch Duration的方式运行的,可能这个Batch Duration需要很多的资源,下一个Batch Duration就不需要那么多的资源,言外之意是如果调整资源的时候,还没来得及调整完,这个Batch Duration运行已经过期了。这个确实是问题,那调整周期的时间间隔,如Batch Duration 10 秒钟考虑增加或减少Executor,这也是非常简单的方式。

对你的数据规模进行评估,对已有资源是否闲置进行评估, Batch Duration的数据流进来,每个数据流进行分片的时候,可以计算已有的Core,如果不够,申请增加Executor,运行任务的时候可能分发到新申请的Executor上。也可检查上一个Batch Duration的处理时间,也是动态资源调整的依据。参照检查上一个Batch Duration的处理时间、流量,可以自己搞一套算法。如果在Batch Duration的时间范围之内,那很轻松的处理完,如果不在Batch Duration的时间范围之内,那需要更多的资源。也可以参考一下Spark Streaming的代码。StreamingContext就是一个class,StreamingContext 可以自定义,如可以定义一个类继承至StreamingContext ,命名的时候注意一下包。

StreamingContext.scala的源代码

1.          class StreamingContextprivate[streaming] (

2.             _sc: SparkContext,

3.             _cp: Checkpoint,

4.             _batchDur: Duration

5.           ) extends Logging {

 

关于动态控制消费速率,Sparkstreaming提供了一个弹性的机制,可以看一下流进来的数据和处理的数据的关系,是否来得及进行处理,如果不能来得及处理,会自己控制数据流进来的速度。这里有一个配置参数:spark.streaming.backpressure.enabled。建议打开这个参数。Sparkstreaming本身有一个关于rate的控制,在运行的时候手动调整流进的速度,如感知delay太严重了,就控制流进来的数据慢一点,如果能轻松的运行完,那就让Batch Duration流进更多的数据,既然我们自己可以观察,Spark streaming就提供一套算法,在数据流进来的数据和处理时间的比例关系,在某个特定比例下,让流进来的rate速率提高或者降低。

一个问题:如果可以动态控制消费速率,那资源是否不可以动态调整?这个不是的,可以同时开启资源的动态分配和速率的动态控制,都有自己的定时器,该怎么调整就会怎么调整。例如资源来不及分配,如果几次资源都来不及分配就可以动态控制数据消费的速率。为何专门搞一个动态的速率控制,一个很重要的原因,Spark streaming不太好控制的流式处理,不太适合做动态资源控制,因为一个Batch Duration变一下,下一个Batch Duration又变了,因此不合适。推荐使用backpressure动态速率控制,资源的动态控制比较适合于长时间耗时的任务,Spark streaming是一个又一个的微批处理,不适合资源的动态分配。流进的速度具体根据处理的延时和Batch或者windows的大小设定,不可能一下就调整得很完美的符合需要,这是不可能的。例如资源的动态分配,如果缺资源,不会一下就分配10个Executor,可能开始的时候分配一个Executor,再次运行发现还是不够,下次分配2个Executor,如果还是不够,下次就分配4个Executor,然后8个Executor,16个Executor,这个是算法。

具体内容可以看论文(AdaptiveStream Processing using Dynamic Batch Sizing 30多页)说的很清楚。




段智华 CSDN认证博客专家 Spark AI 企业级AI技术
本人从事大数据人工智能开发和运维工作十余年,码龄5年,深入研究Spark源码,参与王家林大咖主编出版Spark+AI系列图书5本,清华大学出版社最新出版2本新书《Spark大数据商业实战三部曲:内核解密|商业案例|性能调优》第二版、《企业级AI技术内幕:深度学习框架开发+机器学习案例实战+Alluxio解密》,《企业级AI技术内幕》新书分为盘古人工智能框架开发专题篇、机器学习案例实战篇、分布式内存管理系统Alluxio解密篇。Spark新书第二版以数据智能为灵魂,包括内核解密篇,商业案例篇,性能调优篇和Spark+AI解密篇。从2015年开始撰写博文,累计原创1059篇,博客阅读量达155万次
相关推荐
©️2020 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页
实付 19.90元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值