リファレンスブック：KafkaStreams in Actionこのプロジェクトには分散ストリームデータ処理が含まれるため、書店でコピーを購入しました。
第一章
コンセプト
Kafkaは、Apache Software Foundationによって開発されたオープンソースのストリーム処理プラットフォームであり、ScalaおよびJavaで記述されています。Kafkaは、高スループットの分散パブリッシュ/サブスクライブメッセージングシステムです。
参照：https://baijiahao.baidu.com/s?id=1651919282506404758&wfr=spider&for=pc
KafkaStreamsは、Kafkaに依存するJavaライブラリ（lib）です。
処理フレームワークではない一般的な処理フレームワークは、Storm、Sparkなどです。
フレームワークにはルールが与えられ、フレームワークに基づく開発はフレームワークの構造と使用ルールに基づいています。
ライブラリは、自分で柔軟に呼び出したり作成したりできるAPIのコレクションです。
ライブラリは軽量で柔軟性があります
バッチ処理大容量の静的データセットは、時間に基づいてバッチ処理することも、特定の条件に基づいてバッチ処理することもできます。たとえば、5秒ごとの処理[時間]、またはデータ量が1Mに達したときの処理[条件]フレームワークHadoop
ストリーム処理は、各イベントをリアルタイムで処理します。新しいデータはそれぞれ個別に処理されますが、多くのストリーム処理システムは「ウィンドウ」操作もサポートしているため、現在のデータが到着する前および/または後に、指定された時間間隔内に到着するデータも参照できます。データ処理における最も中心的なデータ]。Framework Storm、Samza
マイクロバッチ処理バッチ間隔は短くなりますが、イベントベースのストリーム処理の代わりに、バッチは小さな単位に分割され、フレームワークスパーク
式ラムダの方法の機能などのパラメータを可能JDK8新機能
フォーマット
(parameters) -> expression
或
(parameters) ->{ statements; }
たとえば、次のとおりです。
() -> 5 //无接收值，但返回5
ハッシュコード https://blog.csdn.net/qq_21430549/article/details/52225801
P6でのデータのグループ化についてデータを
パーティション化するときに、3（1,2,3）の領域に分割したい場合、（ a、b、c、d、e、f）6つのデータの場合、各データにタグを追加するだけです（a-3、b-1、c-2、d-2、e-1など）。 、f-3。この構造はキーと値のペアの構造によく似ていますが、1,2,3はキーであり、a、b、cは値であることに注意してください。同じキー値でカバーされるため、キーは異なりますが、キーは異なります。パーティションを作成するにはどうすればよいですか。特定のアルゴリズムを使用してキーの値をハッシュし、同じハッシュコードをパーティションに分割します。次のページの式は、キーハッシュ値を取得し、パーティション番号の残りの部分を取得してパーティション番号を取得することです。hashCode関数は、キーに基づいて書き換えられる場合があることに注意してください。データが異なるマップ構造に存在する状況もあります。各マップのキーは一意ですが、それらの配置はおそらく順不同です。パーティション化するときにキーに従うとポイント、検索効率は非常に低くなります。ハッシュコードの外観は速度を向上させるためのものです。ハッシュ操作を通じてキーを取得してハッシュコードを取得します。同じハッシュコードは非常に高速なパーティションに送られます。ハッシュルールは一般にパーティションの数に関連していることに注意してください。
深さ優先最初のポイントから前方に歩き続け、行き止まりに遭遇した場合は、一歩戻って別の方法を試み、目標の位置を見つけます。南壁にぶつからないで振り返らないこの方法は、たとえ成功したとしても、必ずしも良い方法を見つけるわけではありませんが、覚える位置が少ないという利点があります。
幅は、最初のポイントから始まり、すべての可能なパスをたどります。ターゲット位置がそこにない場合は、2つのステップで到達できるすべての位置を通過して、ターゲット位置があるかどうかを確認してください。場所にステップします。この方法は確かに最短経路を見つけることができますが、覚えておく必要のあるコンテンツがたくさんあります。
背圧フロー制御メカニズム。フロー制御
背圧とは、生産者が消費者のニーズと同じだけ生産することを意味します。これは、TCPのフロー制御に多少似ています。受信側は、自身の受信ウィンドウに従って受信速度を制御し、逆ACKパケットを介して送信側の送信速度を制御します。このスキームは、コールドオブザーバブルでのみ有効です。Cold Observableは、レートを下げることができるソースです。たとえば、2台のマシンがファイルを転送できます。レートは大きくても小さくてもかまいません。1秒あたり数バイトに減らしても、時間が十分にあれば、完了することができます。反対の例は、オーディオとビデオのライブブロードキャストです。レートが特定の値を下回ると、関数全体が使用できなくなります（これは、ホットなObservableに似ています）。[考える]タイムカメラによって生成されたデータストリームは、明らかにコールドオブザーバブルではありません。つまり、ソースによって生成されたデータレートが制御されていないため、このシナリオではバックプレッシャーメカニズムは適用されません。
まとめ
最初の章では、購入例とともにKafkaStreamの動作モードの概要を説明します。読み取り後に心に残るメモリポイントは、ソース、プロセッサノード、およびマッパーが、ストリームオブジェクトの購入が処理されるときに、対応するKStreamインスタンスを返します。このインスタンスがプロセッサです。
完全な購入オブジェクトがソースから各ノードを通過するとき、私は情報のフィルタリングとフィルタリングを経験したように感じます。このノードは、処理に関連するデータのみを受け取ります。マッパーによってフィルタリングされたデータは、ノードを生成するときに処理されません。つまり、ソースからのノードの数は関数の方向に従って実装されますが、この関数を処理した後は、各ノードの流れの方向が単一でより「狭い」ため、他の関数はありません。
考える
しかし、このKStreamインスタンスがメソッドによって戻されたという疑問がいくつかありますが、どのオブジェクトがこのメソッドを呼び出したのでしょうか。APIは、KStreamがmapValuesメソッドを呼び出し、次に新しいプロセッサオブジェクトを返したことを示しています。次に、このオブジェクトは購入オブジェクトを処理する必要があります。このKStreamはメソッドを呼び出し、このメソッドのパラメーターは購入オブジェクトである必要があります。その後、処理された購入コピーオブジェクトを返します。これを理解しているかどうかはわかりませんが、特定のコード実装を確認する必要があります。
マッパーの原理もあり、動作方法は明確ではありません。
