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)& 延时(laten