一見すると、 をKStream#reduceByKey使用すると と同じ機能を実現できるように思えKStream to KTable leftJoinます。つまり、同じキーを持つレコードを結合します。パフォーマンスの面でも、2つの違いは何ですか?
1255 次
2 に答える
3
簡単な答え: (2 つの違いは何ですか?)
reduceByKeyは単一の入力ストリームに適用され、 2 つのストリーム/テーブルがleftJoin結合されます。
長い答え:
私があなたの質問を正しく理解していれば、あなたの着信changelog ストリームは空になり、着信レコードごとKTableに新しい結合結果 (つまり update result ) を計算したいですか? 結合の結果はマテリアライズド ビューとして利用できませんが、変更ログ トピックのみがダウンストリームに送信されます。したがって、入力は常に空になり、入力レコードは常に「なし」で結合され（左結合のため）、実際には結果が更新されません。入力が状態を提供しない場合、悪用できる状態はありません。KTableKStreamKTableKTableKStreamKTableKStream#map()KTable
対照的に、 を使用するreduceByKeyと、結果KTableはマテリアライズド ビューとして利用できるため、入力レコードごとKStreamに前の結果値を更新することができます。
したがって、両方の操作は根本的に異なります。結合を使用して単一の入力がある場合KStream(2 つの入力が必要) は、まったく奇妙KTableです。
于 2016-09-12T22:25:21.480 に答える
1
KStream は、各レコードが自己完結しているレコード ストリームを表します。たとえば、単語の出現を要約する場合、特定のフレーム (時間ウィンドウまたは段落など) の間カウントを保持します。KTable は一種の状態を表し、受信する各レコードは通常、合計発生数を保持します。したがって、各方法が使用されるユースケースはまったく異なります。KStream#reduceByKey は同じキー内のすべてのレコードを削減し、各キーのカウントを要約しますが、KTable#leftJoin は通常、入ってくる別の情報に従って合計カウントを調整する必要がある場合、またはより多くのデータを結合する必要がある場合に使用されます記録。Kafka Stream のドキュメントに示されている例は、ログ圧縮用です。KStream ではレコードを破棄できませんでしたが、KTable では、
于 2016-09-12T08:06:34.607 に答える