流式计算框架：Storm VS Spark Streaming

1.      概述

         略

2. 技术实现

2.1 原语定义

Ø  Storm

Tuple: 处理数据流中的最小单位；==> Record；

Topology: 数据流向的有向拓扑图；图中节点间的连线标识数据流动的方向；

Spout: tuple流的生产对象；

Bolt: 流的处理节点。处理input tuple流并产生多条输出流；

Nimbus: 集群master 节点，负责job分发，同时监听集群状态；

Supervisor: 集群Slave节点，富足监听分配到本节点的job，根据需要启动和关闭worker进程；

Worker: 执行topology的工作进程；

Task: spout/bolt的处理线程

Ø  Spark Streaming

Client:客户端进程，负责提交作业到Master

Master: 主控节点，负责接收Client提交的作业，管理Worker，并调度Worker启动Driver和Executor

Worker：Standalone模式中slave节点上的守护进程，负责管理本节点的资源，定期向Master汇报心跳，接收Master的命令，启动Driver和Executor

Driver：一个Spark作业运行时包括一个Driver进程，也是作业的主进程，负责作业的解析、生成Stage并调度Task到Executor上。包括DAGScheduler，TaskScheduler

Executor：即真正执行作业的地方，一个集群一般包含多个Executor，每个Executor接收Driver的命令Launch Task，一个Executor可以执行一到多个Task

RDD(ResilientDistributed Datasets): 是一个容错的、并行的数据结构，可以让用户显式地将数据存储到磁盘和内存中，并能控制数据的分区。

DStream: Sequence of RDD

Stage：一个Spark作业一般包含一到多个Stage

Task：一个Stage包含一到多个Task，通过多个Task实现并行运行的功能

DAGScheduler：实现将Spark作业分解成一到多个Stage，每个Stage根据RDD的Partition个数决定Task的个数，然后生成相应的Task set放到TaskScheduler中

TaskScheduler：实现Task分配到Executor上执行

2.2 系统框架

Ø  Storm

Storm High Level Architecture

         Storm总体框架分主从两种不同的节点，三种不同的daemom：Nimbus运行在主节点上，通关全局；从节点上运行Supervisor，管理相关节点上的任务；每个从节点上还有一系列的worker process来运行具体任务

Ø  Spark & Spark Streaming

Spark Architecture

         Spark Streaming是构建在spark上处理Streaming数据的框架。Spark总体框架和storm一样，也分为主从两种节点，主节点负责Job的接收与分发，管理Worker进程，并调度worker启动Executor或Driver（deploy mode:Cluster）；从节点启动WorkerDeamon，负责节点资源管理和Execute调度。

         以上都是基于Spark standalone方式部署集群。

 

         基于Yarn部署的Spark集群，架构与任务调度见下图。

         这里Spark AppMaster相当于Standalone模式下的SchedulerBackend，Executor相当于standalone的ExecutorBackend，spark AppMaster中包括DAGScheduler和YarnClusterScheduler。

 

         SparkStreaming基于Spark的数据处理模型，增加了时间窗口数据切片，数据处理流程如下：

2.3 数据流处理方式

Ø  Storm

Topology

         Storm计算模型以Topology为单位，计算最小粒度为tuple。数据在Spout/Bolt间传输是one at atime，因此storm实时处理的延迟在秒以内。

Ø  Spark Streaming

         SparkStreaming处理某个时间窗口内的时间流，数据流向与具体的计算逻辑有关。同时因为Spark Streaming是小批量job处理，因此延迟一般在秒级。

2.4 系统容错性

Ø  Storm

         Storm通过tuple间的anchoring，以及处理后的ack机制保证一个tuple被完全处理，从而保证消息不丢失。Storm保证所有消息至少被消费一次（可能会重复消费），在trident topology增加了数据可靠性保证，确保所有消息只消费一次，但是以性能下降为代价，而且通常需要业务保障。

 

         Storm是无状态的，可以快速恢复。目前的storm版本中，Nimbus没有实现HA。

Ø  Spark Streaming

         在容错数据保证方面的权衡是，Spark Streaming提供了更好的支持容错状态计算。Spark Streaming只需要在批级别进行跟踪处理，因此可以有效地保证每个mini-batch将完全被处理一次，同时，RDD数据接口保存了数据流处理的lineage，保证了数据不会因为节点故障丢失—数据源数据不丢失。

 

         Spark可以配置基于zookeeper的standbymasters，通过zookeeper支持Spark master的Leader Election机制。

2.5 API支持

Ø  Storm

         Storm提供Java API，但监听数据源、消息处理、结果输出都需要业务实现。

Ø  Spark Streaming

         SparkStreaming主要以Scala实现，API提供java支持。

         同时，在数据源方面，SparkStreaming提供了基于Kafka、Flume等中间件的消息监听接口；在数据处理操作中，Spark提供了两种API接口：transformations和action.

         Transformations接口有

Transformation	Meaning
map(func)	对每一个元素执行func方法
flatMap(func)	类似map函数，但是可以map到0+个输出
filter(func)	过滤
repartition(numPartitions)	增加分区，提高并行度
union(otherStream)	合并两个流
count()	统计元素的个数
reduce(func)	对RDDs里面的元素进行聚合操作，2个输入参数，1个输出参数
countByValue()	针对类型统计，当一个Dstream的元素的类型是K的时候，调用它会返回一个新的Dstream，包含<K,Long>键值对，Long是每个K出现的频率。
reduceByKey(func, [numTasks])	对于一个(K, V)类型的Dstream，为每个key，执行func函数，默认是local是2个线程，cluster是8个线程，也可以指定numTasks
join(otherStream, [numTasks])	把(K, V)和(K, W)的Dstream连接成一个(K, (V, W))的新Dstream
cogroup(otherStream, [numTasks])	把(K, V)和(K, W)的Dstream连接成一个(K, Seq[V], Seq[W])的新Dstream
transform(func)	转换操作，把原来的RDD通过func转换成一个新的RDD
updateStateByKey(func)	针对key使用func来更新状态和值，可以将state该为任何值

        

         Action接口：原生支持Hadoop输出 // TODO

Output Operation	Meaning
print()	打印到控制台
foreachRDD(func)	对Dstream里面的每个RDD执行func，保存到外部系统
saveAsObjectFiles(prefix, [suffix])	保存流的内容为SequenceFile
saveAsTextFiles(prefix, [suffix])	保存流的内容为文本文件
saveAsHadoopFiles(prefix, [suffix])	保存流的内容为hadoop文件

 

         同时SparkStreaming原生支持时间长度窗口，但起始时间无法指定…

2.6 其他

         SparkStreaming运行在spark之上，这样可以基于同样的代码(或做很小变动)处理实时/离线计算；而storm只能处理实时计算需求，离线数据计算需要单独部署其他应用，如MR;

 

         同样因为Spark Streaming与Spark批处理和交互模式共享同样的API，因此SparkStreaming对机器学习算法库/图计算算法库的支持也更方便；Storm需要用户自己实现相关逻辑。

 

         Sparkstreaming和storm都可以基于mesos/yarn部署集群。

3. 应用场景

3.1 Storm应用

         Storm的应用领域主要包括：

1.      信息流处理：实时处理新数据和更新数据库

2.      连续结算

3.      分布式远程过程调用

        

         在淘宝，storm被广泛用来进行实时日志处理，出现在实时统计、实时监控、实时推荐等场景中。一般来说，Storm一般从类kafka等消息中间件或者基于hbase的timetunnel中读取实时日志消息，加工处理的结果推送至分布式存储或者消息中间件中，提供延迟在秒级以内的实时数据查询；

3.2 Spark Streaming应用

         SparkStreaming在互联网企业的应用场景与spark类似，主要也是用于实时日志分析。但是因为spark提供了类似于流join的APIs，使得需求实现的复杂度大大降低。但是由于spark Steaming的处理逻辑是batch commit，因此实时性不如Storm；

         同时SparkStreming维护了一个时间长度窗口，storm需要自己开发维护时间窗口。

4. 总结

Ø  Storm和Spark Streaming应用场景类似，在互联网企业中大多用于实时日志分析、实时监控等业务。但是storm的实时性优于spark steaming（Storm延迟在秒级，Spark Streaming一般在10+秒至分钟级别）；spark streaming多应用于准实时计算场景，storm用于实时应用场景

Ø  Spark streaming基于spark框架，因此可以利用spark提供的丰富API和高灵活性，可以精简的实现高复杂的算法；同样基于spark，可以保证业务逻辑在实时处理和批处理上的复用；Storm则不然。

Ø  Spark Steaming提供是时间长度窗口，Storm需要自己维护时间窗口。

Ø  Spark Streaming API支持计算结果sink到HDFS等分布式文件系统，storm需要用户自己维护。