1. spark steaming概述

在《spark 基础（上篇）》中，spark streaming是spark体系中的一个流式处理框架。因此，Spark streaming相对于其他流式处理框架就更有优势，用途更加广泛，它能够与spark sql、机器学习以及图像处理框架无缝连接。spark streaming还能够从多种数据源获得数据，同时，能够输出到多种不同的数据平台中，包括文件系统、数据库和实时数据展示平台dashboards。spark streaming的流处理框架如下图1所示：

图1 spark streaming的流处理框架

　　详细的处理流程如下图2所示，spark streaming接收实时数据流输入的数据流后，再将其划分为一个个batch（小批次数据流）供后续Spark engine处理，所以实际上，Spark Streaming是按一个个batch（小批次）来处理数据流的。

图2 spark streaming数据处理流程

　　说到spark streaming就不得不提Dstream，Dstream是spark中继spark core的RDD、spark sql的DataFrame和DataSet后有一基础的数据类型，是spark streaming特有的数据类型。DStream代表了一系列连续的RDD，DStream中每个RDD包含特定时间间隔的数据，存储方式为HashMap<Time,RDD>。其中，Time为时间序列，而RDD我们都很熟悉，它是spark core的基础数据结构。Dstream的结构如下图3所示：

图3 Dstream结构

　　对连续不断的streaming data流的多次切片，就会将流分成多个batch，单个batch内有一套针对多个Dstream的处理逻辑，每个batch的处理逻辑相同。这个处理逻辑相当于spark core对RDD的处理逻辑。针对RDD的处理中，DAGScheduler将DAGGraph按照宽窄依赖划分stage。每个batch内部也存在DstreamGraph，对Dstream的处理也类似于对RDD的处理。例如下图4所示，针对一段代码，在单个batch内部也会生成DstreamGraph和Dstream依赖。

图4 单个bath内部处理流程

　　针对一个spark streaming的处理流中的多个batch，处理逻辑如下图5所示。图中用虚线将左侧的streaming data流分成三个batch，每个batch的处理逻辑如右侧所示。

图5 streaming流批量处理流程

2. spark streaming工作原理

根据如上图5分析可知，spark streaming的大致工作流程如下：
　　首先，需要一个DAG的静态模板来定义batch内的执行逻辑。
　　其次，如上图2所示，针对实时的数据流来说， 还需要有控制器，不间断地将数据流分成多个batch，同时在每个batch内部应用DAG静态模板执行处理逻辑。
　　再次，要生成DStream，并不能像一般的数据源那样从存储介质中去读取，而是要从多种数据推送过来的数据，包括kafka、flume以及twitter等等。
　　最后，由于流式处理要不断地循环执行，保障任务的稳定性就显得尤其重要了。
　　因此，针对上述四种需要，spark streaming的整体执行流程就是围绕上述四个需求而设置的，其总体工作流程如下图6所示。如图中脚注，橙色部分显示DAG的静态定义部分，淡蓝色为控制器部分，负责流的拆分，同时执行橙色部分定义的静态模板。绿色部分显示了driver和executor的数据接收部分，最后的紫色部分，显示了spark streaming中很重要的稳定性保障功能，即checkpoint。

图６ spark streaming工作原理图

下面我们来简要介绍下每一部分的主要职责：
　　第一部分：如上图4和图5所示的步骤生成DstreamGraph和Dstream。
　　第二部分：JobScheduler是主要的控制器，负责动态任务的调度，包括JobGenerator和ReceiveTracker两个主要的成员。其中，JobGenerator主要负责将data streaming流按照程序中设置的时间间隔切分成多个batch，并按照静态的DstreamGraph为以后的每一个batch生成DstreamGraph。而ReceiveTracker则负责数据流的接收跟踪和控制，具体的实现见第三部分。
　　第三部分：RecevieTracker启动多个job，并分发到多个executor上。Executor启动ReceiverSupervisor，ReceiverSupervisor启动Receiver来接收数据，ReceiverSupervisor接到数据后，按块的形式存储，并将块的meta信息上报给ReceiverTracker。
　　第四部分：ReceiverTracker接收到块的meta信息后交给ReceivedBlockTracker去管理块信息。ReceivedBlockTracker 也采用 WAL 冷备方式进行备份，在 driver 失效后，由新的 ReceivedBlockTracker 读取 WAL 并恢复 block 的 meta 信息。
第四部分：这部分主要是处于稳定性的考虑，设置的checkpoint机制。因此，checkpoint需要将整个处理流程中的关键节点都做checkpoint，包括DstreamGraph，JobScheduler，数据块的meta信息以及块数据。

3. 与storm流处理框架对比

spark作为Apache spark开源框架的一部分，与当前流程的storm开源框架相比，主要存在以下差别：
1.处理时效
　　spark streaming处理的数据单位是某个时间窗口内的数据流，而storm是针对单条记录处理的。因此,spark streaming可能存在几秒钟的延迟，而storm的延迟能缩短到秒内。
2.容错机制
　　spark streaming有较好的容错机制，当单个节点发生故障后，它可以跟踪每批被处理的数据流，保证每批数据只被处理一次。storm则只能保证单条数据处理不会被遗漏，而却允许数据有重复被处理的现象。
3.运行平台
　　spark streaming和storm都可以运行在自己的集群上，spark streaming能同时运行在Yarn和Mesos集群上，而storm只能运行在Mesos上。