Kafka流在groupby之后减少到流在提交时发送部分减少输出[重复]

Question

我们遇到了一个问题，即在执行 groupby --> reduce --> toStream 时，当在 reduce 期间发生提交时，部分 reduce 值将被发送到下游。因此，如果要减少 65 个键，并且假设在我们完成一半时发生了一次提交，则输出将是两条消息：一条是部分减少，另一条是所有值都减少了。

下面是我们更详细的案例：

msg --> leftJoin
leftJoin --> flatMap //break msg into parts so we can join again downstream
flatMap --> leftJoin
leftJoin --> groupByKey
groupByKey --> reduce
reduce --> toStream
toStream --> to

目前，我们已经为此提出了一个非常丑陋的解决方案，它与在 flatMap 阶段创建的每条消息中添加索引和 out 值有关...我们过滤掉 reduce 发出的任何消息其中索引！= 出。我的感觉是我们没有在这里做某事或以错误的方式看待它。请告知正确的做法。

谢谢。

Answer 1

因此，如果要减少 65 个键，并且假设我们进行了一半的提交，则输出将是两条消息：一条是部分减少，另一条是所有值都减少。

如果我正确理解您的描述，这实际上是预期行为。一方面，这是处理延迟（您希望在有新的输入数据后立即查看更新记录）与将多个更新记录合并之间的权衡更少甚至只有一条更新记录。

Kafka Streams 的默认行为是倾向于降低处理延迟。也就是说，它不会在发送下游更新之前等待“所有输入数据都已到达”。相反，一旦新数据到达，它将发送更新。 https://www.confluent.io/blog/watermarks-tables-event-time-dataflow-model/ 描述了一些背景信息。

今天，您有两个主要的旋钮来更改/调整此默认行为，它们由 (1) Kafka Streams record caches (for the DSL) 和 (2) 配置的提交间隔（您已经提到过）控制。

展望未来，Kafka 社区还一直在开发一项新功能，该功能允许您定义只希望发送单个最终更新记录（而不是您所描述的“部分”更新）。如果您有兴趣，可以在 Kafka 改进提案KIP-328: Ability to suppress updates for KTables 中描述此新功能。这项工作正在积极进行中，但不太可能在 10 月即将发布的 Kafka v2.1 版本中及时完成。

目前，我们已经为此提出了一个非常丑陋的解决方案，它与在 flatMap 阶段创建的每条消息中添加索引和 out of 值有关...我们过滤掉 reduce 发出的任何消息其中索引！= 出。我的感觉是我们没有在这里做某事或以错误的方式看待它。请告知正确的做法。

简而言之，在流处理中，您应该接受流处理的本质。一般来说，你只会对世界有部分/不完整的知识，可以这么说，或者更确切地说：你只知道你到目前为止所观察到的。因此，在任何给定的时间点，您都必须处理可能会到达您仍然需要处理的更多额外数据的情况。

一种典型的情况是必须处理迟到的数据，您的应用程序逻辑必须决定您是要继续集成和处理这些数据（很可能）还是丢弃（有时是它需要的方式）。

回到你的例子：

所以如果要减少 65 个键 [...]

如何知道它是 65，而不是 100 或 28，等等？只能说：“到目前为止，在这个时间点，我收到了 65 个。那么，我该怎么办？我是不是因为我相信这就是全部输入而减少了这 65 个？还是做我多等了几秒/分钟/小时，因为可能还有 35 个到达，但这意味着我不会在等待时间过去之前向下游发送更新/答复（这会导致更高的处理延迟）？”

在您的情况下，我会问：您为什么认为如何/何时发送更新的流式传输行为是一个问题？可能是因为您的下游系统或应用程序不知道如何处理此类流式更新？

这有意义吗？同样，以上内容基于我对您所描述的问题的理解。