Spark Streaming应用与实战全攻略

、一、背景与架构改造

1.1 问题描述

有一块业务主要是做爬虫抓取与数据输出，通过大数据这边提供的SOA服务入库到HBase,架构大致如下：

架构改造之前

以对于以上的架构存在一些问题，我们可以看见数据在Dubbox服务阶段处理后直接通过HBase API入库了HBase，中间并没做任何缓冲，要是HBase出现了问题整个集群都完蛋，没法写入数据，数据还丢失，HBase这边压力也相当大，针对这一点，对入库HBase这个阶段做了一些改造。

1.2 架构改造

改造后的架构，爬虫通过接口服务，入库到Kafka，Spark streaming去消费kafka的数据，入库到HBase.核心组件如下图所示：

架构改造图

为什么不直接入库到HBase，这样做有什么好处？

缓解了HBase这边峰值的压力，并且流量可控；
HBase集群出现问题或者挂掉，都不会照成数据丢失的问题；
增加了吞吐量。

1.3 为什么选择Kafka和Spark streaming

由于Kafka它简单的架构以及出色的吞吐量；
Kafka与Spark streaming也有专门的集成模块；
Spark的容错,以及现在技术相当的成熟。

二、通过代码实现具体细节，并运行项目

然后就开始写代码了，总体思路就是：

put数据构造json数据，写入Kafka；
Spark Streaming任务启动后首先去Zookeeper中去读取offset,组装成fromOffsets；
Spark Streaming 获取到fromOffsets后通过KafkaUtils.createDirectStream去消费Kafka的数据；
读取Kafka数据返回一个InputDStream的信息，foreachRDD遍历，同时记录读取到的offset到zk中；
写入数据到HBase。

详细一点的架构图

2.1 初始化与配置加载

下面是一些接收参数，加载配置，获取配置中的topic，还有初始化配置，代码如下：

只是需要注意一下，这里的KafkaCluster，需要把源码拷贝过来，修改一下，因为里面有些方法是私有的。copy过来后改为public即可。

2.2 链接ZK

注意：这里的ZKStringSerializer，需要把源码拷贝过来，修改一下。

2.3 组装fromOffsets

组装fromOffsets，createDirectStream接收的是一个map的结构，所以可以支持多个topic的消费。

2.4 通过createDirectStream接受数据

使用KafkaUtils里面的createDirectStream方法去消费kafka数据，createDirectStream使用的是kafka简单的Consumer API，所以需要自己去管理offset,我们把offset写入到zk中，这样也方便了一些监控软件读取记录。

2.5 入库

入库HBase：

插入数据到具体HBase数据库：

2.6 运行并查看结果

运行命令：

运行后可以去spark UI中去查看相关运行情况，UI中具体细节见下文。

Streaming Statistics数据统计图

Completed Batches

三、对Streaming监控的介绍以及解决实际问题

这部分主要在代码运行起来的情况下来看一下任务的运行情况主要是streaming的监控界面，以及我们怎么去通过监控界面发现问题和解决问题。

3.1 监控

官网中指出，spark中专门为SparkStreaming程序的监控设置了额外的途径，当使用StreamingContext时，在WEB UI中会出现一个”Streaming”的选项卡：

WEB UI中的“Streaming”选项卡

在此选项卡内，统计的内容展示如下：

Streaming 状态图

Spark streaming 处理速度为3s一次，每次1000条。

Kafka product 每秒1000条数据，与上面spark consumer消费者恰好相等。结果：数据量大导致积压，这个过程中active Batches会越变越大。

因为忽略了实际的Processing time：

Active Batches

Completed Batches

Streaming Batches对应的趋势图

这其中包括接受的记录数量，每一个batch内处理的记录数，处理时间，以及总共消耗的时间。在上述参数之中最重要的两个参数分别是Porcessing Time 以及 Scheduling Delay：

Porcessing Time用来统计每个batch内处理数据所消费的时间
Scheduling Delay用来统计在等待被处理所消费的时间

如果PT比SD大，或者SD持续上升，这就表明此系统不能对产生的数据实时响应，换句话来说就是，出现了处理时延，每个batch time 内的处理速度小于数据的产生速度。在这种情况下，读者需要想法减少数据的处理速度，即需要提升处理效率。

3.2 问题发现

在我做压测的时候， Spark streaming 处理速度为3s一次，每次1000条。

Kafka product每秒1000条数据，与上面spark consumer消费者恰好相等。于是就会数据量大导致积压，这个过程中active Batches会越变越大。最后发现了一个问题：

Streaming Batches对应的趋势图

当压测峰值过后Input Size=0 events，时间仍然不减，奇怪！

Streaming Batches一些异常情况图

查看摸个具体stage：

Streaming具体的stage信息

从图中, 我们可以看到Spark总共调度分发了两批次task set, 每个task set的处理(含序列化和压缩之类的工作)都不超过100毫秒，那么该Stage何来消耗4s呢？慢着，貌似这两批次的task set分发的时间相隔得有点长啊，隔了4秒左右。为什么会隔这么就才调度一次呢？

此处要引入一个配置项“spark.locality.wait”(默认等待3s)，它配置了本地化调度降级所需要的时间。这里概要补充下Spark本地化调度的知识，Spark的task一般都会分发到它所需数据的那个节点，这称之为”NODE_LOCAL”，但在资源不足的情况下，数据所在节点未必有资源处理task，因此Spark在等待了“spark.locality.wait”所配置的时间长度后，会退而求其次，分发到数据所在节点的同一个机架的其它节点上，这是“RACK_LOCAL”。当然，也有更惨的，就是再等了一段“spark.locality.wait”的时间长度后，干脆随便找一台机器去跑task，这就是“ANY”策略了。

Streaming 源码

官网解释：How long to wait to launch a data-local task before giving up and launching it on a less-local node. The same wait will be used to step through multiple locality levels (process-local, node-local, rack-local and then any). It is also possible to customize the waiting time for each level by setting spark.locality.wait.node, etc. You should increase this setting if your tasks are long and see poor locality, but the default usually works well.

而从上例看到, 即使用最差的”ANY”策略进行调度，task set的处理也只是花了100毫秒，因此，没必要非得为了”NODE_LOCAL”策略的生效而去等待那么长的时间，特别是在流计算这种场景上。所以把“spark.locality.wait”果断调小，从1秒到500毫秒，最后干脆调到100毫秒算了。

spark-submit –master yarn-client –conf spark.driver.memory=256m –class com.KafkaDataStream –num-executors 1 –executor-memory 256m –executor-cores 2 –conf spark.locality.wait=100ms hspark-1.0.jar

调了之后的处理时间为0.7s：