Spark Streaming，Flink，Storm，Kafka Streams，Samza：如何选择流处理框架

根据最新的统计显示，仅在过去的两年中，当今世界上90％的数据都是在新产生的，天天建立2.5万亿字节的数据，而且随着新设备，传感器和技术的出现，数据增加速度可能会进一步加快。
从技术上讲，这意味着咱们的大数据处理将变得更加复杂且更具挑战性。并且，许多用例（例如，移动应用广告，欺诈检测，出租车预订，病人监护等）都须要在数据到达时进行实时数据处理，以便作出快速可行的决策。这就是为何分布式流处理在大数据世界中变得很是流行的缘由。api

现在，有许多可用的开源流框架。有趣的是，几乎全部它们都是至关新的，仅在最近几年才开发出来。所以，对于新手来讲，很容易混淆流框架之间的理解和区分。在本文中，我将首先大体讨论流处理的类型和方面，而后比较最受欢迎的开源流框架：Flink，SparkStreaming，Storm，KafkaStream。我将尝试（简要地）解释它们的工做原理，它们的用例，优点，局限性，异同。网络

什么是流/流处理：

流处理的最优雅的定义是：一种数据处理引擎，其设计时考虑了无限的数据集。架构

与批处理不一样，批处理以工做中的开始和结束为界，而工做是在处理有限数据以后完成的，而流处理则是指接二连三地处理天，月，年和永久到来的无边界数据。所以，流媒体应用程序始终须要启动和运行，所以难以实现且难以维护。框架

流处理的重要方面：分布式

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

• 交付保证：
  这意味着不管如何，流引擎中的特定传入记录都将获得处理的保证。能够是at least once（至少一次）（即便发生故障也至少处理一次），at most once : 至多一次（若是发生故障则可能不处理）或Exactly-once（即便失败在这种状况下也只能处理一次））。显然，只处理一次是最好的，可是很难在分布式系统中实现，而且须要权衡性能。
• 容错：
  若是发生诸如节点故障，网络故障等故障，框架应该可以恢复，而且应该从其离开的位置开始从新处理。这是经过不时检查流向某些持久性存储的状态来实现的。例如，从Kafka获取记录并对其进行处理后，将Kafka检查点偏移给Zookeeper。
• 状态管理：在有状态处理需求的状况下，咱们须要保持某种状态（例如，记录中每一个不重复单词的计数），框架应该可以提供某种机制来保存和更新状态信息。
• 性能：
  这包括延迟（能够多久处理一条记录），吞吐量（每秒处理的记录数）和可伸缩性。延迟应尽量小，而吞吐量应尽量大。很难同时得到二者。
• 高级功能：事件时间处理，水印，窗口化
  若是流处理要求很复杂，这些是必需的功能。例如，根据在源中生成记录的时间来处理记录（事件时间处理）。
• 成熟度：从采用的角度来看很重要，若是框架已通过大公司的验证和大规模测试，那就太好了。更有可能得到良好的社区支持并在堆栈溢出方面提供帮助。

流处理的两种类型：函数

如今了解了咱们刚刚讨论的术语，如今很容易理解，有两种方法能够实现Streaming框架：微服务

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

微批处理：
也称为快速批处理。这意味着每隔几秒钟就会将传入的记录分批处理，而后以单个小批处理的方式处理，延迟几秒钟。例如：Spark Streaming, Storm-Trident。性能

两种方法都有其优势和缺点。
原生流传输感受很天然，由于每条记录都会在到达记录后当即进行处理，从而使框架可以实现最小的延迟。但这也意味着在不影响吞吐量的状况下很难实现容错，由于对于每条记录，咱们都须要在处理后跟踪和检查点。并且，状态管理很容易，由于有长时间运行的进程能够轻松维护所需的状态。

另外一方面，微批处理则彻底相反。容错是免费提供的，由于它本质上是一个批处理，吞吐量也很高，由于处理和检查点将在一组记录中一次性完成。但这会花费必定的等待时间，而且感受不天然。高效的状态管理也将是维持的挑战。

流框架对比：

Storm :

Storm是流处理世界的强者。它是最古老的开源流框架，也是最成熟和可靠的框架之一。这是真正的流传输，适合基于简单事件的用例。

优势：

• 极低的延迟，真正的流，成熟和高吞吐量
• 很是适合简单的流媒体用例

缺点

• 没有状态管理
• 没有高级功能，例如事件时间处理，聚合，开窗，会话，水印等
• 一次保证

Spark Streaming :

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

优势：

• 支持Lambda架构，Spark免费提供
• 高吞吐量，适用于不须要亚延迟的许多使用状况
• 因为微批量性质，默认状况下具备容错能力
• 简单易用的高级API
• 庞大的社区和积极的改进
• 刚好一次

缺点

• 不是真正的流，不适合低延迟要求

• 要调整的参数太多。很难作到正确。

• 天生无国籍

• 在许多高级功能方面落后于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大，但如今正在快速发展

Kafka Streams :

与其余流框架不一样，Kafka Streams是一个轻量级的库。对于从Kafka流式传输数据，进行转换而后发送回kafka颇有用。咱们能够将其理解为相似于Java Executor服务线程池的库，但具备对Kafka的内置支持。它能够与任何应用程序很好地集成，而且能够当即使用。

因为其重量轻的特性，可用于微服务类型的体系结构。Flink在性能方面没有匹配之处，并且不须要运行单独的集群，很是方便而且易于部署和开始工做。

Kafka Streams的一个主要优势是它的处理是彻底精确的端到端。多是由于来源和目的地均为Kafka以及从2017年6月左右发布的Kafka 0.11版本开始，仅支持一次。要启用此功能，咱们只须要启用一个标志便可使用。

优势：

• 重量很轻的库，适合微服务，IOT应用
• 不须要专用集群
• 继承卡夫卡的全部优良特性
• 支持流链接，内部使用rocksDb维护状态。
• 刚好一次（从Kafka 0.11开始）。

缺点

• 与卡夫卡紧密结合，在没有卡夫卡的状况下没法使用
• 婴儿期还很新，尚待大公司测试
• 不适用于繁重的工做，例如Spark Streaming，Flink。

Samza :

简短介绍一下Samza。（Samza）看上去就像是（Kafka Streams）。有不少类似之处。这两个框架都是由同一位开发人员开发的，这些开发人员在LinkedIn上实现了Samza，而后在他们建立Kafka Streams的地方成立了Confluent。这两种技术都与Kafka紧密结合，从Kafka获取原始数据，而后将处理后的数据放回Kafka。使用相同的Kafka Log哲学。Samza是Kafka Streams的缩放版本。Kafka Streams是一个用于微服务的库，而Samza是在Yarn上运行的完整框架集群处理。
优势 ：

• 使用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之间的一场激烈争吵。

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

Flink的一个重要问题是成熟度和采用水平，直到一段时间以前，可是如今像Uber，Alibaba，CapitalOne这样的公司正在大规模使用Flink流传输，证实了Flink Streaming的潜力。

最近，Uber开源了其最新的流分析框架AthenaX，该框架基于Flink引擎构建。

若是您已经注意到，须要注意的重要一点是，全部支持状态管理的原生流框架（例如Flink，Kafka Streams，Samza）在内部都使用RocksDb。RocksDb从某种意义上说是独一无二的，它在每一个节点上本地保持持久状态，而且性能很高。它已成为新流系统的关键部分。

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

这是最重要的部分。诚实的答案是：这取决于 :

必须牢记，对于每一个用例，没有一个单一的处理框架能够成为万灵丹。每一个框架都有其优势和局限性。尽管如此，根据一些经验，他们仍然会分享一些有助于作出决定的建议：

1. 取决于用例：
   若是用例很简单，那么若是学习和实现起来很复杂，则无需寻求最新，最好的框架。在很大程度上取决于咱们愿意投资多少来换取咱们想要的回报。例如，若是它是基于事件的简单IOT事件警报系统，那么Storm或Kafka Streams很是适合使用。
2. 将来考虑因素：
   同时，咱们还须要对将来可能的用例进行自觉考虑。未来可能会出现对诸如事件时间处理，聚合，流加入等高级功能的需求吗？若是答案是确定的，则最好继续使用高级流框架（例如Spark Streaming或Flink）。一旦对一项技术进行了投资和实施，其变动的困难和巨大成本将在之后改变。例如，在以前的公司中，从过去的两年开始，Storm管道就已经启动并运行，而且在要求统一输入事件并仅报告惟一事件以前，它一直运行良好。如今，这须要状态管理，而Storm自己并不支持这种状态管理。虽然我使用基于时间的内存哈希表实现，可是在重启时状态会消失是有限制的。
3. 我要提出的观点是，若是咱们尝试自行实现框架未明确提供的某些内容，则势必会遇到未知问题。
4. 现有技术堆栈：
   另外一重要点是考虑现有技术堆栈。若是现有堆栈的首尾相连是Kafka，则Kafka Streams或Samza可能更容易安装。一样，若是处理管道基于Lambda架构，而且Spark Ba​​tch或Flink Batch已经到位，则考虑使用Spark Streaming或Flink Streaming是有意义的。例如，在我之前的项目中，我已经在管道中添加了Spark Ba​​tch，所以，当流需求到来时，选择须要几乎相同的技能和代码库的Spark Streaming很是容易。

简而言之，若是咱们很好地了解框架的优势和局限性以及用例，那么选择或至少过滤掉可用的选项就更加容易。最后，一旦选择了几个选项。毕竟每一个人都有不一样的选择。

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

更多实时数据分析相关博文与科技资讯，欢迎关注 “实时流式计算”