Kafka - 带有批处理数据和流的事件之间的区别

Posted 2023-03-10

【中文标题】Kafka - 带有批处理数据和流的事件之间的区别

【英文标题】：Kafka - Difference between Events with batch data and Streams

【发布时间】：2020-01-26 14:45:29

【问题描述】：

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

注意：question 的 cmets 中有一些信息，但我希望得到更全面的答案。

【参考方案1】：

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

流：每个感兴趣的事件都会立即发送到流。因此，那些单个事件是细粒度的，规模较小。 带有数据批处理的事件：多个单个事件聚合成一个更大的批处理，当批处理达到一定大小、经过一定时间或业务事务完成时，批处理事件被发送到流。因此，这些 batch 事件的粒度更粗且更大（r）。

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

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

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

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

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

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

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