SparkStreaming, StructedStreaming, KafkaStream,Storm,Flink 几大常见实时流计算引擎的对比

目前开源大数据实时计算引擎有很多选择,我们可以对他们大致分为流处理和 批处理

第一类是流处理(Native Streaming):这类引擎中所有的data在到来的时候就会被立即处理，一条接着一条（HINT： 狭隘的来说是一条接着一条，但流引擎有时会为提高性能缓存一小部分data然后一次性处理），其中的代表就是Storm,Samza,Flink,KafkaStream
第二类是批处理(micro-batch):数据流被切分为一个一个小的批次， 然后再逐个被引擎处理。这些batch一般是以时间为单位进行切分，单位一般是‘秒‘，其中的典型代表则是spark了，不论是老的spark DStream还是2.0以后推出的spark structured streaming都是这样的处理机制；另外一个基于Micro-batch实现的就是storm trident，它是对storm的更高层的抽象，因为以batch为单位，所以storm trident的一些处理变的简单且高效。此外还有Hive(MR),Flink都可以实现批

而同时支持流处理和批处理的计算引擎只有两种选择:Apache Flink和Apache Spark

从技术，生态等各方面的综合考虑。首先，Spark的技术理念是基于批来模拟流的计算。而Flink则完全相反，它采用的是基于流计算来模拟批计算。

从技术发展方向看，用批来模拟流有一定的技术局限性，并且这个局限性可能很难突破。而Flink基于流来模拟批，在技术上有更好的扩展性。从长远来看，用Flink可以做一个统一的、通用的大数据引擎作为未来的选型。

一,接下来先介绍一下Spark的两个实时计算框架SparkStreaming和StructuredStreaming的区别

 (1)执行模式

Spark Streaming以micro-batch的模式:以固定的时间间隔来划分每次处理的数据，在批次内以采用的是批处理的模式完成计算

Structed streaming有两种模式：1),Micro-batch模式:处理模式类似sparkStreaming的批处理，2),Continuous Processing模式:一种启动长时运行的线程从数据源获取数据，worker线程长时运行，实时处理消息。放入queue中，启动long-running的worker线程从queue中读取数据并处理。该模式下，当前只能支持简单的projection式（如map,filter,mappartitions等）的操作

(2)ApI

Sparkstreaming框架基于RDD开发，自实现一套API封装，程序入口是StreamingContext，数据模型是Dstream，数据的转换操作通过Dstream的api完成，真正的实现依然是通过调用rdd的api完成

Structed Streaming 基于sql开发，入口是sparksession，使用的统一Dataset数据集，数据的操作会使用sql自带的优化策略实现

(3)Time Based

SparkStreaming的处理逻辑是根据应用运行时的时间(ProcessingTime)进行处理,不能根据消息中自带的时间戳完成一些特殊的处理逻辑

StructedStreaming很大的改变是它加入了EventTime,WeaterMark等概念,在处理消息时,可以考虑消息本身的时间属性,同时,也支持基于运行时间的处理方式

(4)UI页面

SparkStreaming提供了内置的界面化的UI操作,便于观察应用运行,批处理时间,消息速率,是否延迟等信息

StructedStreaming则没有直观的UI页面

二,flink与spark和storm比较

从流处理的角度将flink与spark和storm这三个框架进行比较，会主要关注以下几点，后续的对比也主要基于这几点展开

1,功能性（Functionality）- 是否能很好解决流处理功能上的痛点 , 比如event time和out of order data。

2,容错性（Fault Tolerance）- 在failure之后能否恢复到故障之前的状态，并输出一致的结果；此外容错的代价也是越低越好，因为其直接影响性能。

3,吞吐量(throughputs)& 延时(latency)- 性能相关的指标，高吞吐和低延迟某种意义上是不可兼得的，但好的流引擎应能兼顾高吞吐&低延时。

功能性（Functionality）01.Event time&Window Operation①Event time

event time - 指数据或者事件真正发生时间 , 比如用户点击网页时产生一条点击事件的数据，点击时间就是这条数据固有的event time。

processing time - 指计算框架处理这条数据的时间。

spark DStream和storm 1.0以前版本往往都折中地使用processing time来近似地实现event time相关的业务。显然，使用processing time模拟event time必然会产生一些误差， 特别是在产生数据堆积的时候，误差则更明显，甚至导致计算结果不可用。在使用event time时，自然而然需要解决由网络延迟等因素导致的迟到或者乱序数据的问题。为了解决这个问题， spark、storm及flink都引入了watermark和lateness的概念。watermark: 是引擎处理事件的时间进度，代表一种状态，一般随着数据中的event time的增长而增长。比如 watermark(t)代表整个流的event time处理进度已经到达t， 时间是有序的，那么streaming不应该会再收到timestamp t’ < t的数据，而只会接受到timestamp t’ >= t的数据。 如果收到一条timestamp t’ < t的数据， 那么就说明这条数据是迟到的。lateness: 表示可以容忍迟到的程度，在lateness可容忍范围内的数据还会参与计算，超过的会被丢弃。②Window Operation下面主要比较在使用window的操作中，spark structured streaming 和flink对event time处理机制的不同。

flink

首先，我们结合图来看flink， 时间轴从左往右增大。当watermark WM处于时 间窗口区间内时，即WM ∈ [start, end] , event time落在窗口范围内的任何乱序数据都会被接受；随着WM的增长并超过了窗口的结束时间，但还未超过可容忍的lateness时间范围，即WM ∈ (window_end,window_end+ lateness]， 这时乱序数据仍然可以被接受； 只有当WM超过 window_end+lateness, 即WM ∈ (window_end+ lateness, ∞)， 迟到的数据将会被丢弃。

fiink中watermark的计算也比较灵活，可以选择build-in的（如最大时间戳），也可以通过继承接口自定义实现。此外，用户可以选择周期性更新或者事件触发更新watermark。spark

首先,spark中watermark是通过上一个batch最大的timestamp再减去lateness得到的，即watermark = Max(last batch timestamps) - lateness。当数据的event time大于watermark时，数据会被接受，否则不论这条数据属于哪个窗口都会被丢弃。细节请参考spark文档（http://t.cn/RaTnvVQ）。下面来比较一下两者实现细节上的不同：①lateness定义: 在spark中，迟到被定义为data的event time和watermark的比较结果，当data的event time < watermark时，data被丢弃；flink中只有在watermark > window_end + lateness的时候，data才会被丢弃。②watermark更新: spark中watermark是上个batch中的max event time，存在延迟；而在flink中是可以做到每条数据同步更新watermark。③window触发: flink中window计算会触发一次或多次，第一次在watermark >= window_end后立刻触发（main fire），接着会在迟到数据到来后进行增量触发。spark只会在watermark（包含lateness）过了window_end之后才会触发，虽然计算结果一次性正确，但触发比flink起码多了一个lateness的延迟。上面三点可见flink在设计event time处理模型还是较优的：watermark的计算实时性高，输出延迟低，而且接受迟到数据没有spark那么受限。不光如此，flink提供的window programming模型非常的灵活，不但支持spark、storm没有的session window，而且只要实现其提供的WindowAssigner、Trigger、Evictor就能创造出符合自身业务逻辑的window，功能非常强大。02.SQL API目前flink相比spark，对streaming sql的支持还是比较初级的。在当前最新1.2版本中，仅支持Selection、Projection、Union、Tumble，不支持Aggregation、 Join、Top N、 Sort。计划中1.3版本将支持 Window Aggregation(sum、max、 min、avg), 但依然不支持Distinct。相比flink，当前最新版本的spark structured streaming仅仅不支持Top N、Distinct。03.Kafka Source Integrationflink对于kafka的兼容性非常好，支持kafka 0.8、0.9、0.10；相反，spark structured streaming只支持kafka0.10或更高版本。04.Interoperation with Static Dataspark底层对static batch data和streaming data有共同的rdd抽象，完美兼容互操作。而flink中DataSet 和 DataStream是完全独立的，不可以直接交互。此外，flink还可以运行storm的topology，带来较强的移植性。另外一个有趣的功能是可以自由调整job latency and throughputs的取舍关系，比如需要high throughputs的程序可以牺牲latency来获得更大的throughputs。

容错性（Fault Tolerance）spark依赖checkpoint机制来进行容错，只要batch执行到doCheckpoint操作前挂了，那么该batch就会被完整的重新计算。spark可以保证计算过程的exactly once（不包含sink的exactly once）。storm的容错通过ack机制实现，每个bolt或spout处理完成一条data后会发送一条ack消息给acker bolt。当该条data被所有节点都处理过后，它会收到来自所有节点ack， 这样一条data处理就是成功的。storm可以保证数据不丢失，但是只能达到at least once语义。此外，因为需要每条data都做ack，所以容错的开销很大。storm trident是基于microbatched实现了exactly once语义。flink使用Chandy-Chandy-Lamport Algorithm 来做Asynchronous Distributed Snapshots（异步分布式快照），其本质也是checkpoint。如下图，flink定时往流里插入一个barrier（隔栏），这些barriers把数据分割成若干个小的部分，当barrier流到某个operator时，operator立即会对barrier对应的一小部分数据做checkpoint并且把barrier传给下游（checkpoint操作是异步的，并不会打断数据的处理），直到所有的sink operator做完自己checkpoint后，一个完整的checkpoint才算完成。当出现failure时，flink会从最新完整的checkpoint点开始恢复。

flink的checkpoint机制非常轻量，barrier不会打断streaming的流动，而且做checkpoint操作也是异步的。其次，相比storm需要ack每条data，flink做的是small batch的checkpoint，容错的代价相对要低很多。最重要的是flink的checkpoint机制能保证exactly once。

吞吐量和延迟（Throughputs& Latency）01.吞吐量（throughputs）spark是mirco-batch级别的计算，各种优化做的也很好，它的throughputs是最大的。但是需要提一下，有状态计算（如updateStateByKey算子）需要通过额外的rdd来维护状态，导致开销较大，对吞吐量影响也较大。storm的容错机制需要对每条data进行ack，因此容错开销对throughputs影响巨大，throughputs下降甚至可以达到70%。storm trident是基于micro-batch实现的，throughput中等。flink的容错机制较为轻量，对throughputs影响较小，而且拥有图和调度上的一些优化机制，使得flink可以达到很高 throughputs。下图是flink官网给出的storm和flink的benchmark，我们可以看出storm在打开ack容错机制后，throughputs下降非常明显。而flink在开启checkpoint和关闭的情况下throughputs变化不大，说明flink的容错机制确实代价不高。对比官网的benchmark，我们也进行了throughputs的测试，实测结果是flink throughputs是storm的3.5倍，而且在解除了kafka集群和flink集群的带宽瓶颈后，flink自身又提高了1.6倍。

02.延迟（latency）spark基于micro-batch实现，提高了throughputs，但是付出了latency的代价。一般spark的latency是秒级别的。storm是native streaming实现，可以轻松的达到几十毫秒级别的latency，在几款框架中它的latency是最低的。storm trident是基于micro-batch实现的，latency较高。flink也是native streaming实现，也可以达到百毫秒级别的latency。下图是flink官网给出的和storm的latency对比benchmark。storm可以达到平均5毫秒以内的latency，而flink的平均latency也在30毫秒以内。两者的99%的data都在55毫秒latency内处理完成，表现都很优秀。

3总 结

综合对比spark、storm和flink的功能、容错和性能（总结如下图）

不难发现， flink是一个设计良好的框架，它不但功能强大，而且性能出色。此外它还有一些比较好设计，比如优秀的内存管理和流控。但是，flink目前成熟度较低，还存在着不少问题，比如 SQL支持比较初级；无法像storm一样在不停止任务的情况下动态调整资源；不能像spark一样提供很好的streaming和static data的交互操作等。对于这些问题，flink社区还在积极的跟进，相信在更多公司和贡献者的共同努力下，flink会发展的越来越好

三,KafkaStreams

我个人在Hadoop之后接触的第一个大数据框架就是Spark，所以自然而然曾经对Spark Streaming有着特别的偏爱。但Spark Streaming作为micro-batch结构，天生不是纯正的“真”实时处理。有着秒级别的延时，并且每次处理单个micro-batch中的所有数据记录。相对而言，Flink和Kafka Streams则是真正意义上的实时处理，每次处理单个数据记录。

同时,当我在工作中频繁使用Kafka作为系统中的数据总线后，一些较为轻度的数据处理，比如 filter，aggregation， join 等，如果使用Spark Streaming，需要将Kafka topic中的数据导入Spark Streaming，结果处理后再重新导入Kafka中相应的topic，显得十分繁琐。而使用Kafka Streams可以便捷地从源topic取得数据，处理并放入另一个topic，所有工作可以在Kafka内部完成。Kafka Streams 直接集成于Kafka，因此不需要单独的集群来支持其运行，这大大减少了额外的维护成本.

SparkStreaming的工作原理: Spark Streaming接收实时输入数据流，并将数据分成多个批次，然后由Spark引擎对其进行处理，批量生成最终的结果流。Spark Streaming提供了一个被称为离散化数据流（discretized stream，缩写为DStream）的高级抽象，它代表了一个持续的数据流。DStream可以从诸如Kafka、Flume或Kinesis等来源的输入数据流中创建，或者通过对其他DStream执行高级操作来创建。在框架内部，DStream可以看成是一系列的RDD（Resilient Distributed Datasets，弹性分布式数据集）。

KafkaStreams工作原理:Kafka Streams是一个用于处理和分析数据的客户端库。它先把存储在Kafka中的数据进行处理和分析，然后将最终所得的数据结果回写到Kafka或发送到外部系统去。它建立在一些非常重要的流式处理概念之上，例如适当区分事件时间和处理时间、窗口支持，以及应用程序状态的简单（高效）管理。同时，它也基于Kafka中的许多概念，例如通过划分主题进行扩展。此外，由于这个原因，它作为一个轻量级的库可以集成到应用程序中去。这个应用程序可以根据需要独立运行、在应用程序服务器中运行、作为Docker容器，或通过资源管理器（如Mesos）进行操作。Kafka Streams直接解决了流式处理中的很多困难问题：毫秒级延迟的逐个事件处理。
有状态的处理，包括分布式连接和聚合。
方便的DSL。
使用类似DataFlow的模型对无序数据进行窗口化。
具有快速故障切换的分布式处理和容错能力。
无停机滚动部署。
Apache Spark可以与Kafka一起使用来传输数据，但是如果你正在为新应用程序部署一个Spark集群，这绝对是一个复杂的大问题。为了克服这个复杂性，我们可以使用完整的流式处理框架，Kafka streams正是实现这个目的的最佳选择。我们的目标是简化流式处理，使之成为异步服务的主流应用程序编程模型。这是我知道的第一个库，它充分利用了Kafka，而不仅仅把Kafka当做是一个信息中介。Streams建立在KTables和KStreams的概念之上，这有助于他们提供事件时间处理。给出一个与Kafka的核心抽象高度集成的处理模型，能够减少流式架构中移动件的总数。将状态表与事件流完全整合起来，并在单个概念框架中提供这两个东西，这使得Kafka Streams完全成为一个嵌入式的库，而不是流式处理集群（只是Kafka和你的应用程序）。当你向应用程序加入了一个新的实例，或者现有的实例发生崩溃的时候，它能够自动均衡负载，并维护表的本地状态，使得系统能够从故障中恢复出来。Kafka Streams具备低延迟的特点，并且支持易于使用的事件时间。它是一个非常重要的库，非常适合某些类型的任务。这也是为什么一些设计可以针对Kafka的工作原理进行深入地优化的原因。你不需要设置任何种类的Kafka Streams集群，也没有集群管理器。如果你需要实现一个简单的Kafka的主题到主题的转换、通过关键字对元素进行计数、将另一个主题的数据加载到流上，或者运行聚合或只执行实时处理，那么Kafka Streams适合于你。如果事件时间不相关，并且秒级的延迟可以接受，那么Spark是你的第一选择。它相当稳定，并且可以很容易地集成到几乎任何类型的系统中去。此外，每个Hadoop发行版都包含它。而且，用于批处理应用程序的代码也可以用于流式应用程序，因为API是相同的。结论我认为，Kafka Streams最适用于“Kafka > Kafka”场景，而Spark Streaming可用于“Kafka > 数据库”或“Kafka > 数据科学模型“这样的场景。