現在ラムダ アーキテクチャを適用するプロジェクトを構築している場合、バッチ レイヤーとサービス レイヤーを分割する必要がありますか。つまり、プログラム A がバッチ レイヤーの作業を行い、プログラム B がサービス レイヤーの作業を行いますか? それらは物理的に独立していますが、プログラム A が事前計算作業を完了した後にプログラム A が B に動作するように指示できるため、論理的に関連しています。
もしそうなら、それを実装する方法を教えてください。IPCを考えています。IPC が役立つ場合、具体的な方法は何ですか?
ところで、「バッチ ビュー」とは正確にはどういう意味ですか? なぜ、どのようにサービングレイヤーがインデックスを作成するのですか?
ラムダ アーキテクチャの batch_layer とserving_layer を実装する最良の方法は何ですか? それは、特定の要件、システム環境などに完全に依存します。ただし、Lambda アーキテクチャの batch_layer とserving_layer の設計方法については説明できます。
ちなみに、昨日同僚とこれについて話し合ったところです。これはその議論に基づいています。3 つの部分に分けて説明します。この議論のために、(a) 1 日、(b) 週、(c) 年間で最も読まれた記事を計算するシステムの設計に関心があるとします。
まず、ラムダ アーキテクチャでは、解決しようとしている問題を最初に時間、次に機能に関して分割することが重要です。したがって、データを着信ストリームとしてモデル化すると、速度レイヤーはストリームの「先頭」、たとえば当日のデータを処理します。バッチレイヤーは、マスターセットである「頭」+「尾」を扱います。
次に、これらの時間ベースのライン間でフィーチャを分割します。たとえば、一部の機能はストリームの「ヘッド」のみを使用して実行できますが、マスターセットなどの「ヘッド」よりも幅広いデータを必要とする機能もあります。この例では、スピード レイヤーを定義して 1 日分のデータを計算するとします。次に、スピード レイヤーは、いわゆるスピード ビューで 1 日に最も多く読まれた記事 (a) を計算します。一方、バッチ レイヤーは、いわゆるバッチ ビューで、(a) 曜日、(b) 週、(c) 年間で最も読まれた記事を計算します。はい、少し冗長に見えるかもしれませんが、その考えを保持してください。
3 番目に、Speed View と Batch View に関するクライアントからのクエリに対するレイヤー応答を提供し、それに応じて結果をマージします。Speed View と Batch View の結果には必ず重複があります。とにかく、これは速度とバッチの違いであり、他の利点の中でも特に、(1) バグのロールアウト、(2) データ配信の破損、(3) 長時間実行されるバッチ プロセスなどのリスクへの露出を最小限に抑えることができます。理想的には、 、問題は速度ビューで捕捉され、バッチ ビューの再計算の前に修正が適用されます。もしそうなら、すべては順調です。
要約すると、互いに完全に独立しているため、IPC を使用する必要はありません。したがって、プログラム A はプログラム B と通信する必要はありません。代わりに、システムは処理のオーバーラップに依存します。たとえば、プログラム B が日単位でバッチ ビューを計算する場合、プログラム A は 1 日分の速度ビューと、処理にかかる追加の時間を計算する必要があります。この余分な時間には、バッチ レイヤーのダウンタイムを含める必要があります。
お役に立てれば！
ノート：