分析と回答
リアルタイム データ ウェアハウスの場合、Lmabda アーキテクチャには明らかな欠点があります。まず、2 つのシステムを同時に維持すると、リソースの使用量が多くなります。第 2 に、2 つのシステムのデータ処理ロジックは同じであり、コードは繰り返し開発されます。
ストリーム処理タスクとバッチ処理タスクを同時に完了するために 1 つのシステムを維持するだけで済むアーキテクチャはありますか?もちろん、それはKappaアーキテクチャです。
カッパ建築
Kappa アーキテクチャは、真のストリームとバッチの統合処理方法です。これは、LinkedIn によって提案され、ストリーム処理エンジンが段階的に改良されたリアルタイム データ ウェアハウス アーキテクチャです。
カッパ建築
このアーキテクチャは、Lambda アーキテクチャからバッチ層 (Batch Layer) を削除し、別のストリーム処理層 (Speed Layer) だけを残すことに相当します。上流のリプレイ (バックトラッキング) 機能は、メッセージ キューのデータ保持機能によって実現されます。
フロー タスクでコード変更が発生した場合、またはバックトラッキング計算が必要な場合、元のジョブ N は変更されません。まず、新しいジョブ ジョブ N+1 が開始され、メッセージ キューから履歴データを取得し、計算を実行し、計算を保存します。新しいデータテーブルが作成されます。
計算の進行状況が前のジョブ N に追いつくと、ジョブ N+1 がジョブ N に代わって最新のストリーム処理タスクになります。次に、プログラムは新しいデータ テーブルからのデータの読み取りに切り替え、履歴ジョブ ジョブ N を停止し、古いデータ テーブルを削除します。
もちろん、このアーキテクチャを最適化して 2 つの出力テーブルを 1 つにマージして、運用および保守部分の作業を軽減することもできます。
Lambda アーキテクチャのバッチ処理は全体のスループットとパフォーマンスの中核部分であるため、このアーキテクチャは Lambda アーキテクチャと比較してスループットとパフォーマンスが低くなります。
ただし、Kappa はデータ処理アーキテクチャを統合し、コンピューティング リソースの無駄を削減し、運用と保守のコストを削減します。さらに、コードは一度記述して保守するだけで済みますが、Kappa ではストリーム処理とバッチ処理の間の一部の処理ロジックの不一致を解決できません。
Kappa アーキテクチャの選択
Kappa アーキテクチャの選択では、履歴データの保存と再生機能があり、複数のコンシューマをサポートしているため、メッセージ キューとして Kafka がよく選ばれます。
ストリーム処理クラスターの場合、一般に Flink が選択されます。これは、Flink がストリームとバッチの統合処理をサポートし、SQL のサポートが徐々に増加しているため、ストリーム処理とバッチ処理のロジック コード間の不一致を最小限に抑えることができるためです。
データ サービスに関しては、リアルタイムの読み取りと書き込みを必要とするデータベース製品が依然として存在しており、一般的なものには HBase、Druid、ClickHouse などが含まれます。
ただし、Kafka をメッセージ キューとして使用する場合、Kafka はメッセージをまずメモリに保存してからディスクに書き込むため、データ損失が発生する可能性があることに注意してください。
財務レベルのデータの信頼性が必要な場合は、ディスクへの直接のデータ永続化をサポートする Rabbit MQ や Rocket MQ などのメッセージ キューを使用する方が良い選択肢になる可能性がありますが、それに応じてデータのリアルタイム性とスループットが犠牲になります。
反映と拡張
Kappa アーキテクチャと Lambda アーキテクチャに違いはなく、異なるシナリオに適用できるだけです。
Meow Interview Assistant:面接の質問に対するワンストップ ソリューション。WeChat アプレットを検索できます。[Meow Interview Assistant]< a i=3> または、 [鳴き声の質問] -> インタビュー アシスタント 無料の質問をフォローしてください。面接に関する優れた知識やスキルをお持ちでしたら、ぜひ共有してください。