Kafka Streams：為執行 KTable-KTable 外鍵連接的應用程序增加主題分區

Question

我發現的大部分信息都與主鍵連接有關。 我知道外鍵連接是 Kafka Streams 的一個相對較新的功能。 我對這將如何擴展感興趣。 我知道 Kafka Streams 的並行性受到每個主題的分區數量的限制，但是我對增加輸入主題分區的含義有一些疑問。

• 外鍵連接是否對共同划分輸入主題有相同的要求？ 也就是說，兩個主題是否需要具有相同數量的分區？
• 在應用程序在生產中運行數月或數年之后如何添加分區？ 支持每個 KTable 的更改日志主題存儲來自某些輸入主題分區的數據。 如果要增加輸入主題中的分區，這對我們的 KTables 的 state 存儲和更改日志有何影響？ 據推測，我們不能只是重新開始並丟失該數據，因為它已經積累了數月和數年，並且對於執行聯接至關重要。 它可能不會很快被上游數據取代。 我們是否需要吹走我們的 state 存儲，創建新的輸入主題，並將所有 KTable 更改日志主題數據重新發送給它們？
• 其他內部“訂閱”主題怎么樣？

Answer 1

外鍵連接是否對共同划分輸入主題有相同的要求？ 也就是說，兩個主題是否需要具有相同數量的分區？

不。有關更多詳細信息，請查看https://www.confluent.io/blog/data-enrichment-with-kafka-streams-foreign-key-joins/

在應用程序在生產中運行數月或數年之后如何添加分區？

即使您不使用 Kafka Streams，您也無法真正做到這一點。 問題是，您的輸入數據是按鍵分區的，如果您添加分區，則輸入主題中的分區會中斷。 -- 推薦的模式是創建一個具有不同分區數的新主題。

支持每個 KTable 的更改日志主題存儲來自某些輸入主題分區的數據。 如果要增加輸入主題中的分區，這對我們的 KTables 的 state 存儲和更改日志有何影響？

它會破壞應用程序。 事實上，Kafka Streams 會檢查並在檢測到輸入主題分區的數量與更改日志主題分區的數量不匹配時引發異常。