相同键的主题未能加入 Kafka 流

Question

我最近在流应用程序中遇到了一个我以前没有遇到过的问题，并且很难找到与键控/连接相关的问题（以及更新后的分区）。

我有两个主题（raw_events 和 processes_users），它们的键控相同，但是当我尝试对这两个主题执行连接时，尽管键控相同，但只有一些连接成功。

工作流程（用于上下文）

为简洁起见，应用程序的基本工作流程如下：

1. 数据通过 Producer 流入raw_event主题。
2. 一系列流应用程序监听raw_event主题并根据一系列业务规则从中提取各种实体（例如 IP 地址、用户等）
3. 从raw_event主题中识别的实体被放入preprocessing_{type}主题中，其中包含有关提取的元数据和在raw_event中找到的相关信息（例如，对于用户来说，这可能是帐户名称、电子邮件等。 ）。 这些主题中的项目由raw_event键入。
4. 另一系列的流应用程序将监听各种preprocessing_{type}主题，并与一系列 GlobalKTables 相结合，这些 GlobalKTables 代表该给定实体final_{type}的所有已知实例。 对于成功的连接，来自final_{type}的实例将使用来自raw_event/preprocessing_{type}主题的新信息进行丰富； 不成功的连接将指示给定类型的新实体，然后将其键入并放入final_{type}主题。 preprocessing_{type}的所有丰富实例都插入到processing_{type}主题中，该主题包含实体的丰富（或新）实例以及创建它的元数据。 最重要的是 - processed_{type}主题中的项目仍然由raw_event键入。
5. 最后，一个流应用程序运行并尝试通过加入到processing_{type}中来丰富原始实例，这将被键入相同的键，并raw_event raw_event ，然后将其推送到final_event话题。

问题

问题本身出现在上面的第 5 步（事件丰富）中，因为raw_event主题和processing_users主题之间只有一些连接按预期工作。

使用通过整个管道的 24 条记录的子集，主题中的 24 对中只有 5 对成功加入。 那些有效的似乎是相同的一致的，但我在数据中看不到任何表明为什么一个有效而另一个无效：

raw_event keys          processing_user keys
mawjuG0B9k3AiALz0_2S    0q0juG0B9k3AiALz8ApP 
xEEcv20B9k3AiALzEN0m    m60juG0B9k3AiALz5gU5 
zqwjuG0B9k3AiALzz_tg    ua0juG0B9k3AiALz7wqa 
v60juG0B9k3AiALz6Aal    xEEcv20B9k3AiALzEN0m 
0q0juG0B9k3AiALz8ApP    zqwjuG0B9k3AiALzz_tg 
RK0juG0B9k3AiALz5QUw    zK0juG0B9k3AiALz6Aal
0a0juG0B9k3AiALz6Aal    Ta0juG0B9k3AiALz5QUw 
8KwjuG0B9k3AiALz1v58    RKwjuG0B9k3AiALz1P7C 
c60juG0B9k3AiALz5gU4    -60juG0B9k3AiALz3gGn 
RKwjuG0B9k3AiALz1P7C    Va0juG0B9k3AiALz5QUw 
zK0juG0B9k3AiALz6Aal    560juG0B9k3AiALz3QGh 
Ta0juG0B9k3AiALz5QUw    mawjuG0B9k3AiALz0_2S 
Va0juG0B9k3AiALz5QUw    -K0juG0B9k3AiALz3QGh 
pK0juG0B9k3AiALz5gU5    zq0juG0B9k3AiALz6Aal 
Xa0juG0B9k3AiALz2QCh    RK0juG0B9k3AiALz5QUw 
560juG0B9k3AiALz3QGh    v60juG0B9k3AiALz6Aal 
-K0juG0B9k3AiALz3QGh    Xa0juG0B9k3AiALz2QCh 
-60juG0B9k3AiALz3gGn    P60juG0B9k3AiALz5QUw 
F60juG0B9k3AiALz3gKn    pK0juG0B9k3AiALz5gU5 
m60juG0B9k3AiALz5gU5    0a0juG0B9k3AiALz6Aal 
zq0juG0B9k3AiALz6Aal    3K0juG0B9k3AiALz3QGh 
ua0juG0B9k3AiALz7wqa    8KwjuG0B9k3AiALz1v58 
3K0juG0B9k3AiALz3QGh    F60juG0B9k3AiALz3gKn 
P60juG0B9k3AiALz5QUw    c60juG0B9k3AiALz5gU4 

我已经尝试将主题组合为 KStreams 和 KTables（以及我能想到的每个组合），但是在这个小子集中的 24 条消息中，只有约 5 条连接是成功的。

当前代码的当前示例（并略微简化）：

val events = streams.createKTable<RawEvent>("raw_events)
val users = streams.createKStream<ProcessingUser>("processing_users)

val finalEvents = events
    .join(users, eventsProcessor::enrichWithUsers)
    .to("final_events")

鉴于raw_events和processing_users主题中有对应的对 (1:1)，是否有任何解释为什么某些连接会成功而其他连接会失败？ 只有 5 对将始终进入final_events主题（总是相同的对）。

欢迎任何其他建议！

配置

为了详细起见，这里有一些关于设置值得注意的事情：

• 使用 Kafka Streams 2.3.0
• 缓存和日志记录分别为所有适用的物化调用启用/禁用
• 拓扑优化已启用
• 缓存缓冲设置为 0

更新

简而言之，在花了几个小时仔细考虑并深入研究数据后，这个问题似乎与分区有关。

一直成功的五个连接似乎只是因为每个主题的键位于相同的分区上：

successful events       raw_events partition  processing_users partition
RK0juG0B9k3AiALz5QUw    3                     3
m60juG0B9k3AiALz5gU5    7                     7
ua0juG0B9k3AiALz7wqa    7                     7
8KwjuG0B9k3AiALz1v58    8                     8
RKwjuG0B9k3AiALz1P7C    9                     9

尽管两个主题中都存在所有键，但它们似乎没有使用相同的策略进行分区（即两个主题包含具有相同键的所有消息，但有些可能出现在raw_events的一个分区上，但在不同的分区上在processing_users中），如下面的分区/计数表示所示：

值得强调的是，出现在raw_events主题中的消息是在上面描述的流应用程序工作流之外生成的，这让我相信这些问题需要得到回答：

• 假设分区策略导致跨分区的标准化分布，是否有可能允许分区策略的责任仅落在流工作流的入口点上？ （例如，如果给定的键在raw_events的分区 7 中，并且您将具有相同键的记录发送到preprocessing_users ，它会落入分区 7？
• 如果是这样，这是一个合理的策略吗？ 或者有没有办法在不编写所有生产者和流应用程序使用的自定义分区器的情况下强制执行此行为？
• 如果没有，是否可以采用现有主题（在这种情况下raw_event并基本上重新分区整个主题以便使用默认分区策略？

Answer 1

正如对原始帖子的更新所详述的，问题本身是 .NET Producer 应用程序之间的分区策略差异的结果，该应用程序默认使用consistent_random的随机分区策略，而不是使用murmur2random策略的默认 Java 流应用程序。

有几个选项可以解决这个问题，但在这种特殊情况下，最简单的方法是调整生产者以使用适当的策略：

// Set the default partitioning strategy 
ProducerConfig.Partitioner = Partitioner.Murmur2Random;

另一种方法可能是编写一个CustomPartitioner class 来实现您喜欢的分区策略来模仿您的生产者。