根据IBM Marketing cloud最近的一份报告，“当今世界上90％的数据是仅仅在过去的两年内产生的，每天创建2.5亿个字节的数据 - 随着新设备，传感器和技术的出现，数据增长率可能还会加速。
      从技术上讲，这意味着大数据处理将变得更加复杂和具有挑战性。许多用例（例如移动广告，欺诈检测，出租车预订，护理监控等）需要在数据到达时实时进行处理，以便做出快速可行的决策。这就是分布式流处理变得非常流行的原因。

    现在有许多开源流式计算框架可用。有趣的是，几乎所有这些框架都是在过去几年中发展起来的。因此，对于理解和区分流式框架而言，新人很容易混淆。在这篇文章中，我将首先讨论流式计算的种类和方方面面，然后再来比较最流行的开源流式计算框架：Flink，Spark Streaming，Storm，Kafka Streams。我将尝试解释它们如何工作（简要），它们的使用场景，优势，局限性，相似点和不同点。

什么是流式计算：

       最优雅的定义是：一种设计时考虑了无限数据集的数据处理引擎。
传统的批处理，数据以作业的开始和结束为界，并且作业在处理完有限数据后结束，Streaming用于处理连续数天，数月，数年和永久实时的无界数据。因此，总是意味着启动和运行，流应用程序很难实现并且难以维护。

流处理的重要方面：

为了理解Streaming框架的优点和局限性，我们应该注意与Stream处理相关的一些重要特征和术语： 

• Delivery Guarantees： 
  用何种方式保证流中的记录将被处理。它可以是Atleast-once（即使出现故障也至少会被处理一次），Atmost-once（在故障情况下可能不被处理）或Exactly-once（即使故障时也会处理且仅处理一次）。显然Exactly-once是我们想要的，但在分布式系统中难以实现，并且与性能进行权衡。
• 容错： 
  如果出现节点故障，网络故障等故障，框架应该能够恢复，并且应该从它挂掉的位置再次开始处理。这是通过不时的保存流处理的状态到持久化存储中来实现的。例如，在从Kafka获取记录并处理后，把offset保存到zookeeper。
• 状态管理：
  在状态处理要求的情况下，我们需要维护某些状态（例如记录中看到的每个不同单词的计数），框架应该能够提供一些机制来保存和更新状态信息。
• 性能：
  这包括延迟（可以多快处理记录），吞吐量（处理的记录/秒）和可伸缩性。延迟应尽可能小，而吞吐量应尽可能大。很难同时满足。
• 高级功能：事件时间处理，水印，窗口
  这些是处理复杂的流式计算所需要的功能。例如事件时间处理：处理数据时要考虑记录生成的时间。要了解更多详细的内容，请阅读谷歌Tyler Akidau的文章：第1部分和第2部分。
• 成熟度：
  如果框架已经过大公司的大规模应用和验证，那就很好了。更有可能获得良好的社区支持和stackoverflow的帮助。

 

两种类型的流处理：

   看过了上面列出的一些术语，现在应该很容易理解流式计算框架的两种类型： 

1. Native Streaming：
   也称为Native Streaming。这意味着每个传入的记录一到达就会被处理，而不必等待其他记录。有一些持续运行的进程（operators/tasks/bolts，不同框架有不同名称），每个记录都通过这些进程进行处理。例如：Storm，Flink，Kafka Streams，Samza。
   
2. 微批处理：
   也称为快速批处理。会将几秒内传入的记录一起批量处理，这会导致数据处理有几秒钟的延迟。例如：Spark Streaming，Storm-Trident。

两种方法都有一些优点和缺点。
Native Streaming因为在每个记录到达时就会被处理，因此能实现低延迟。但这也意味着很难在不影响吞吐量的情况下实现容错，我们需要在每条记录处理后马上跟踪记录处理状态。此外，状态管理很容易，因为长时间运行的进程可以轻松地维持所需的状态。

另一方面，微批处理恰恰相反。因为它本质上是一个批处理，所以容错很容易实现，吞吐量也很高。但它会以一些延迟为代价。有效的状态管理也将是一项挑战。

 

storm：

Storm是流式计算界的hadoop。它是最古老的开源流框架，也是最成熟，最可靠的框架之一。它是真正的流式计算，适用于简单的基于事件的场景·。有关Storm的详细信息请见：part1和part2。

优势：

• 极低的延迟，真正的流式计算，成熟和高吞吐量
• 非常适合简单场景

劣势：

• 没有状态管理
• 没有高级功能 
• Atleast-once

Spark Streaming：

Spark已经成为批处理中hadoop的真正继承者，也是第一个完全支持Lambda架构的框架（批处理和流式处理都实现了;批处理应对正确性要求高的场景，后者应对对处理速度要求高的场景）。它非常受欢迎，成熟并被广泛采用。Spark Streaming、Spark均可免费使用，它使用微批处理方式。在2.0发布之前，Spark Streaming有一些严重的性能局限，但是新版本2.0+，它被称为结构化流式处理，并提供了许多好的功能，如定制内存管理tungsten（类似flink的），水印，事件时间处理支持等。结构化流式处理也更抽象，在2.3.0版本中用户可以选择在micro-batching模式和 continuous streaming模式之间切换。 continuous streaming模式有望像Storm和Flink那样提供低延迟，但它仍处于初期阶段，在操作方面存在许多限制。

优点：

• 支持Lambda架构，Spark免费提供
• 高吞吐量，适用于不需要低延迟的场景
• 批处理模式默认容错 
• 简单易用的高级API 
• 大社区和积极的改进 
• Exactly Once

缺点：

• 不是真正的流式处理，不适合要求低延迟的场景
• 参数太多，调参困难。详见Spark Streaming调参有感 
• 无状态 
• 在许多高级功能中落后于Flink

Flink：

Flink也来自Spark类似的学术背景。Spark来自加州大学伯克利分校，Flink来自柏林大学。像Spark一样，它也支持Lambda架构。但实现方式与Spark完全相反。Spark本质上是一个批处理，Spark Streaming的微批处理只是Spark批处理的一种特殊情况，但Flink本质上是一个真正的流引擎，将批处理作为有界数据的流来处理。虽然两个框架中的API相似，但它们在实现中没有任何相似之处。在Flink中，map，filter，reduce等各项功能都是作为长时间运行的operator实现的（类似于storm中的Bolt）
Flink看起来像Storm的真正继承者，就像Spark在批处理领域继承了hadoop一样。

优点：

• 领域的创新领导者
• 第一个真正的流式处理框架，具有事件时间处理，水印等所有高级功能 
• 低延迟，高吞吐量，可根据要求进行配置 
• 自动调整，没有太多参数需要去调整 
• Exactly Once 
• 被阿里巴巴、uber等大公司广泛接受。

缺点：

• 出现的晚了一点，被使用的没有那么广泛
• 社区没有Spark那么大，但现在正以快节奏增长 
• 没有大公司采用了Flink的批处理，大家只乐意使用它的流式处理。

Kafka Streams：

与其他流式框架不同，Kafka Streams是一个轻量级的库。它对于从Kafka传输数据，进行转换然后发送回kafka非常有用。我们可以将它理解为类似于Java Executor服务线程池的库，但内置了对Kafka的支持。它可以与任何应用程序很好地集成，并且可以开箱即用。

由于其重量轻，可用于微服务类型的架构。Flink在性能方面没有匹配，但也不需要单独的集群运行，非常方便，易于部署和开始工作。内部使用Kafka Consumer小组并致力于Kafka日志哲学。
这篇文章彻底解释了Kafka Streams与Flink Streaming的使用案例。

好处： 

• 完全从Kafka 0.11起保证一次
• 非常轻量级的库，适用于微服务，物联网应用
• 不需要专用集群 
• 继承所有卡夫卡的优良特征 
• 支持Stream连接，内部使用rocksDb来维持状态。

缺点：

• 与卡夫卡紧密相连，如果没有卡夫卡，就无法使用
• 在婴儿期阶段相当新，尚未在大公司进行测试 
• 不适用于像Spark Streaming，Flink这样繁重的工作。 

Samza：

将简要介绍Samza。100英尺的Samza看起来非常类似于Kafka Streams。有很多相似之处。这两个框架都是从在LinkedIn上实现Samza的同一个开发人员开发的，然后创建了Confluent，他们编写了Kafka Streams。这两种技术都与Kafka紧密结合，从Kafka获取原始数据，然后将处理后的数据放回Kafka。使用相同的Kafka Log理念。Samza是Kafka Streams的缩放版本。虽然Kafka Streams是一个用于微服务的库，但是Samza是在Yarn上运行的完整的fledge集群处理。

好处 ：

• 非常适合使用rocksDb和kafka日志维护大型信息状态（适用于加入流的用例）。
• 使用Kafka属性的容错和高性能 
• 如果已经在处理管道中使用Yarn和Kafka，则需要考虑的一个选项。 
• 好纱公民 
• 低延迟，高吞吐量，成熟和大规模测试

缺点： 

• 与卡夫卡和纱线紧密结合。如果其中任何一个不在您的处理管道中，则不容易使用。
• 至少一次加工保证。虽然在谈到Exactly Once的Kafka 0.11发布后，它可能会改变。 
• 缺少高级流媒体功能，如水印，会话，触发器等

流媒体框架的比较：

我们只能将技术与同类产品进行比较。虽然Storm，Kafka Streams和Samza现在看起来对于更简单的用例更有用，但是具有最新功能的重量级人物之间的真正竞争是明确的：Spark与Flink 

 

当我们谈论比较时，我们通常会问：向我显示数字:) 
基准测试是只有在第三方完成比较时才能比较的好方法。

例如，其中一个旧的工作台标记是这样的。
但这有时候在Spark Streaming 2.0之前，当它有RDD限制并且项目钨没有到位时。
现在有了结构化流媒体2.0版本，Spark Streaming试图赶上很多，似乎将会有艰难的战斗。

最近基准测试有点成为Spark和Flink之间开放的猫战斗。
Spark最近与Flink进行了基准测试比较，Flink的开发人员用另一个基准测试做出了回应，之后Spark的人编辑了帖子。
最好不要相信这些天的基准测试，因为即使是一个小小的调整也可以完全改变数字。没有比在决定之前尝试和测试自己更好的了。
截至今天，很明显Flink正在引领Streaming Analytics领域，其中包括大部分所需的方面，如一次性，吞吐量，延迟，状态管理，容错，高级功能等。

这些都是可能的，因为有些Flink的真正创新就像轻量级快照和关闭堆自定义内存管理。
Flink的一个重要问题是成熟度和采用水平，直到某个时候，但现在Uber，Alibaba，CapitalOne等公司正在大规模使用Flink流媒体来证明Flink Streaming的潜力。
最近，优步开放了他们最新的流媒体分析框架，名为AthenaX，它建立在Flink引擎之上。在这篇文章中，他们讨论了他们如何将他们的流媒体分析从STorm迁移到Apache Samza到现在的Flink。

需要注意的一点是，如果您已经注意到，那么支持状态管理的所有本地流式传输框架（如Flink，Kafka Streams，Samza）都会在内部使用RocksDb。RocksDb在某种意义上是唯一的，它在每个节点上本地维护持久状态并且具有高性能。它已成为新流媒体系统的重要组成部分。我在之前的帖子中分享了有关RocksDb的详细信息。

如何选择最佳流媒体框架：

这是最重要的部分。诚实的答案是：它取决于:) 
重要的是要记住，没有一个处理框架可以成为每个用例的银弹。每个框架都有一些优势和一些限制。不过，凭借一些经验，我们将分享一些帮助做出决定的指示：

1. 取决于用例：
   如果用例很简单，如果学习和实现起来很复杂，则无需使用最新最好的框架。很大程度上取决于我们愿意为我们想要的回报多少投资。例如，如果它是简单的IOT类型的基于事件的警报系统，Storm或Kafka Streams可以完美地使用。
2. 未来的考虑因素： 
   与此同时，我们还需要有意识地考虑未来可能的用例是什么？未来可能会出现事件时间处理，聚合，流连接等高级功能的需求吗？如果答案是肯定或可能是，那么最好继续使用像Spark Streaming或Flink这样的高级流式传输框架。一旦投资并在一种技术中实施，其后期改变的成本很高且成本巨大。
   
   例如，在之前的公司中，我们从过去2年开始运行Storm管道，并且它的工作非常好，直到有一个要求来确定传入事件并仅报告唯一事件。现在这需要国家管理，而Storm本身并不支持。虽然我使用基于时间的内存中的hashmap实现了，但是有限制的是状态会在重启时消失。此外，它在这些变化中给出了问题，我在之前的一篇文章中分享了这些变化。我想说的是，如果我们试图自己实现框架没有明确提供的东西，我们必然会遇到未知问题。
3. 现有的技术堆栈：
   更重要的一点是考虑现有的技术堆栈。如果现有的堆栈端到端都有Kafka，那么Kafka Streams或Samza可能更容易适应。类似地，如果处理管道基于Lambda架构并且Spark Ba​​tch或Flink Batch已经到位，则考虑Spark Streaming或Flink Streaming是有意义的。例如，在我之前的一个项目中，我已经在管道中使用了Spark Ba​​tch，因此当流式传输需求出现时，很容易选择需要几乎相同技能和代码库的Spark Streaming。

简而言之，如果我们理解框架的优点和局限性以及我们的用例，那么更容易选择或至少过滤掉可用选项。最后，一旦选择了几个选项，就可以拥有POC。毕竟每个人都有不同的味蕾。

 

这篇是翻译自文献：https://why-not-learn-something.blogspot.com/2018/03/spark-streaming-vs-flink-vs-storm-vs.html，可能有些地方文法不通用词奇怪，凑合着看看吧，大概知道这几种流处理框架的异同就对了