spark streaming框架简介

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。

图6 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上。

推荐阅读更多精彩内容