序文
この記事はコラム「ビッグデータの理論体系」に属しています。このコラムは著者によるオリジナルです。引用する場合は出典を明記してください。不足点や間違いがあればコメント欄でご指摘ください。ありがとうございます。
このコラムのディレクトリ構造と参考文献については、「ビッグデータ理論体系」を参照してください。
仲間
「分散データモデルの詳しい説明：OldSQL => NoSQL => NewSQL」
「分散コンピューティングモデルの詳細解説：MapReduce、データフロー、P2P、RPC、エージェント」
「ビッグ データ ストレージ アーキテクチャの詳細説明: データ ウェアハウス、データ マート、データ レイク、データ グリッド、レイクとウェアハウスの統合」
「ビッグデータ処理アーキテクチャの詳細説明：Lambdaアーキテクチャ、Kappaアーキテクチャ、フローバッチ統合、Dataflowモデル、リアルタイムデータウェアハウス」
マインドマッピング
ラムダアーキテクチャ
ラムダの起源
データは 2 つの場所から取得されるため、通常、このギリシャ文字はこのパターンに関連付けられていると考えられます。
バッチ データと高速ストリーミング データは、ラムダ シンボルの曲線部分を表し、上の図に示すように、サービス レイヤーを介してマージされます (線分が曲線部分とマージされます)。
何
Lambda アーキテクチャは、Twitter エンジニアの Nathan Marz によって提案されたビッグデータ処理アーキテクチャです。
その目標は、リアルタイムのクエリと履歴データのバッチ処理のニーズを同時に満たすことができる、汎用的で堅牢なビッグ データ システムを構築することです。
ビッグデータの台頭により、ますます多くの企業が大量のデータの処理という問題に直面し始めています。従来のバッチ処理システムはリアルタイム データ処理のニーズを満たすことができず、単純なストリーム処理システムでは複雑な履歴データ分析を実行できません。これには、リアルタイムのパフォーマンスと複雑な分析のバランスをとれるハイブリッド アーキテクチャが必要です。ラムダアーキテクチャが誕生しました。
Lambda アーキテクチャの詳細については、私のブログ「Lambda アーキテクチャとは?」を参照してください。》
構成
Lambda アーキテクチャは、バッチ層、スピード層、クエリに応答するためのサービング層の合計 3 層のシステムで構成されています。
Lambda アーキテクチャでは、各レイヤーに独自のタスクがあります。
バッチレイヤー
バッチ レイヤーは、マスター データ セット (不変データ セット) とバッチ前の計算ビューを保存および管理します。
バッチ処理層は、大量のデータを処理できる分散処理システムを使用して結果を事前計算します。
既存のすべての履歴データを処理することで、データの正確性を実現します。
これは、完全なデータ セットに基づいて再計算され、エラーがあれば修正されてから、既存のデータ ビューが更新されることを意味します。
通常、出力は読み取り専用データベースに保存され、更新により既存の事前計算されたビューが完全に置き換えられます。
高速処理層
高速処理層は、受信したビッグデータをリアルタイムで処理します。
スピード レイヤーは、最新データのリアルタイム ビューを提供することで遅延を最小限に抑えます。
スピード レイヤーによって生成されるデータのビューは、バッチ レイヤーによって最終的に生成されるビューほど正確または完全ではない可能性がありますが、データを受信するとほぼ即座に利用可能になります。
バッチ層で同じデータを処理する場合、スピード層のデータを置き換えることができます。
基本的に、スピード レイヤーは、バッチ レイヤーによって生じるデータ ビューの遅れを補います。
たとえば、バッチ処理レイヤーの各タスクが完了するまでに 1 時間かかり、この時間の間、バッチ処理レイヤーの最新のタスクによって提供されるデータ ビューを取得できません。
スピード レイヤーは、データをリアルタイムで処理して結果を提供できるため、この 1 時間の遅れを補います。
サービス層
バッチ レイヤーとスピード レイヤーで処理されたすべての出力は结果サービス レイヤーに保存され、サービス レイヤーは事前計算されたデータ ビューを返すか、スピード レイヤーの処理からデータ ビューを構築することでクエリに応答します。
カッパ建築
Kappa アーキテクチャは、2014 年に Jay Kreps によって最初に提案された Lambda アーキテクチャの改良と最適化です。
ストリーミング コンピューティング システムの発展に伴い、Lambda アーキテクチャに関するいくつかの問題が徐々に明らかになってきました。
- システムの複雑さ: バッチ処理システムとストリーミング システムを同時に開発し、保守する必要があります。
- ログの再生を通じて低遅延クエリを実装すると、データの冗長性が得られる可能性があります。
- リアルタイム ビューとバッチ ビューの間には遅延の不一致という問題があります。
これらの問題を解決するために、Jay Kreps は Kappa アーキテクチャを提案しました。Kappa アーキテクチャは、Lambda アーキテクチャのバッチ処理層を削除し、ストリーム処理システムを通じてプロセス全体を直接実装します。
Kappa アーキテクチャの詳細については、私のブログ「Kappa アーキテクチャとは?」を参照してください。》
構成
Kappa アーキテクチャは主に 2 つの層で構成されます。
- ストリーミング処理層: ストリーミング システムを通じてすべてのデータを受信し、リアルタイムの計算を実行し、ストレージ内の結果ビューを更新します。
- サービス層: クエリ サービスを外部に提供し、ストリーミング処理層によって更新された結果ビューに基づいてクエリの戻りを直接実行します。
Kappa アーキテクチャはシステムの複雑さを軽減し、データの冗長性とデータの不整合を回避します。ただし、ストリーミング処理システムは、Exactly-onceストリーミング計算の正確性を保証するためにセマンティクスを保証できる必要があります。さらに、履歴データの複雑な計算は、バッチ処理システムなしではさらに困難になります。
Apache Kafka を例として、Kappa アーキテクチャのプロセス全体を説明します。
- Apache Kafka をデプロイし、データ ログの保存期間 (Retention Period) を設定します。ここでの保持期間とは、再処理できるようにする履歴データの時間間隔を指します。たとえば、最大 1 年分の履歴データを再処理する場合は、Apache Kafka の保持期間を 365 日に設定できます。すべての履歴データを処理できるようにしたい場合は、Apache Kafka の保持期間を「永久」に設定できます。
- 既存の論理アルゴリズムを改善する必要がある場合は、履歴データを再処理する必要があることを意味します。必要なのは、Apache Kafka ジョブ インスタンス (インスタンス) を再起動することだけです。このジョブ インスタンスは最初からやり直し、保持されている履歴データを再計算し、結果を新しいデータ ビューに出力します。Apache Kafka の最下層はログ オフセットを使用してどのデータ ブロックが処理されたかを判断することがわかっているため、ログ オフセットを 0 に設定するだけ新しいジョブ インスタンスが履歴データの処理を再開します。
- この新しいデータ ビューで処理されたデータが古いデータ ビューに追いつくと、アプリケーションは新しいデータ ビューからの読み取りに切り替えることができます。
- 古いバージョンのジョブ インスタンスを停止し、古いデータ ビューを削除します。
Lambda アーキテクチャとは異なり、Kappa アーキテクチャはバッチ処理層を削除し、速度層のみを保持します。データを再処理する必要があるのは、ビジネス ロジックが変更された場合、またはコードが変更された場合のみです。
もちろん、上記の手順でいくつかの最適化を行うこともできます。たとえば、ステップ 4 は実行されません。つまり、古いデータ ビューは削除されません。この利点は、コード ロジックにエラーが見つかったときに、時間内に以前のバージョンのデータ ビューにロールバックできることです。または、サービス層で A/B テストを提供したい場合は、複数のバージョンのデータ ビューを保持しておくと、A/B テストの実行に役立ちます。
Lambda アーキテクチャと Kappa アーキテクチャ
Lambda アーキテクチャと Kappa アーキテクチャの違いは、次の表で比較して説明できます。
| 比較品 | ラムダアーキテクチャ | カッパ建築 |
|---|---|---|
| 構成 | バッチ層 スピード層 サービス層 |
ストリーミング処理層 サービス層 |
| データ処理方法 | バッチ システムは履歴データを処理し、 ストリーミング システムはリアルタイム データを処理します。 |
すべてのデータを処理するにはストリーミング システムのみを使用してください |
| システムの複雑さ | より高度な 2 つのシステムの開発と保守が必要 | 低い場合、ストリーミング システムのみが必要です |
| 遅延一貫性 | はい、リアルタイム ビューとバッチ ビューの間には待ち時間の違いがあります。 | バッチシステムがない方が良い |
| データの冗長性 | 存在します。ログをリアルタイム システムに再生する必要があります | ログを再生する必要がなくなり、 |
| 履歴データの処理 | バッチ処理システムにより複雑な履歴分析が可能 | 比較的複雑な、ストリーミングのみのシステム |
結論は：
Lambda アーキテクチャは、バッチ処理レイヤーと高速レイヤーの組み合わせにより、低レイテンシと複雑な分析を組み合わせていますが、システムは複雑で、データの冗長性とレイテンシの不整合の問題があります。
Kappa アーキテクチャはストリーミング システムを通じてすべての処理を実装するだけなので、アーキテクチャが簡素化されますが、履歴データの分析は比較的複雑であり、正確なワンスセマンティクスを保証するにはストリーミング システムが必要です。
どちらにも独自の長所と短所があり、特定のシナリオに基づいて技術的な選択と設計のトレードオフを行う必要があります。
Kappa アーキテクチャのバリアント
カッパ-S
Kappa-S アーキテクチャは、Kappa アーキテクチャに基づいて最適化および改善されています。
Kappa アーキテクチャにより、単一のストリーム処理システムを通じて低遅延のリアルタイム コンピューティングと履歴データ処理が可能になります。
しかし、元の Kappa アーキテクチャにはまだいくつかの問題があります。
- 履歴データの処理はまだ比較的複雑で、Lambda アーキテクチャのバッチ処理システムほど優れていません。
- 単一のストリーミング システムはすべてのデータを処理する必要があり、より大きなプレッシャーに直面しています。
- ストリーミング システムでは、 1 回限りのセマンティクスを保証する必要がありますが、これは実装がより複雑です。
これらの問題を解決するために、Jay Kreps らは Kappa-S アーキテクチャを提案しました。このアーキテクチャでは、Kappa アーキテクチャに基づいた Stream-Serving 層が導入されています。
Kappa-S アーキテクチャは次のコンポーネントで構成されます。
- ストリーム層: リアルタイムストリーミング処理層。
- サービス層: クエリ サービス層。
- Stream-Serving レイヤー: Stream の負荷を軽減するために、履歴データ クエリを事前計算して提供するために使用されます。
Kappa-S アーキテクチャは、履歴データを事前計算する Stream-Serving レイヤーを導入することで、ストリーミング処理の負荷を軽減し、履歴データのクエリと分析を簡素化すると同時に、正確なワンス セマンティクスを提供する必要があるストリーミング システムの複雑さを回避します。。これは、Kappa アーキテクチャと Lambda アーキテクチャの間の妥協点と見なすことができます。
カッパラムダ
Kappa-Lambda アーキテクチャは、Kappa アーキテクチャに基づいており、Lambda アーキテクチャのバッチ処理層コンポーネントを導入したハイブリッド アーキテクチャです。
Kappa-Lambda アーキテクチャは次のコンポーネントで構成されます。
- ストリーム層: リアルタイムストリーミング処理層。
- サービス層: クエリ サービス層。
- バッチ レイヤー: 複雑な履歴データ分析に使用されるバッチ処理レイヤー。
- スピード レイヤー: 低遅延リアルタイム コンピューティングのためのスピード レイヤー。
ワークフローは次のとおりです。
- ストリーム層はリアルタイム データを受信し、リアルタイム計算を実行します。
- Speed レイヤーは、Stream レイヤーからリアルタイムの結果を取得し、低遅延のリアルタイム分析を実行します。
- Serving レイヤーにクエリを実行すると、リアルタイム部分は Speed レイヤーから取得され、履歴部分は Batch レイヤーから取得されます。
- Batch レイヤーは、Stream レイヤーから定期的にデータを取得し、複雑な履歴データの分析と処理を実行します。
Kappa アーキテクチャと比較すると、Kappa-Lambda アーキテクチャでは、複雑な履歴データ分析を容易にするバッチ処理層コンポーネントが導入されていることがわかります。同時に、低遅延のリアルタイム計算のために Speed レイヤーが保持されます。
この設計では、Kappa アーキテクチャのシンプルさと、複雑な分析における Lambda アーキテクチャの利点が考慮されています。リアルタイム処理と複雑なバッチ処理の両方を処理できます。
カッパDB
Kappa-DB アーキテクチャは、データベース コンポーネントを導入してストリーミング データをデータベースに永続的に保存することにより、Kappa アーキテクチャに基づいて形成されたアーキテクチャ設計です。
Kappa-DB アーキテクチャには通常、次のコンポーネントが含まれています。
- ストリーム層: リアルタイムストリーミング処理層。
- サービス層: クエリ サービス層。
- データベース: ストリーミング処理の結果データを保存するために使用されるデータベース層。
ワークフローは次のとおりです。
- ストリーム層はリアルタイム データを受信し、リアルタイム処理を実行します。
- ストリーム層は、処理結果をデータベースに書き込み、永続的に保存します。
- サービス層はクエリ リクエストを受信し、データベースからデータを読み取り、計算を実行して結果を返します。
- データベースのオーバーフローを避けるために定期的にアーカイブまたは集約します。
データベース コンポーネントを導入すると、次のような利点があります。
- データベースの永続ストレージを通じてデータ損失を回避します。
- 履歴データのクエリを簡素化し、データベースでインデックスの最適化を実行できます。
- アーカイブすることでストレージ コストを削減できます。
- データベースの計算能力を再利用して、ストリーム コンピューティングのオーバーヘッドを削減できます。
データベースへの書き込みがシステムのボトルネックになることに注意する必要があり、通常はデータベースへの書き込み頻度を制御し、アーカイブの最適化を行う必要があります。
一般に、Kappa-DB アーキテクチャは、 Kappa アーキテクチャの利点を継承しながら、ストリーミング処理とデータベースを統合することでデータの永続的な保存を実現します。
Kappaシリーズのアーキテクチャ比較
| アーキテクチャのタイプ | 構成 | アドバンテージ | 欠点がある |
|---|---|---|---|
| カッパ | ストリーミング処理層 サービス層 |
シンプルで一貫性のある | 履歴処理は複雑です |
| カッパ-S | ストリーミング処理層 サービス層 プレコンピューティング層 |
流圧を低減し、 履歴処理を簡素化します。 |
さらなる複雑さの層 |
| カッパラムダ | ストリーミング層 サービス層 スピード層 バッチ層 |
リアルタイム処理とバッチ処理の両方を考慮 | アーキテクチャはより複雑です |
| カッパDB | ストリーミング処理層 サービス層 データベース層 |
データの永続化には DB コンピューティングを使用します |
DBがボトルネックになる |
要約すれば：
- Kappa アーキテクチャはシンプルですが、履歴処理は複雑です
- Kappa-S は、事前計算層を通じてリアルタイム トラフィックのプレッシャーを軽減しますが、システムの複雑性は増大します
- Kappa-Lambda はバッチ処理機能を導入していますが、アーキテクチャは非常に複雑です
- Kappa-DB は永続化のためにデータベースを使用しますが、DB のボトルネックに直面する可能性があります
リアルタイム処理、履歴処理、一貫性、範囲などのニーズのバランスをとりながら、特定のビジネス ニーズに基づいて適切なアーキテクチャを選択する必要があります。
統合されたフローとバッチ
統合バッチおよびストリーミング処理とは、ストリーミング処理とバッチ処理をランタイム フレームワークで統合して統合処理することを指します。
ストリーミング バッチ統合アーキテクチャでは、リアルタイム データ ストリーミングと履歴データのバッチ処理で、Apache Spark、Apache Flink などの同じデータ処理ツールとテクノロジのセットを使用できます。ストリーミング バッチ統合アーキテクチャは、リアルタイム データと履歴データを統合的に処理および分析して、データ処理の複雑さを簡素化し、データ処理の効率を向上させることができます。
ストリーミング バッチ統合アーキテクチャでは、リアルタイム データ ストリーミングと履歴データのバッチ処理で同じデータ処理コード セットを使用できます。これは、データ プロセッサが同じプログラミング言語、フレームワーク、ツールを使用して、リアルタイム データと履歴データの両方を処理できることを意味します。これにより、データ処理担当者の学習コストと使用コストが削減され、データ処理の効率と精度が向上します。
ストリーミング バッチ統合アーキテクチャでは、Apache HBase、Apache Cassandra などの同じデータ ストレージ システムにリアルタイム データと履歴データを保存することもできます。これにより、データ ストレージの管理とメンテナンスが簡素化され、データの可用性と信頼性が向上します。
つまり、ストリームとバッチの統合は、ストリーム データ処理とバッチ データ処理を統合するデータ処理アーキテクチャであり、複雑なデータ処理を簡素化し、データ処理の効率を向上させることができます。ストリーミング バッチ統合アーキテクチャにより、リアルタイム データ処理と履歴データ バッチ処理の間のシームレスな切り替えを実現し、さまざまなデータ処理ニーズに対応できます。
誕生の背景
Liubatch Integration の誕生には主に次のような背景があります。
- Lambdaアーキテクチャの複雑さ：Lambdaアーキテクチャはバッチ処理システムとストリーミング処理システムの開発と保守を同時に行う必要があり、システムが複雑で開発や運用保守が困難です。
- リアルタイム コンピューティングと履歴コンピューティング要件の統合: リアルタイム データ処理と履歴データ分析の両方を必要とするアプリケーションが増えており、統一されたフレームワークが必要です。
- ストリーミング処理システムの開発は成熟しています。ストリーミング処理システムのコンピューティング モデルとパフォーマンスは成熟しており、従来のバッチ処理タスクの置き換えに使用できます。
- マイクロバッチ ストリーミング テクノロジーの出現: Spark Streaming などのシステムは、マイクロバッチ ストリーミングを使用して、ストリーミング処理のイベント時間管理を簡素化します。
- クラウド ネイティブ テクノロジーの台頭: Kubernetes などのテクノロジーは、より優れたリソース スケジューリングと、ストリーミングとバッチ統合のための技術サポートを提供します。
要約すると、ストリームとバッチの統合は、Lambda アーキテクチャの簡素化であり、リアルタイム データと履歴データが必要なシナリオに対処するためのリアルタイム処理とバッチ処理の統合の成果であると考えることができます。
データフローモデル
DataFlow モデルは、データ処理プロセスを記述するために使用されるコンピューティング モデルであり、ソースから宛先までのデータの流れを記述し、データ処理の方法と順序を指定します。
DataFlow モデルは、さまざま并行计算な数据流处理分野でよく使用されており、たとえば、ストリーム処理フレームワーク Apache Flink は DataFlow モデルに基づいて実装されています。
DataFlow モデルでは、データは流れるものとみなされ、データ処理は一連のデータ変換操作と見なされます。データは 1 つまたは複数の入力ソースからデータ処理システムに流入し、一連の処理操作を経て、最終的に 1 つまたは複数の出力先に出力されます。データ処理中に、データを複数のデータ ブロックに分割し、これらのデータ ブロックを並列処理してデータ処理の効率を向上させることができます。
DataFlow モデルのデータ処理操作は通常、有向グラフのノードとして記述され、データ フローは有向エッジとして記述されます。各ノードは、データ フィルタリング、データ変換、データ集約などの特定のデータ処理操作を実行できます。ノード間のエッジは、データの流れの方向とデータ処理の順序を表します。DataFlow モデルでは、データ処理操作を複雑なデータ処理プロセスに結合して、さまざまなデータ処理要件を達成できます。
つまり、DataFlow モデルはデータ処理プロセスを記述するために使用されるコンピューティング モデルであり、ソースから宛先までのデータの流れを記述し、データ処理の方法と順序を指定します。DataFlowモデルは並列計算やデータフロー処理の分野でよく利用されており、例えばストリーム処理フレームワークApache FlinkはDataFlowモデルに基づいて実装されています。
Dataflow モデルの詳細については、私のブログ「DataFlow モデルとは?」を参照してください。》
誕生の背景
Dataflow モデルの主な背景は次のとおりです。
- ビッグデータ時代のデータ規模の爆発的な増加には並列コンピューティング機能が必要です
- ストリーミング コンピューティングとバッチ処理の要件の融合
- MapReduce モデルの制限: MapReduce モデルは反復計算や DAG サポートには適していませんが、Dataflow モデルはオペレーター グラフを通じて複雑なデータ処理プロセスを表現するのにより適しています。
- 分散リソース管理およびクラスター スケジューリング テクノロジーの進歩: YARN、Mesos、Kubernetes およびその他のテクノロジーにより、Dataflow モデルのランタイム サポートが向上しました。
- インメモリ コンピューティングの開発: Spark などのインメモリ コンピューティング フレームワークは、Dataflow モデルにより適しています。
要約すると、Dataflow モデルは MapReduce モデルの重要な開発および拡張であり、反復、ストリーミング、DAG などの複雑なデータ処理タスクをより適切に処理でき、ビッグ データ時代に広く使用されています。
MapReduce モデルの詳細については、私のブログ「MapReduce プログラミング モデルとは?」を参照してください。》
Dataflow モデルの全体プロセス
DataFlow モデルのプロセス全体は、次のステップに分割できます。
- データ ソース入力: データ ソースには、ファイル、データベース、メッセージ キューなど、さまざまなタイプのデータを使用できます。DataFlow モデルでは、データ ソースがデータ処理プロセスの開始点とみなされ、データはデータ ソースからデータ処理システムに流れます。
- データの切断: DataFlow モデルでは、データを複数のデータ ブロックに分割し、これらのデータ ブロックを並列処理してデータ処理の効率を向上させることができます。データサイズ、タイムスタンプ、キー値などに基づいてデータカットを実行し、並列データ処理をより効果的に実現できます。
- データ変換: DataFlow モデルでは、データはデータ クリーニング、データ フィルタリング、データ集計などの一連のデータ変換操作を受けることができます。データ変換操作は有向グラフのノードとして記述されます。各ノードは特定のデータ処理操作を実行できます。ノード間のエッジはデータの流れの方向とデータ処理の順序を表します。
- データ集約: DataFlow モデルでは、データ分析とマイニングをより適切に実装するために、複数のデータ変換操作の後にデータを集約できます。
- データ出力: DataFlow モデルでは、データ出力は、ファイル、データベース、メッセージ キューなど、さまざまなタイプのデータ宛先にできます。データ出力はデータ処理プロセスの終点とみなされ、データはデータ処理システムからデータ宛先に出力されます。
DataFlow モデルでは、データ処理操作を複雑なデータ処理プロセスに結合して、さまざまなデータ処理要件を達成できます。データ処理プロセスは、Apache Flink、Apache Beam、Apache Kafka などのさまざまなデータ処理フレームワークやツールを使用して実装できます。
Dataflow モデルがデータの正確性と一貫性を確保する方法
DataFlow モデルは、次の方法でデータの精度と一貫性を確保できます。
- データ検証: データがデータ処理システムに流入する前に、データ形式、データタイプ、データ範囲などのデータ検証を実行できます。これにより、データの正確性と完全性が保証されます。
- データ クリーニング: データ処理プロセス中に、重複データの削除、欠落データの補充などのデータ クリーニングを実行できます。これにより、データの一貫性と正確性が保証されます。
- トランザクション処理: データ処理中に、トランザクション メカニズムを使用してデータの一貫性を確保できます。たとえば、ノード上のデータ処理が失敗した場合、データ処理プロセス全体を以前の状態にロールバックして、データの整合性を確保できます。
- データのパーティショニング: データ処理中に、データを複数のデータ ブロックに分割し、各データ ブロックを並列処理できます。これにより、データ処理の効率が向上すると同時に、データの競合や競合を回避してデータの一貫性を確保できます。
- データの再試行: データ処理中にノードの処理が失敗した場合、データが正常に処理されるまでデータを再試行できます。これにより、データの整合性と正確性が保証されます。
リアルタイムデータウェアハウス
リアルタイム データ ウェアハウスは、小規模なデータ セマンティクスとビッグ データ スケールのパフォーマンスを備えた最新のデータ ウェアハウスです。リアルタイムデータ、最新データ、履歴データを処理し、データドメイン全体の相関分析を実行できます。リアルタイム データ ウェアハウスは、データの到着とクエリの速度が速く、統合された安全なプラットフォーム上ですべての機能を完了できます。
リアルタイム データ ウェアハウスの利点には、意思決定の迅速化、データの民主化、パーソナライズされた顧客エクスペリエンス、ビジネスの機敏性の向上、新しいビジネス ユースケースの開拓などが含まれます。ただし、リアルタイム データ ウェアハウスは、ETL パフォーマンスや複雑なリアルタイム コンピューティング シナリオなどの課題にも直面しています。
一般的なリアルタイム データ ウェアハウス アーキテクチャには、データ収集層、データ ストレージ層、リアルタイム コンピューティング層、およびリアルタイム アプリケーション層が含まれます。データ収集層はデータの受信と送信を担当し、データ ストレージ層はリアルタイム データの保存に使用され、リアルタイム コンピューティング層はリアルタイムの計算と分析に使用され、リアルタイム アプリケーション層は使用されます。データ分析とマイニングに。
リアルタイム データ ウェアハウスは、リアルタイム OLAP 分析、リアルタイム データ ダッシュボード、リアルタイム ビジネス監視、リアルタイム データ インターフェイス サービスなどのシナリオで使用できます。その技術的な実装には、通常、メッセージ バス、リアルタイム ストレージ、ストリーム処理と分析、およびアプリケーション層が含まれます。
一般的に使用されるリアルタイム データ ウェアハウス テクノロジには、Apache Kafka、Apache Druid、Apache Spark、Hadoop、TiDB などが含まれます。具体的な選択は、ニーズと好みによって異なります。
リアルタイム データ ウェアハウスの詳細については、私のブログ「リアルタイム データ ウェアハウス 詳細解説」を参照してください。
誕生の背景
リアルタイム データ ウェアハウスの誕生の主な背景は次のとおりです。
- リアルタイム データ分析の需要の高まり: 運用データを即座に分析してタイムリーな意思決定を行えるようにしたいと考える企業が増えています。
- 従来のデータ ウェアハウスにおける大幅な遅延の問題: 従来のデータ ウェアハウスは定期的にバッチで更新されるため、リアルタイム データ分析のニーズを満たすことができません。
- ストリーミングコンピューティング技術の開発：ビッグデータ技術により、ストリーミングデータの収集、送信、計算が可能になります。
- インメモリ コンピューティングの進歩: Spark などのインメモリ コンピューティング テクノロジにより、メモリ レベルの対話型分析が可能になります。
- ユーザー エクスペリエンスを向上させるための要件: ユーザーは分析に関する洞察をすぐに得たいと考えており、従来のデータ ウェアハウスの遅延を待つことはできません。
- クラウド コンピューティング テクノロジの進歩: クラウド コンピューティングは、リアルタイム データ ウェアハウスを柔軟に拡張する機能を提供します。
建築
リアルタイム データ ウェアハウスには通常、データ収集層、データ ストレージ層、リアルタイム コンピューティング層、リアルタイム アプリケーション層の 4 つのコンポーネントがあります。これらのコンポーネントは連携して、イベント発生直後またはイベント発生直後のイベント データの処理と分析をサポートします。すべてのデータ処理段階 (データの取り込み、エンリッチメント、分析、AI/ML ベースの分析) は最小限の遅延で継続的に実行され、リアルタイムのレポート作成とアドホック分析が可能になります。
一般的なリアルタイム データ ウェアハウスのアーキテクチャは次のとおりです。
- データ収集層: サードパーティのサービスと連携システムは、Apache Kafka/Apache Nifi などのメッセージ バスを介してリアルタイム データ ウェアハウスにデータを送信します。サードパーティのデータ ソースはリアルタイム データ ウェアハウスの API を呼び出します。IoT システムは直接データを接続してプッシュする データ転送方法
- データストレージレイヤー: リアルタイムデータストレージには Apache Kudu/Apache Druid/Amazon Redshift を使用します。
- リアルタイム コンピューティング レイヤー: リアルタイム コンピューティングと分析には Apache Spark/Amazon Kinesis/Hadoop を使用します。
- リアルタイム アプリケーション層: AI と機械学習テクノロジを使用してデータの分析とマイニングを行い、SQL Server/Oracle BI を使用してクエリ、レポート、アドホック クエリをサポートし、Apache Impala を使用してリアルタイムのレポートとアラームをサポートします。
比較した
| アーキテクチャのタイプ | 構成 | アドバンテージ | 欠点がある |
|---|---|---|---|
| ラムダアーキテクチャ | バッチ層 スピード層 サービス層 |
低遅延と複雑な分析のバランスをとる | 複雑なシステムと冗長データ |
| カッパ建築 | ストリーミング処理層 サービス層 |
システムはシンプルで一貫性がある | 履歴処理は比較的複雑です |
| 統合されたフローとバッチ | 統合されたランタイムフレームワーク | 処理の簡素化と高効率化 | リアルタイム割引 |
| データフローモデル | データソース、変換操作、データ集約 | 強力な柔軟性と優れた拡張性 | 一貫性などの問題に対処する必要がある |
| リアルタイムデータウェアハウス | コレクション層、 ストレージ層、 コンピューティング層、 アプリケーション層 |
リアルタイム分析、低遅延 | 高度なインフラストラクチャ要件 |
要約する
この記事では、いくつかの主要なビッグ データ処理アーキテクチャについて詳しく説明します。
- Lambda架构：组合批处理层和速度层，兼顾低延迟和复杂分析，但系统较复杂，存在数据冗余和延迟不一致问题。Lambda架构的批处理层可以基于Hadoop、Spark等技术来实现，速度层可以基于Storm、Flink等流式处理系统来实现。服务层需要实现查询接口，可以使用REST API。Lambda架构适合大数据场景，但维护批处理层和速度层的重复开发较为麻烦。
- Kappa架构：仅通过流式处理实现所有处理，简化了架构，但历史数据分析相对复杂。Kappa架构还有几种变种，如Kappa-S、Kappa-Lambda、Kappa-DB。Kappa架构中的流式处理层可以基于Flink、Spark Streaming等来实现，需要实现Exactly-once语义。服务层同样需要查询接口。Kappa架构简单高效，但对实时流有较高要求，历史数据处理不如Lambda架构方便。
- 流批一体：将流式处理和批处理统一在一个运行时框架中，可以简化处理，提高效率。流批一体需要统一运行时框架，如Flink、Spark等，可以通过DataStream和DataSet在流式处理和批处理之间无缝切换。计算模型也需要统一，如Dataflow模型。流批一体简化系统，但实时性不如纯流式处理。
- Dataflow模型：将数据处理视为数据流经转换操作的流程，可以表达复杂的数据处理流程。Dataflow模型通常用有向图表达，并基于并行运行时框架实现，如Flink。需要解决数据一致性、容错等问题。Dataflow模型可以灵活表示复杂处理流程。
- リアルタイムデータウェアハウス：ストリーミング処理によりリアルタイムデータの高速保存と演算分析を実現し、リアルタイム分析の需要に応えます。リアルタイム データ ウェアハウスのメッセージ バスは Kafka を使用して実装でき、ストレージ システムは HBase、Druid などを使用でき、計算には Spark Streaming と Flink を使用します。リアルタイム データ ウェアハウスはデータを迅速に分析し、リアルタイムで更新できますが、インフラストラクチャ要件が高くなります。
一般に、ビッグデータ処理アーキテクチャの開発傾向は实时性增强、处理统一简化、 、です满足复杂分析需求。特定のビジネス シナリオのニーズに基づいて、適切なアーキテクチャ ソリューションを選択する必要があります。将来的には、アーキテクチャはストリーミング処理に基づいたものになる可能性がありますが、複雑な分析のためにバッチ処理機能が導入される予定です。