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

Spark Streaming揭秘 Day9

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

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

解决的问题

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

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

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

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

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

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

解决负载均衡问题

如下代码是receiver的启动代码：

进入startReceiver

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

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

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

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

解决高可用问题

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

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

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

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

其他

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

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

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