ラムダアーキテクチャ

ラムダアーキテクチャは、バッチ処理とストリーム処理の両方の手法を活用して大量のデータを処理するように設計されたデータ処理アーキテクチャです。このアーキテクチャアプローチでは、バッチ処理を使用してバッチデータの包括的かつ正確なビューを提供し、同時にリアルタイムのストリーム処理を使用してオンラインデータのビューを提供することで、レイテンシ、スループット、フォールトトレランスのバランスを取ろうとします。2つのビュー出力は、プレゼンテーション前に結合される場合があります。ラムダアーキテクチャの台頭は、ビッグデータ、リアルタイム分析、およびマップリデュースのレイテンシを軽減する動きの成長と相関しています。^[1]

ラムダアーキテクチャは、記録システムとして機能する、追加専用の不変データソースを持つデータモデルに依存します。^{[2] : 32}これは、既存のイベントを上書きするのではなく、追加されたタイムスタンプ付きイベントを取り込んで処理することを目的としています。状態は、データの自然な時間ベースの順序付けから決定されます。

ラムダアーキテクチャは、バッチ処理、高速（またはリアルタイム）処理、クエリに応答するためのサービス層の3つの層で構成されるシステムを表します。^{[3] : 13}処理層は、データセット全体の不変のマスターコピーからデータを取り込みます。このパラダイムは、Nathan Marz によって「 CAP 定理を打ち破る方法」というブログ記事で初めて説明され、彼は当初これを「バッチ/リアルタイムアーキテクチャ」と呼んでいました。^[4]

バッチ層は、大量のデータを処理できる分散処理システムを使用して結果を事前計算します。バッチ層は、ビューを生成する際に利用可能なすべてのデータを処理できるようにすることで、完全な精度を目指しています。つまり、完全なデータセットに基づいて再計算し、既存のビューを更新することで、エラーを修正できます。出力は通常、読み取り専用データベースに保存され、更新によって既存の事前計算済みビューが完全に置き換えられます。^{[3] : 18}

2014年までに、Apache Hadoopは主要なバッチ処理システムであると推定されました。^{[5]その後、} Snowflake 、Redshift、Synapse、Big Query などの他のリレーショナルデータベースもこの役割で使用されるようになりました。

スピード レイヤーは、データ ストリームをリアルタイムで処理し、修正や完全性は要求しません。このレイヤーは、最新のデータに対するリアルタイム ビューを提供することでレイテンシを最小限に抑えることを目指しているため、スループットを犠牲にしています。基本的に、スピード レイヤーは、最新のデータに基づくビューを提供するバッチ レイヤーの遅延によって生じる「ギャップ」を埋める役割を担っています。このレイヤーのビューは、最終的にバッチ レイヤーによって生成されるビューほど正確または完全ではない可能性がありますが、データの受信後すぐに利用可能になり、同じデータに対するバッチ レイヤーのビューが利用可能になると置き換えることができます。^{[3] : 203}

この層で一般的に使用されるストリーム処理技術には、Apache Kafka、Amazon Kinesis、Apache Storm、SQLstream、Apache Samza、Apache Spark、Azure Stream Analytics、Apache Flinkなどがあります。出力は通常、高速なNoSQLデータベースに保存されます。^{[6] [7]}またはコミットログとして保存されます。^[8]

バッチ レイヤーとスピード レイヤーからの出力はサービング レイヤーに保存され、サービング レイヤーは、事前計算されたビューを返すか、処理されたデータからビューを構築することでアドホック クエリに応答します。

サービス層で使用される技術の例としては、Apache Druid、Apache Pinot、ClickHouse、Tinybirdなどがあり、これらは両方の層からの出力を処理する単一のプラットフォームを提供します。^[9]サービス層で使用される専用ストアには、スピード層出力用のApache Cassandra、Apache HBase、Azure Cosmos DB、MongoDB、VoltDB、Elasticsearch 、バッチ層出力用のElephant DB、Apache Impala、SAP HANA、Apache Hiveなどがあります。 ^{[2] : 45  [6]}

データセットを最適化し、クエリの効率を向上させるために、生データに対してさまざまなロールアップおよび集約技術が実行され、^{[9] : 23}推定技術が採用され、計算コストがさらに削減されます。^{[10]また、フォールトトレランスには高価な完全な再計算が必要ですが、増分計算アルゴリズムを選択的に追加して効率を高めることができ、}部分計算やリソース使用の最適化などの技術は、レイテンシを効果的に短縮するのに役立ちます。^{[3] : 93、287、293}

プログラマティック広告分野の企業に分析サービスを提供するMetamarketsは、ストリーミングデータとバッチ処理データの両方を保存および提供するためにDruidを使用するラムダアーキテクチャのバージョンを採用しています。 ^{[9] : 42}

Yahooは広告データウェアハウスの分析を実行するために、Apache Storm、Apache Hadoop、Druidを使用して同様のアプローチを採用しています。^{[11] ：9、16}

Netflix Suroプロジェクトにはデータ処理用の個別のパスがありますが、パスは異なる目的で使用される可能性があり、必ずしも同じタイプのビューを提供するわけではないため、厳密にはラムダアーキテクチャには従っていません。^[12]それでも、全体的なアイデアは、選択されたリアルタイムイベントデータを非常に低いレイテンシでクエリに使用できるようにし、データセット全体をバッチパイプラインで処理することです。後者は、レイテンシにあまり敏感ではなく、マップリデュースタイプの処理を必要とするアプリケーションを対象としています。

ラムダアーキテクチャに対する批判は、その固有の複雑さと、その影響の限界に焦点が当てられてきました。バッチ側とストリーミング側はそれぞれ異なるコードベースを必要とし、処理されたデータが両方のパスから同じ結果を生成するように、維持され同期された状態に保つ必要があります。しかし、コードベースを単一のフレームワークに抽象化しようとすると、バッチおよびリアルタイムエコシステムの多くの専用ツールが利用できなくなります。^[13]

ジェイ・クレプスは、単一のコードベースで純粋なストリーミングアプローチを使用するためにカッパアーキテクチャを導入しました。^{[13]純粋なストリーミングアプローチを採用するメリットに関する技術的な議論では、} Apache Samzaなどの柔軟なストリーミングフレームワークを使用すると、遅延なしでバッチ処理と同じ利点が得られる可能性があることが指摘されました。^[14]このようなストリーミングフレームワークを使用すると、任意のサイズのデータ​​のウィンドウを収集して処理し、ブロッキングに対応し、状態を処理できます。

• イベントストリーム処理
• AWS Lambda は、Amazon Web Services の特定のサービスであり、実際の実行時間のみが課金されます。

^[1]