同键主题未能加入Kafka流

Question

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

我有两个主题(raw_events和processed_users)，这两个主题的密钥相同，但是当我试图对这两个主题执行连接时，尽管密钥相同，但只有一些连接是成功的。

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

null

问题本身是在步骤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主题（总是相同的对）。

欢迎任何其他建议！

null

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

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主题中的消息是在上面描述的streams应用程序工作流之外产生的，这使我相信需要回答以下问题：

• 假设分区策略会导致跨分区的规范化分布，那么它是否可以允许分区策略的责任完全落在流工作流的入口点上？（例如，如果给定的键在RAW_Events的分区7中，并且您将具有相同键的记录发送到Preprocessing_Users，则该记录将落入分区7？
• 如果是的话，这是一个合理的策略吗？或者，是否有一种方法可以强制执行此行为，而无需编写所有生产者和流应用程序都使用的自定义分区器？
• 如果不是，是否可以使用现有主题（在本例中为raw_event并基本上重新分区整个主题，以便使用默认分区策略？

Answer 1

正如在对原始文章的更新中详细介绍的那样，问题本身是.NET Producer应用程序之间分区策略不同的结果，后者默认使用consistent_random分区策略，而默认Java streams应用程序则使用murmur2random策略。

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

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

另一种方法可能是编写创建一个custompartitioner类，它将实现您首选的分区策略，以模拟您的生产者。