Kafka Stream 以及其他流处理框架对比

最新推荐文章于 2024-09-25 08:42:22 发布

weixin_30872337

最新推荐文章于 2024-09-25 08:42:22 发布

阅读量653

点赞数

文章标签：大数据 java 嵌入式

原文链接：http://www.cnblogs.com/zackstang/p/11522194.html

版权

1. Kafka Stream Introduction

假设我们需要对kafka 消息做流数据分析，例如：

对部分消息做过滤
每分钟计算一次收到了多少消息

这种情况下，对于消息过滤以及定时统计，甚至是进行流的合并，是几个基本的流式处理。但是在这种情况下，仅使用Kafka Producer 与 Consumer 很难实现这些功能，因为它们属于非常底层的API，并且并不是developer friendly 的API。在这种情况下，我们可以考虑使用Kafka Stream。

什么是Kafka Stream？

它是一个Kafka提供，进行数据处理与转换的库，有如下特点：

由Java 标准实现
不需要创建另一个独立的kafka集群
较好的扩展、弹性以及容错能力
可实现Exactly Once传输语义
每次处理一个条目（no batching），不像spark streaming那样是微批处理
适用于任何规模的应用

常规的Kafka Stream处理架构如下，其中producer端使用了开源的kafka connector：

2. Differences among various Streams

当前主流的流处理有：Storm，Spark Streaming，Flink以及Kafka Stream。

Storm

Storm是最早的流处理框架，它的优点在于：

第延时、true streaming、高吞吐
非常适合复杂度不高的流场景

缺点为：

无状态管理（no state management）
缺少更高级的功能，例如事件-时间处理、聚合、窗口、sessions、watermark等等
at-least-once 语义

Spark Streaming

Spark Streaming 非常流行，在Spark 2.0 之后的版本，称为结构化的流（structured streaming），性能提升了很多，并且增加了很多高级功能，例如定制的内存管理（tungsten），watermarks，事件事件处理等。

在2.3.0 版本之后，structured streaming除了可以（默认）使用micro-batching处理之外，还可以选择continuous streaming 模式。在micro-batching模式下，最低延时可达100ms，而在continuous streaming 模式下，最低延时可达几毫秒。在大部分real-time 应用场景下，micro-batching 的延时是可以接受的。不过如果有必要实现毫秒级别的延时（如信用卡交易欺诈之类的），则需要使用continuous streaming。

虽然spark streaming 的continuous streaming可以提供如Storm与Flink级别的低延时，不过它仅是一个预览版，尚未完全成熟。

Spark Streaming 的优点为：

支持Lambda架构，与Spark无缝连接
高吞吐，适用于大部分对延时要求不高的场景
默认实现的Fault tolerance（由原生的micro-batch提供）
简易使用的高级API
社区繁荣，更新频繁
Exactly Once 语义

缺点有：

并不是真正的流处理，不适用于低延时的场景
需要调整太多参数，很难调整到合适的参数
默认是Stateless streaming
在一些高级特性上，落后于Flink

Flink

Flink 是一个真正的流处理框架，它的优点为：

第一个真正的流处理框架，具有所有高级功能，例如事件-时间处理，watermarks，等
低延时、高吞吐，可以根据需求做配置
自适应，没有太多的参数需要调优
Excatly Once 语义
被大公司广泛使用

缺点有：

仅在Streaming中广泛使用，在Batch 场景中使用较少

Kafka Stream

Kafka Stream相较于其他所有流处理框架，是一个轻量级的库。常用于处理Kafka中的数据，做一些变换（transformation），然后发回Kafka。

由于它原生即为轻量级的，所以适用于一些微服务类型的架构中。kafka Stream的部署与使用非常简单，且并不需要额外建立一个集群去运行。它的内部使用的是Kafka Consumer group，与Kafka log 的机制共同实现流处理。

Kafka Stream一个最大的优点为：端到端的Exactly Once。启用时也仅需要启用一个flag即可。

它的优点有：

非常轻量级的库，适用于微服务，IOT应用
不需要一个dedicated cluster
继承了Kafka所有优点
支持Stream join，内部使用rocksDB管理state
Exactly Once语义（Kafka 0.11 以后的版本）

缺点为：

与Kafka 紧密联系，无法在没有Kafka 的场景下使用
相较于Spark Streaming、Flink，不适用于大型业务场景

3. Stream Comparison

当前主流使用的流处理框架其实仅有两种：Spark Streaming与Flink。所以其实真正的竞争也仅在这两者之间。

一般来说，我们在比较两者的性能时，会对比一些压测数据。不过这里的问题在于：两者的压测数据对比并不能很有效的说明两者孰优孰劣，因为一个很小的因素或是配置就有可能造成两者性能的不同。

抛开数据来看，我们可以明显看到的是：Flink在流处理框架中，为一个引领者的状态。例如它的exactly once，吞吐，延时，state management，fault tolerance，以及其他高级的功能等，均是由Flink引导。Flink中的各种底层实现如light weighted snapshots、off-heap custom memory management 可能也帮助它成就了今天的地位。并且我们现在也可以看到Flink已经在各大公司被广泛地使用了。

这里有一点需要提及的是：各个原生的流处理框架，如Flink，Kafka Stream，Samza 等这些支持state management的处理框架，内部均使用的是RocksDb存储state。其中一个原因就是RocksDB在每个节点上，locally maintains 持久化的state数据，并且性能特别好。

4. 如何选择Streaming Framework

在选择Streaming Frameworks时，首先需要了解的一点是：没有万能的Streaming Framework，一切的选择都是基于需求。

如果业务场景较为简单，并不需要最新的框架（存在学习成本以及实现成本）。则可以根据可投入的成本选择一个框架。例如，如果仅是需要一个基于IOT的事件的警报系统，则Storm，Kafka Stream就已经足够了。

如果业务场景中需要一些高级的功能，如状态管理，stream join，聚合等，则要使用更先进的流处理框架如Spark Streaming或是Flink。

基于当前业务使用的技术栈，若是整个业务使用的是Kafka 端到端，则使用Kafka Stream 或是Samza会更简单。同样，如果基于的是Lambda架构，或者业务中已经使用了Spark Batch或是Flink Bath，则可以相应考虑使用Spark或是Flink。

转载于:https://www.cnblogs.com/zackstang/p/11522194.html