ラムダアーキテクチャとは、膨大なデータ「ビッグデータ」を処理するアプローチ。従来のデータ基盤が得意とするバッチ処理の定期実行で得られる集計結果と、ストリーム処理によるリアルタイムの分析結果を組み合わせて分析できる。
Hadoopの登場により、「ビッグデータ」という言葉が浸透した。ビッグデータは多量のデータを蓄積し、そのデータに対してバッチ処理を施すことで何らかの知見を得るというものが主だった。
バッチ的にビッグデータを扱っていたところ、やがてビッグデータに対してインタラクティブに分析・集計処理を実施することも可能になってきた。
やがてリアルタイム系技術が流行し、リアルタイム処理を強みの一つとして持つApache Sparkがブレークした。
バッチ処理は正確な結果を出力できるが、待ち時間が長いため、出力された頃には古いデータになっている。そうした課題感から、バッチ処理とリアルタイム処理のマージである「ラムダアーキテクチャ」というアプローチが提唱された。
(画像出典: ラムダアーキテクチャとは | Databricks )
新しいデータはバッチレイヤとスピードレイヤに同時に供給される。
このレイヤでは、マスターデータセット(生データ)の管理や定期的なバッチ処理によるバッチビューの事前計算を行う。全てのデータを一度調べ、最終的にスピードレイヤ内のデータを修正する。
バッチレイヤ・スピードレイヤから出力されるデータが、サービングレイヤに転送される。この例やでは、バッチビュー(集計結果や分析可能な加工済みデータ)をクライアントに提供する。このビューはBIツールやSQLで参照可能なデータとなる。
リアルタイム処理の結果を提供する層。直近数秒、数分、数十分のイベントの集計結果を提供する。
バッチレイヤのレイテンシで処理できずバッチビューでまだ配信されていないデータを処理する。リアルタイムビューを作成して、ユーザにデータの完全なビューを提供するために、最新のデータのみを扱う。
サービスレイヤとスピードレイヤの双方に対して問い合わせをし、その結果をマージしてユーザに提供するようなクエリ機構を構築することで、バッチ処理の細やかな集計結果も、スピードレイヤの最新の集計結果も、分析に反映させることができる。
過去のデータとリアルタイムなデータを区別することなく、集計・分析することができる。例えば、マーケティング分野への活用が考えられる。ユーザのアクションを検知した際、そのユーザの過去と直近の双方の動向を理解した上で、そのユーザのアクションに対するリアクションをリアルタイムに決定できる。
難易度が高そうなのでそこまで調べていない...検討するべきときが来たらもう一度調べる。