4

この質問は、 Kafka Streams with lookup data on HDFSのフォローアップです。小さな辞書データをメインの Kafka ストリームに (「マップ側」結合のように) 結合する必要があります

私の知る限り、Kafka Stream インスタンスは常にトピックの特定のパーティションで動作します。検索を行うには、結合キーの両方のストリームを再分割して、関連するレコードをまとめる必要がありました。

複数のルックアップ データをチェックする必要がある場合、何度もパーティションを再分割するコストはいくらですか? ルックアップ データセット全体を各パーティションに送信することはできないためKTable、ルックアップ トピックから作成すると、すべての Kafka Stream アプリケーション インスタンスにデータ セット全体が表示されます。したがって、私がKStream#transform()持っているすべてのルックアップ データを使用して、ローカルの RocksDB ストアを取得するメソッドでルックアップを実行できます。

どのオプションがより適切か疑問に思っています：

  • トピックの各パーティションに同じデータ (データ セット全体) を挿入し、 でルックアップを実行しますKStream#transform。トピックが過剰に分割されている場合、多くの重複データが発生しますが、小さなデータセットの場合、これは問題になりません。

  • ルックアップ (結合) を実行できるように、DSL API を使用して両方のストリームを再分割します。ここでのパフォーマンスの意味は何ですか?

4

1 に答える 1

5

私の知る限り、Kafka Stream インスタンスは常にトピックの特定のパーティションで動作します。検索を行うには、結合キーの両方のストリームを再分割して、関連するレコードをまとめる必要がありました。

はい、Apache Kafka 0.10.0 および 0.10.1 では、これを行う必要があります。

複数のルックアップ データをチェックする必要がある場合、何度もパーティションを再分割するコストはいくらですか? ルックアップ データセット全体を各パーティションに送信することはできないため、ルックアップ トピックから KTable を作成すると、すべての Kafka Stream アプリケーション インスタンスにデータ セット全体が表示されます。

このような機能 (私たちはしばしば「グローバル KTable」または「グローバル状態」と表現します) は実際に有用であり、いつ、どのように追加できるかについては既に議論しています。

2017 年 2 月 28 日更新:グローバル テーブルに関する機能の最初のラウンドが Kafka 0.10.2 でリリースされ、KStream から GlobalKTable への結合を実行できるようになりました。

ルックアップ (結合) を実行できるように、DSL API を使用して両方のストリームを再分割します。ここでのパフォーマンスの意味は何ですか?

その影響は、主に入力データの特性 (データ量、一様なデータ分布と歪んだデータ分布など) によって異なります。

于 2016-09-23T08:47:13.193 に答える