首页 > 解决方案 > Kafka - 具有批处理数据和流的事件之间的区别

问题描述

附加了一批数据的事件和偶尔发送数据的 kafka 流之间的根本区别是什么?它们可以互换使用吗?我什么时候应该使用第一个,什么时候使用后者?你能提供一些简单的用例吗?

注意:这个问题的评论中有一些信息,但我会要求更全面的答案。

标签: apache-kafkaevent-driven-design

解决方案


我假设您正在考虑的带有批处理数据的流和事件之间的“差异”:

  • 流:每个感兴趣的事件都会立即发送到流。因此,这些单独的事件是细粒度的,规模较小(呃)。
  • 带有数据批的事件:多个单独的事件聚合成一个更大的批,当批达到一定大小、经过一定时间或业务事务完成时,将批事件发送到流中。因此,这些批处理事件的粒度更粗且更大(r)。

以下是我能想到的特征列表:

  • 实时/延迟:单个事件的端到端处理时间通常会更短,而批处理事件的处理时间会更长,因为发布者可能会等待发送批处理事件,直到积累了足够的单个事件。

  • 吞吐量:消息代理的最大性能特征不同。# of in/out events / sec 在可比较的输入/输出数据量下。例如,比较 Kinesis 与 Kafka,Kinesis 的最大值较低。# in/out events / sec 它可以处理的比微调的 Kafka 集群。因此,如果您要使用 Kinesis,批处理事件可能更有意义,以根据单个事件的数量来实现所需的吞吐量。注意:据我所知,Kinesis 客户端库具有一个功能,可以在需要/可能增加吞吐量时透明地批处理单个事件。

  • 顺序和相关性:如果多个单独的事件属于一个业务事务并且需要由消费者一起处理和/或可能按顺序处理,那么批处理事件可能会使这项任务变得更容易,因为所有相关数据都立即可供消费者使用。对于单个事件,您必须采取适当的措施,例如选择适当的分区键,以保证单个事件按顺序处理,并且可能由同一个消费者工作者实例处理。

  • 失败案例:如果批处理事件包含独立的单个事件,则可能会发生批处理中单个事件的子集无法处理(与临时或永久失败无关)。在这种情况下,消费者可能无法简单地重试整个事件,因为部分批处理事件已经导致状态更改。处理批处理事件的部分处理失败可能需要显式逻辑(=额外的努力) 。

要回答您的问题,这两者是否可以互换使用,理论上我会说是的,但是根据具体的用例,这两种方法中的一种可能会产生更好的性能或导致设计/代码/配置不太复杂。

如果我能想到更多不同的特征,我会编辑我的答案。


推荐阅读