流式计算框架:Storm VS Spark Streaming
2015-01-23 17:49
483 查看
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:客户端进程,负责提交作业到MasterMaster: 主控节点,负责接收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 ArchitectureStorm总体框架分主从两种不同的节点,三种不同的daemom:Nimbus运行在主节点上,通关全局;从节点上运行Supervisor,管理相关节点上的任务;每个从节点上还有一系列的worker process来运行具体任务
Ø Spark & Spark Streaming
Spark ArchitectureSpark 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
TopologyStorm计算模型以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需要用户自己维护。
相关文章推荐
- 实时流式计算框架Storm 0.9.0发布通知(中文版)
- storm实时流式计算框架集群搭建过程
- 基于zookeeper和storm的车载流式计算框架
- storm实时流式计算框架集群搭建过程
- storm实时流式计算框架集群搭建过程
- storm实时流式计算框架集群搭建过程
- 实时流式计算框架Storm 0.9.0发布通知(中文版)
- 实时计算框架之一:Storm之框架搭建
- 流式计算之Storm简介
- 【流式计算】Twitter Storm: DRPC简介
- 流式计算之Storm简介
- 流式计算之Storm简介
- Storm:最火的流式处理框架
- 流式计算之Storm简介
- 流式计算框架
- 从Storm和Spark 学习流式实时分布式计算的设计
- 从Storm和Spark 学习流式实时分布式计算的设计
- 【流式计算】twitter storm Tutorial [2]
- 【流式计算】twitter storm Rationale[1]
- 【流式计算】Twitter Storm: 搭建storm集群