Flink、Storm与Spark Stream的区别
Apache Storm
- 在Storm中,需要先设计一个实时计算结构,我们称之为拓扑(topology)。之后,这个拓扑结构会被提交给集群,其中主节点(master node)负责给工作节点(worker node)分配代码,工作节点负责执行代码。在一个拓扑结构中,包含spout和bolt两种角色。数据在spouts之间传递,这些spouts将数据流以tuple元组的形式发送;而bolt则负责转换数据流。
Apache Spark
- Spark Streaming,即核心Spark API的扩展,不像Storm那样一次处理一个数据流。相反,它在处理数据流之前,会按照时间间隔对数据流进行分段切分。Spark针对连续数据流的抽象,我们称为
DStream
(Discretized Stream)。DStream是小批处理的RDD(弹性分布式数据集)
, RDD则是分布式数据集,可以通过任意函数和滑动数据窗口(窗口计算)进行转换,实现并行操作。
Apache Flink
- 针对
流数据+批数据
的计算框架。把批数据看作流数据的一种特例,延迟性较低(毫秒级),且能够保证消息传输不丢失不重复。
- Flink创造性地统一了流处理和批处理,
作为流处理看待时输入数据流是无界的,而批处理被作为一种特殊的流处理
,只是它的输入数据流被定义为有界的。Flink程序由Stream和Transformation这两个基本构建块组成,其中Stream是一个中间结果数据,而Transformation是一个操作,它对一个或多个输入Stream进行计算处理,输出一个或多个结果Stream
。
这三种计算框架的对比如下
扩展
- 我们怎样选择一款低延迟、exactly once、流和批统一的,能够支撑足够大体量的复杂计算的引擎。
- Spark streaming 的本质还是一款基于 microbatch 计算的引擎。这种引擎一个天生的缺点就是每个 microbatch 的调度开销比较大,当我们要求越低的延迟时,额外的开销就越大。这就导致了 Spark streaming 实际上不是特别适合于做秒级甚至亚秒级的计算。
- Storm 是一个没有批处理能力的数据流处理器,除此之外 Storm 只提供了非常底层的 API,用户需要自己实现很多复杂的逻辑。另外,Storm 在当时不支持 exactly once。
- 最后, Flink所满足的需求:
- 1)不同于 Spark,
Flink 是一个真正意义上的流计算引擎
,和 Storm 类似,Flink 是通过流水线
数据传输实现低延迟的流处理; - 2)Flink 使用了经典的 Chandy-Lamport 算法,能够在满足低延迟和低 failover 开销的基础之上,完美地解决 exactly once 的目标;
- 3)如果要用一套引擎来
统一流处理和批处理,那就必须以流处理引擎为基础
。Flink 还提供了SQL/tableAPI
这两个 API,为批和流在 query 层的统一又铺平了道路。因此 Flink 是最合适的批和流统一的引擎; - 4)最后,Flink 在设计之初就非常在意性能相关的任务状态
state
和流控
等关键技术的设计,这些都使得用 Flink 执行复杂的大规模任务时性能更胜一筹。
- 1)不同于 Spark,
项目应用
- 对于spark而言他的优势就是机器学习,如果我们的场景中对实时要求不高可以考虑spark,但是如果是要求很高就考虑使用flink,比如对用户异常消费进行监控,如果这个场景使用spark的话那么等到系统发现开始预警的时候(0.5s),罪犯已经完成了交易,可想而知在某些场景下flink的实时有多重要。