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

如今，有许多可用的开源流框架。 有趣的是，几乎所有它们都是相当新的，仅在最近几年才开发出来。 因此，对于新手来说，很容易混淆流框架之间的理解和区分。 在本文中，我将首先大致讨论流处理的类型和方面，然后比较最受欢迎的开源流框架：Flink，Spark流，Storm，Kafka流。 我将尝试（简要地）解释它们的工作原理，它们的用例，优势，局限性，异同。

什么是流/流处理：我发现的最优雅的定义是：一种数据处理引擎，其设计时考虑了无限的数据集。 而已。

与批处理不同，批处理以工作中的开始和结束为数据边界，而工作是在处理有限数据之后完成的，而流处理则意味着连续不断地处理无限制的数据，这些数据连续几天，数月，数年甚至是永远。 这样一来，流媒体应用程序始终需要启动和运行，因此难以实现且难以维护。

流处理的重要方面：

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

· 交付保证：这意味着无论如何，流引擎中的特定传入记录都将得到处理的保证。 可以是Atleast-once（一次，即使发生故障也将至少处理一次），Tomost-once（如果发生故障则可能不会被处理）或Exactly-once（一次处理，并且即使是一次也仅处理一次） 失败）。 显然，只希望一次，但是很难在分布式系统中实现，并且需要权衡性能。

· 容错：如果发生诸如节点故障，网络故障等故障，框架应该能够恢复并应该从其离开的位置重新开始处理。 这是通过不时检查流向某些持久性存储的状态来实现的。 例如 从卡夫卡获取记录并对其进行处理后，将检查点卡夫卡抵消给动物园管理员。

· 状态管理：在有状态处理要求的情况下，我们需要保持某种状态（例如，记录中看到的每个不同单词的计数），框架应该能够提供某种机制来保存和更新状态信息。

· 性能：这包括延迟（可以多久处理一条记录），吞吐量（每秒处理的记录数）和可伸缩性。 延迟应尽可能小，而吞吐量应尽可能大。 很难同时获得两者。

· 高级功能：事件时间处理，水印，窗口化这些功能是流处理要求复杂时所需的功能。 例如，根据在源中生成记录的时间来处理记录（事件时间处理）。 要了解更多详细信息，请阅读Google家伙Tyler Akidau的必读文章：part1和part2。

· 成熟度：从采用角度来看，重要的是，该框架已经过大公司的验证并经过了大规模的测试。 更有可能获得良好的社区支持并在堆栈溢出方面提供帮助。

流处理的两种类型：

现在了解了我们刚刚讨论的术语，现在很容易理解，有两种方法可以实现Streaming框架：

本机流：也称为本机流。 这意味着每条到达的记录都会在到达后立即处理，而无需等待其他记录。 有一些连续运行的过程（根据框架，我们称之为操作员/任务/螺栓），这些过程将永远运行，每条记录都将通过这些过程进行处理。 示例：Storm，Flink，Kafka Streams，Samza。

微批处理：也称为快速批处理。 这意味着每隔几秒钟将传入的记录分批处理，然后以单个小批处理的方式处理，延迟几秒钟。 示例：Spark，Storm。

这两种方法都有其优点和缺点。原生流很自然，因为每条记录在到达时都会被处理，从而使框架实现了尽可能小的延迟。 但这也意味着在不影响吞吐量的情况下很难实现容错，因为对于每条记录，一旦处理，我们就需要跟踪和检查点。 而且，状态管理很容易，因为有长时间运行的进程可以轻松维护所需的状态。

另一方面，微批处理则完全相反。 容错是免费提供的，因为它本质上是一个批处理，吞吐量也很高，因为处理和检查点将在一组记录中一次性完成。 但这会花费一定的等待时间，并且不会感觉像是自然的流式传输。 高效的状态管理也将是维持的挑战。

流框架一对一：

Storm：Storm是流媒体世界的产物。 它是最古老的开源流框架，也是最成熟和可靠的框架之一。 这是真正的流传输，适合基于简单事件的用例。 我在以下帖子中详细分享了有关Storm的详细信息：part1和part2。

优点：

· 极低的延迟，真正的流，成熟和高吞吐量

· 非常适合简单的流媒体用例

缺点

· 没有状态管理

· 没有高级功能，例如事件时间处理，聚合，开窗，会话，水印等

· 一次保证

Spark Stream：

Spark已成为批处理中hadoop的真正继任者，并且是第一个完全支持Lambda体系结构的框架（在该框架中，实现了批处理和流传输；实现了正确性的批处理；为速度而流化）。 它非常受欢迎，成熟并被广泛采用。 Spark Streaming是随Spark免费提供的，它使用微批处理进行流媒体处理。 在2.0版本之前，Spark Streaming有一些严重的性能限制，但是在新版本2.0+中，它被称为结构化流，并具有许多良好的功能，例如称为钨的自定义内存管理（如flink），水印，事件时间处理支持等。 另外，结构化流更为抽象，在2.3.0版本中，可以选择在微批量和连续流模式之间进行切换。 连续流模式有望带来像Storm和Flink这样的子延迟，但是它仍处于起步阶段，操作上有很多限制。

优点：

· 支持Lambda架构，Spark免费提供

· 高吞吐量，适用于不需要亚延迟的许多使用情况

· 由于微批量性质，默认情况下具有容错能力

· 简单易用的高级API

· 庞大的社区和积极的改进

· 恰好一次

缺点

· 不是真正的流媒体，不适合低延迟要求

· 要调整的参数太多。 很难做到正确。 在调整Spark Streaming时写了一篇关于我的个人经历的文章

· 天生无国籍

· 在许多高级功能方面落后于Flink

Flink：

Flink也来自类似Spark这样的学术背景。 Spark来自加州大学伯克利分校，而Flink来自柏林工业大学。 像Spark一样，它也支持Lambda架构。 但是实现与Spark完全相反。 虽然Spark本质上是一个批处理，其中Spark流是微批处理，并且是Spark Batch的特例，但Flink本质上是一个真正的流引擎，将批处理视为带边界数据流的特例。 尽管两个框架中的API都是相似的，但是它们在实现上没有任何相似之处。 在Flink中，诸如map，filter，reduce等的每个函数都实现为长时间运行的运算符（类似于Storm中的Bolt）

Flink看起来像是Storm的真正继承者，就像Spark批量继承了hadoop一样。

优点：

· 开源流媒体领域的创新领导者

· 具有所有高级功能（例如事件时间处理，水印等）的第一个True流框架

· 低延迟，高吞吐量，可根据要求进行配置

· 自动调整，无需调整太多参数

· 恰好一次

· 被Uber，阿里巴巴等大型公司广泛接受。

缺点

· 比赛进行得很晚，最初缺乏采用

· 社区不如Spark大，但现在正在快速发展

· 截至目前，尚无人采用Flink Batch，仅流行于流媒体。

Kafka Streams：

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

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

Kafka Streams的一个主要优点是它的处理是完全精确的端到端。 可能是因为来源和目的地都是Kafka以及从2017年6月左右发布的Kafka 0.11版本开始，仅支持一次。 要启用此功能，我们只需要启用一个标志即可使用。 有关此处和此处共享的更多详细信息。

优点：

· 重量很轻的库，适合微服务，IOT应用

· 不需要专用集群

· 继承卡夫卡的所有优良特性

· 支持流连接，内部使用rocksDb维护状态。

· 恰好一次（从Kafka 0.11开始）。

缺点

· 与卡夫卡紧密结合，在没有卡夫卡的情况下无法使用

· 婴儿期还很新，尚待大公司测试

· 不适用于繁重的工作，例如Spark Streaming，Flink。

Samza：

简短介绍一下Samza。 从100英尺高的萨姆扎（Samza）看上去与卡夫卡Stream（Kafka Streams）相似。 有很多相似之处。 这两个框架都是由同一位开发人员开发的，这些开发人员在LinkedIn实施了Samza，然后在他们创建Kafka Streams的地方成立了Confluent。 这两种技术都与Kafka紧密结合，从Kafka获取原始数据，然后将处理后的数据放回Kafka。 使用相同的Kafka Log哲学。 Samza是Kafka Streams的缩放版本。 Kafka Streams是用于微服务的库，而Samza是运行在Yarn.Advantages上的完整框架集群处理。

· 在使用rocksDb和kafka日志维护大型信息状态（适用于连接流的用例）方面非常好。

· 使用Kafka属性的容错和高性能

· 如果已在处理管道中使用Yarn和Kafka，则要考虑的选项之一。

· 好纱民

· 低延迟，高吞吐量，成熟并经过大规模测试

缺点：

· 与Kafka和Yarn紧密相连。 如果这些都不在您的处理管道中，则不容易使用。

· 至少一次加工保证。 我不确定它是否像Kafka 0.11之后的Kafka Streams现在完全支持一次

· 缺乏高级流功能，例如水印，会话，触发器等

流框架比较：

我们只能将技术与类似产品进行比较。 尽管Storm，Kafka Streams和Samza现在对于更简单的用例很有用，但具有最新功能的重量级产品之间的真正竞争显而易见：Spark vs Flink

当我们谈论比较时，我们通常会问：给我看数字:)

基准测试是仅当第三方进行比较时比较的好方法。

例如，一个古老的基准标记就是这个。 但这是在Spark Streaming 2.0之前的时候，它受到RDD的限制并且项目钨没有到位。现在在Structured Streaming 2.0版本发布之后，Spark Streaming试图追赶很多东西，而且似乎很难 奋斗。

最近，基准测试已成为Spark和Flink之间的一场激烈争吵。

Spark最近与Flink进行了基准测试比较，Flink开发人员对Flink开发人员进行了另一项基准测试，之后由Spark成员编辑了该帖子。

最好不要相信这些天的基准测试，因为即使很小的调整也可以完全改变数字。 没有什么比决定之前尝试和测试自己更好。 到目前为止，很明显，Flink在流分析领域处于领先地位，它具有大多数期望的方面，例如精确一次，吞吐量，延迟，状态管理，容错，高级功能等。

之所以能够实现这些功能，是因为Flink的一些真正创新，例如轻量级快照和堆外自定义内存管理.Flink的一个重要问题是成熟度和采用水平，直到一段时间之前，但现在Uber，阿里巴巴，CapitalOne等公司正在使用Flink流 大规模证明Flink Streaming的潜力。

最近，Uber开源了他们最新的称为AthenaX的流分析框架，该框架基于Flink引擎构建。 在本文中，他们讨论了如何将流分析从STorm迁移到Apache Samza，再到现在的Flink。

如果您已经注意到，需要注意的重要一点是，所有支持状态管理的本机流框架（例如Flink，Kafka Streams，Samza）在内部都使用RocksDb。 RocksDb从某种意义上说是独一无二的，它在每个节点上本地保持持久状态，并且性能很高。 它已成为新流媒体系统的关键部分。 我在先前的一篇文章中分享了有关RocksDb的详细信息。

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

这是最重要的部分。 诚实的答案是：这取决于:)重要的是要记住，对于每个用例，没有一个处理框架可以成为万灵丹。 每个框架都有其优点和局限性。 尽管如此，凭借一些经验，他仍然会分享一些有助于制定决策的建议：

· 取决于用例：如果用例很简单，那么如果学习和实现起来很复杂，则无需寻求最新，最好的框架。 在很大程度上取决于我们愿意为想要的回报投入多少。 例如，如果它是基于事件的简单IOT事件警报系统，那么Storm或Kafka Streams可以很好地使用。

· 现有技术堆栈：更重要的一点是考虑现有技术堆栈。 如果现有堆栈的首尾相连是Kafka，则Kafka Streams或Samza可能更容易安装。 同样，如果处理管道基于Lambda架构，并且Spark Batch或Flink Batch已经到位，则考虑使用Spark Streaming或Flink Streaming是有意义的。 例如，在我以前的项目之一中，我已经在管道中添加了Spark Batch，因此，当流媒体需求到来时，选择需要几乎相同的技能和代码库的Spark Streaming相当容易。

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

结论：

Apache Streaming空间的发展速度如此之快，以至于在信息方面，此职位可能在几年后已经过时。 目前，Spark和Flink在开发方面是领先的重量级人物，但仍有一些新手可以加入比赛。 Apache Apex是其中之一。 还有一些我没有介绍的专有流解决方案，例如Google Dataflow。 我的这篇文章的目的是帮助流媒体新手以最少的术语理解流媒体的一些核心概念，以及流行的开源流媒体框架的优点，局限性和用例。 希望该帖子对您有所帮助。

快乐流！

您可以在Linkedin和Quora上关注我

(本文翻译自chandan prakash的文章《Spark Streaming vs Flink vs Storm vs Kafka Streams vs Samza : Choose Your Stream Processing Framework》，参考：)