Spark Streaming揭秘 Day9 从Receiver的设计到Spark框架的扩展

Spark Streaming揭秘 Day9

从Receiver的设计到Spark框架的扩展

Receiver是SparkStreaming的输入数据来源,从对Receiver整个生命周期的设计,我们可以充分领略到Spark框架设计之巧妙,废话少说,让我们来看代码。

解决的问题

在开始之前,让我们先明确一个概念,就是Receiver于inputDStream之间的关系,从如下代码中,我们可以看到,receiver其实是由inputDStream映射得到的,也就是说Receiver和inputDStream是一一对应的。
Snip20160515_27

让我们需要明确一下需要解决的问题,或者说设计的目标。

Receiver其实是一个独立的应用程序,一边不断从外部数据源接收数据,一边向进行数据存储。以如下SocketInputStream为例,其实就是一个标准的Socket数据接收程序。
Snip20160515_26

那么,作为一个应用程序,如何在集群上进行运行就是一个要解决的问题。
通过前面几讲的说明,我们知道,在Spark中是将Receiver作为一个Job来进行运行的。
但是如果只是简单的作为一个Job来运行,因为Spark core并不知道Receiver的特殊性,所以可能在一个executor上启动多个receiver,这时候会出现两个非常大的问题:

  1. 由于会与其他应用Job共同调度,负载可能不均衡。
  2. 如果receiver启动失败的话,可能导致整个应用程序无法工作,无法保证高可用。

事实上,对整个Receiver运行的设计,我们就是要突破Spark本身限制,解决这两个关键的问题。

解决负载均衡问题

如下代码是receiver的启动代码:
Snip20160515_33

进入startReceiver
Snip20160515_32

通过上面两段代码,我们可以看到两点。

  1. 每个Receiver的启动都会触发一个作业。
  2. 在启动作业时,是基于scheduledLocation来决定运行的位置。

首先,分开作业,可以起到很好的隔离作用,不同receiver互相不会发生影响,并且可以在最大程度负载均衡.
其次,利用RDD可自定义的机制,通过对scheduledLocation的操作,其实SparkStreaming是把负载均衡的策略掌握到了自己手里,而不是使用Spark自身的机制!!!

让下面看下scheduledLocation的生成,策略本身比较复杂,从注释我们可以看到,主要还是会以当前最小负载的原则进行分配,从而确保Receiver尽可能的分布。
Snip20160515_34

解决高可用问题

高可用的设计目标,简单来说,就是只要集群存在,我们希望receiver一定启动成功。

在这里,比较巧妙的使用了Job启动的回调机制,可以看到,当失败时会自动进行重启操作,只要集群在运行,就会进行永无休止的重试。
Snip20160515_36

那Spark原生的重试限制如何解决呢,在如下代码中,实际上是把Spark原生的重试机制进行了短路,和负载均衡类似,将这一机制控制到SparkStreaming手中,绕开了重试次数的限制。
Snip20160515_35

最后,在重试机制中,使用了future的语法,使得重试在缓冲线程池中运行,支持并发启动,还可以控制负载。
Snip20160515_37

其他

说实话,我是有点被这段代码震到了,SparkStreaming中采用了一组非常简洁的代码,就扩展了Spark框架,并解决了一系列其实是在分布式系统中非常通用的问题,真是精彩绝伦!!!

欲知后事如何,且听下回分解

DT大数据每天晚上20:00YY频道现场授课频道68917580

posted @ 2016-05-15 20:13  哎哟慰  阅读(888)  评论(1编辑  收藏  举报