《Kafka Stream》调研:一种轻量级流计算模式

本文涉及的产品
对象存储 OSS,20GB 3个月
对象存储 OSS,内容安全 1000次 1年
云备份 Cloud Backup,100GB 3个月
简介: 流计算,已经有Storm、Spark,Samza,包括最近新起的Flink,Kafka为什么再自己做一套流计算呢?Kafka Stream 与这些框架比有什么优势?Samza、Consumer Group已经包装了Kafka轻量级的消费功能,难道不够吗? 花了一些时间阅读[docs](http

Confluent Inc(原LinkedIn Kafka作者离职后创业公司)在6月份预告推出Kafka Stream,Kafka Stream会在Kafka 0.10版本中推出。

对于流计算,已经有Storm、Spark,Samza,包括最近新起的Flink,Kafka为什么再自己做一套流计算呢?Kafka Stream 与这些框架比有什么优势?Samza、Consumer Group已经包装了Kafka轻量级的消费功能,难道不够吗?

花了一些时间阅读docs 和一些PPT,写一份粗略的调研材料供大家参考。

什么是流计算?流是计算的一个连续计算类型

  1. Single:例如HTTP,发送一个Request请求、返回一个Response
    screenshot
  2. Batch:将一组作业提交给计算机,返回一组,优势是减少IO等待时间
    screenshot
  3. Stream:Batch异步过程,任务和任务之间没有明显的边界
    screenshot

流计算一般有哪些方式?

DIY 简单实现

以wordcount来作例子,我们可以启动一个server,内存中建立一个HashMap,把输入先分词,然后根据word视图更新HashMap。是不是很简单?但带来的问题是什么?

  • 如果挂了,数据都被清空,数据重复怎么办?
  • 如果数据量非常大,一块内存放不下怎么办?
  • 如果在多台机器上部署,如何保证分配策略和先后顺序?

我们把这些问题做一个分类,主要有这样几个:

  • 保序处理
  • 规模和切片
  • 异常恢复
  • 状态类计算(例如TopK,UV等)
  • 重新计算
  • 时间、窗口等相关问题

利用现有框架

比较成熟度的框架有:Apache Spark, Storm(我们公司开源Jstorm),  Flink, Samza 等。第三方有:Google’s DataFlow,AWS Lambda

现有框架的好处是什么?

强大计算能力,例如Spark Streaming上已经包含Graph Compute,MLLib等适合迭代计算库,在特定场景中非常好用。

问题是什么?

  • 使用起来比较复杂,例如将业务逻辑迁移到完备的框架中,Spark RDD,Spout等。有一些工作试图提供SQL等更易使用模式降低了开发门槛,但对于个性化ETL工作(大部分ETL其实是不需要重量级的流计算框架的)需要在SQL中写UDF,流计算框架就退化为一个纯粹的容器或沙箱。
  • 作者认为部署Storm,Spark等需要预留集群资源,对开发者也是一种负担。

screenshot

Kafka Stream定位是轻量级的流计算类库,简单体现在什么方面?

  • 所有功能放在Lib中实现,实现的程序不依赖单独执行环境

    • 可以用Mesos,K8S,Yarn和Ladmda等独立调度执行Binary,试想可以通过Lamdba+Kafka实现一个按需付费、并能弹性扩展的流计算系统,是不是很cool?
    • 可以在单集成、单线程、多线程进行支持
  • 在一个编程模型中支持Stateless,Stateful两种类型计算
  • 编程模型比较简洁,基于Kafka Consumer Lib,及Key-Affinity特性开发,代码只要处理执行逻辑就可以,Failover和规模等问题由Kafka本身特性帮助解决

个人感觉Kafka Lib是Samza一个增强版(Samza也是Linkedin与Kafka深度集成的流计算框架),将来可以替换Samza,但无法撼动Spark、Flink等语义上比较高级的流计算系统地位,只能做一些轻量级流处理的场景(例如ETL,数据集成,清洗等)。

Kafka Stream 例子

先来看一个例子,通过Kafka Stream代码开发:

screenshot

这里面做了这样几件事情:

  1. 构建了Kafka中数据序列化/反序列化方式
  2. 构建了2个计算节点

    • 分词(flatMapValues),并将结果根据Key来Map
    • Reduce(根据Key来计算结果)
  3. 将结果写到Kafka一个结果Topic中(增量方式)

在2个结算节点中,使用了一个Kafka Topic将计算结果序列化、并反序列化。相当于Map-Reduce中Streamline。

这段程序可以执行在一个Thread中,也可以执行在N台机器上,主要归结于Kafka Consumer Lib可以帮助对数据与计算解耦分离。

基本概念

Processor:Processor是一个基本的计算节点

public interface Processor<K, V> {
void process (K key, V Value);
void punctuate(long time stampe);
}

Stream: Processor 处理后后结果输出

两者的关系如图:

screenshot

Kafka Stream如何解决流计算中6个问题:

保序(Ordering)

对Kafka而言,在一个Partition(Shard)下,数据是先进先出严格有序的,因此不是问题。
screenshot

分区与规模(Partition & Scalability)

流计算规模取决于2个因素:数据是否能线性扩容、计算能否线性扩容。

数据

Kafka中的数据通过Partition方式划分,每个Partition严格有序,可以做到弹性伸缩(实际上目前版本中弹性伸缩是不完整的,Kafka在0.10版本中能提供完全弹性伸缩的能力)。

screenshot

计算

Kafka对于消费端提供Consumer Group功能,可以扩展消费Instance达到与Partition同样的水平扩展能力,过程中保证一个消费Instance只能消费一个Partition。

screenshot

故障恢复(Fault Tolerance)

Kafka Consumer Group已实现了负载均衡,因此当有消费实例crash时也能保证迅速未完成的任务,过程中数据不丢,可能会重复(取决于消费checkpoint配合)

screenshot

状态处理(State)

这个问题相对比较复杂,在流计算场景中,分为两类计算:

  • Stateless(无状态):例如Filter,Map,Joins,这些只要数据流过一遍即可,不依赖于前后的状态
  • Stateful(有状态):主要是基于时间Aggregation,例如某段时间的TopK,UV等,当数据达到计算节点时需要根据内存中状态计算出数值

Kafka Stream 提供了一个抽象概念KTable,KStream来解决状态存储和数据变化的问题,见下面的章节解释。

重放(Reprocessing)

在了解了RedoLog和State后,重放这个概念并不难理解

screenshot

基于时间窗口计算(Time, Windowsing)

时间是流计算的一个重要熟悉,因为在现实过程中数据采集往往并不是很完美的,历史数据的到来会打断我们对计算的假设。时间有两个概念:

  • Event Time: 物理时间中的客观时间,代表事件发生时的一刻
  • Processing Time: 实际处理的时间(到达服务器时间)

虽然Processing Time对处理比较容易,但因历史数据的影响,采用Event Time更为准确。一个零售业中比较典型的场景是:统计每10分钟内每个产品的销量(或网站每个时间点UV、PV的统计)。销售数据可能会从不同的渠道实时流入,因此我们必须依赖于销售数据产生的时间点来作为窗口,而不是数据达到计算的点。

screenshot

Kafka Stream用一种比较简单粗暴方式来解决这个问题,他会给每个windows一个状态,这个状态只是代表当前时刻的数值,当有新数据达到该窗口时,状态就被改变了。对于windows based aggregation,Kafka Stream做法是:

Table (状态数据) + Library = Stateful Service

Stream & Table

为了实现状态的概念,Kafka 抽象了两种实体Kstream, KTable

  • Stream 等同于数据库中Change log
  • Table 等同于数据库在一个时间点Snapshot,两个不同的Snapshot之间通过1个或多个changelog造成

screenshot

假设有2个流,一个流是送货,另外一个流是销售,我们对着两个流进行Join,获得当前的库存状态:

shipment stream:

item ID store code count
10 CA 200
23 NY 50
23 CA 101
54 WA 1000

sale stream:

item ID store code count
10 CA 20
23 NY 10

当这两个流中的记录先后达到情况下,会影响库存状态,整个库存的变化状态如下:

screenshot

我们把这两个流放到Kafka Stream中,就会看到一个Processor节点中的状态变化如下:

screenshot

基于状态数据,我们可以在该节点定义处理的逻辑:

if (state.inventory[item].size < 10)
{
notify the manager;
}
else if (state.inventory[item] > 100)
{
on sale;
}

KTable,KStream可能比较抽象,KafkaStream包装了high-level DSL,直接提供了filter, map, join等算子,当然如果有个性化需求可以使用更低抽象程度API来完成。

粗浅的看法

流计算场景中,是否会有两个极端:复杂内存操作+迭代计算,轻量级数据加工与ETL。这两个比例分别占据多少?在我们常用的ETL场景里,大部分其实是轻量级Filter,LookUP,Write Storage等操作,有时候我们为了对数据做加工,不得不借助一个执行容器去选择流计算的框架。Docker,Lamdba可以解决这类问题,但需要有一定流计算的开发量。

我觉得对轻量级ETL场景,一个而理想的架构是Kafka Stream这样的轻量级计算库+Lamdba,这样就能做到安全按需使用的流计算模式。

Kafka Stream有一些关键东西没有解决,例如在join场景中,需要保证来源2个Topic数据Shard个数必须是一定的,因为本身做不到MapJoin等技术。在之前的版本中,也没有提供EventTime等Meta字段。

目录
相关文章
|
5月前
|
消息中间件 存储 Kafka
深入解析Kafka中的动态更新模式
深入解析Kafka中的动态更新模式
92 0
|
1月前
|
消息中间件 存储 监控
Kraft模式下Kafka脚本的使用
【9月更文挑战第9天】在Kraft模式下,使用Kafka脚本涉及以下几个关键步骤:启动Zookeeper和Kafka服务、创建主题、发送与消费消息、查看主题列表及描述主题详情。通过指定配置文件与相关参数,如`--replication-factor`和`--partitions`,可以灵活管理主题。此外,确保根据实际需求调整配置文件中的参数,并监控日志以维持最佳性能与及时问题处理。
|
2月前
|
消息中间件 负载均衡 Kafka
【Kafka消费秘籍】深入了解消费者组与独立模式,掌握消息消费的两种超能力!
【8月更文挑战第24天】Apache Kafka是一款高性能的分布式消息系统,支持灵活多样的消费模型以适应不同的应用场景。消息按主题组织,每个主题可划分为多个分区,确保消息顺序性。本文深入探讨了Kafka中的两大核心消费模式:消费者组(Consumer Group)和独立消费者(Standalone Consumer)。消费者组允许多个消费者协同工作,实现负载均衡及故障恢复,是最常用的消费模式。独立消费者模式则适用于需要高度定制化处理逻辑的场景,如消息重放等。通过对比这两种模式的特点和提供的示例代码,开发者可以根据具体需求选择最合适的消费策略,从而更好地利用Kafka构建高效的数据流应用程序。
49 3
|
4月前
|
消息中间件 负载均衡 监控
Kafka消费者:监听模式VS主动拉取,哪种更适合你?
Kafka消费者:监听模式VS主动拉取,哪种更适合你?
60 1
|
4月前
|
消息中间件 监控 大数据
揭秘Kafka:大数据和流计算领域的高可用利器
**Kafka是分布式流处理平台,以高效、可伸缩和消息持久化著称。其高可用性通过分区和副本机制实现:每个分区有Leader和Follower副本,Leader处理请求,Follower同步数据。当Leader故障时,ZooKeeper协助选举新Leader,确保服务连续。Kafka适用于大数据处理、流计算和日志分析,但异步处理可能导致延迟,不适合极高实时性场景,并且管理和配置复杂。**
101 0
|
4月前
|
消息中间件 存储 Kafka
深入解析Kafka中的动态更新模式
深入解析Kafka中的动态更新模式
67 0
|
5月前
|
消息中间件 负载均衡 大数据
【夏之以寒-Kafka专栏 01】Kafka的消息是采用Pull模式还是Push模式?
Kafka采用Pull模式为主,消费者主动拉取消息,保证控制和灵活性;同时融合Push模式,如自动Partition再分配和有序消息传递,实现高可用和负载均衡。专栏提供全面资源和面试题,助力Kafka学习。
94 0
|
5月前
|
消息中间件 缓存 负载均衡
【Kafka】Kafka 消息的消费模式
【4月更文挑战第5天】【Kafka】Kafka 消息的消费模式
|
5月前
|
消息中间件 负载均衡 监控
Kafka消费者:监听模式VS主动拉取,哪种更适合你?
Kafka消费者:监听模式VS主动拉取,哪种更适合你?
269 0
|
5月前
|
消息中间件 存储 Kafka
Kafka - 消息队列的两种模式
Kafka - 消息队列的两种模式
171 0