ビッグデータアーキテクチャ
その他の関連する推奨事項:
システム アーキテクチャのマイクロサービス アーキテクチャ
システム アーキテクチャ設計のマイクロカーネル アーキテクチャ
Hongmeng オペレーティング システムアーキテクチャ
コラム:システム アーキテクト
1. ビッグデータ技術の生態
-
ストレージ: 主にHDFS、Kafka
HDFS は、Hadoop が提供する分散ストレージ フレームワークであり、大量のデータを保存するために使用できます。 > -
コンピューティング: 主にMapReduce、Spark、Flink
MapReduce は、Hadoop によって提供される分散コンピューティング フレームワークであり、カウントと分析に使用できます。 HDFS の大規模データ -
オンライン クエリ OLAP:kylin、impala など
-
ランダム クエリ NoSQL:Hbase、Cassandra など
-
マイニング、機械学習、深層学習テクノロジー:TensorFlow、caffe、mahout など
2. ビッグデータの階層化アーキテクチャ
ビッグデータの階層化アーキテクチャ図:
ビッグデータのアーキテクチャ図:
HDFS: (Hadoop 分散ファイル システム)。大量のデータを保存するために使用でき、上で実行される分散システムに適しています。汎用ハードウェア ファイル システム (分散ファイル システム)。 HDFS は、安価なマシンへの導入に適した耐障害性の高いシステムです。 HDFS は高スループットのデータ アクセスを提供でき、大規模なデータ セット上のアプリケーションに非常に適しています。[通常、オフライン データ ストレージの処理に使用されます]。
Hbase: 非構造化データ ストレージに適した分散型の列指向のオープン ソース データベース。 [リアルタイム データとオフライン データの両方がサポートされています]。
Flume: 高可用性/信頼性、分散型大規模ログ収集、集約、送信システム 、Flumeデータを収集するためにログ システム内のさまざまなデータ送信者のカスタマイズをサポートすると同時に、Flume はデータを単純に処理し、さまざまなデータ受信者に書き込む機能 (カスタマイズ可能) を提供します。
Kafka: ストリーム データを処理できる、高スループットの分散パブリッシュ/サブスクライブ メッセージング システムウェブサイト上での消費者のあらゆる行動。
ZooKeeper: オープン ソースの分散アプリケーション調整サービス。Hadoop および Hbase コンポーネントの重要なコンポーネントです。分散アプリケーションに一貫したサービスを提供するソフトウェアであり、構成保守、ドメイン名サービス、分散同期、グループ サービスなどの機能が提供されます。
3. ラムダアーキテクチャ
3.1 Lambda アーキテクチャは 3 つの層に分解される
- バッチ レイヤー(バッチ レイヤー): データ セットの保存とバッチ ビューの生成という 2 つのコア機能。
- アクセラレーション レイヤー(スピード レイヤー): リアルタイム ビューを保存し、受信データ ストリームを処理してこれらのビューを更新します。
- サービス レイヤー(サービス レイヤー): ユーザーのクエリ リクエストに応答し、バッチ ビューとリアルタイム ビューの結果データ セットを最終データ セットにマージするために使用されます。
3.2 メリットとデメリット
利点:
優れた耐障害性、クエリの高い柔軟性、容易なスケーラビリティと拡張
欠点:
シーン全体をカバーすることによって発生するコーディングのオーバーヘッド。特定のシナリオに対してオフラインでトレーニングを再度行っても、ほとんどメリットはありません。再展開と移行には費用がかかります。
3.3 実際の事例
4. カッパのアーキテクチャ
4.1 構造図
- 入力データは、リアルタイム レイヤーのリアルタイム データ処理エンジンによって直接処理され、連続ソース データが処理されます。
- その後、サービス層のサービス バックエンドによってさらに処理されて、上位層のビジネス クエリが提供されます。
- 中間結果のデータはすべて保存する必要があり、これらのデータには履歴データと結果データが含まれ、これらは記憶媒体に一様に保存される。
4.2 メリットとデメリット
利点:
リアルタイム コードとオフライン コードを統合し、メンテナンスを容易にし、データ キャリバーを統合し、Lambda アーキテクチャでのオフライン データとのマージの問題を回避します。
欠点:
(1) メッセージ ミドルウェアによってキャッシュされるデータ量とバックトラッキング データにパフォーマンスのボトルネックがあります。
(2) リアルタイム データ処理では、相関関係を調べるために多数の異なるリアルタイム ストリームが発生する場合、リアルタイム コンピューティング システムの機能に大きく依存します。データ フロー シーケンスの問題によりデータ損失が発生する可能性があります。
(3) Kappa がオフライン データ処理モジュールを放棄したとき、オフライン コンピューティングのより安定した信頼性の高い機能も放棄しました。
4.3 実際の事例
- リアルタイム ログ分析プラットフォームは、Kappa アーキテクチャに基づいています。
- 統合データ処理エンジン Flink は、すべてのデータをリアルタイムで処理できます。
- そしてそれを ElasticSearch と OpenTSDB に保存します。
5. Lambda アーキテクチャと Kappa アーキテクチャの比較
| 内容を比較する | ラムダアーキテクチャ | カッパ建築 |
|---|---|---|
| 複雑さ | メンテナンスが必要2 つのシステム (エンジン)、非常に複雑 | 必要なのはメンテナンスのみ1 つのシステム (エンジン)、複雑さは低い |
| 開発費と保守費 | 開発費と保守費が高い | 開発コストと保守コストが低い |
| 計算オーバーヘッド | バッチ処理とリアルタイム計算を常に実行する必要があるため計算オーバーヘッドが大きい | 必要に応じて完全な計算を完了します。計算のオーバーヘッドは比較的小さい |
| リアルタイム | リアルタイム性を満足させる | リアルタイム性を満足させる |
| 履歴データ処理機能 | 完全なバッチ処理、大規模なスループット、および強力な履歴データ処理機能 | 完全なストリーミング処理、比較的低いスループット、比較的弱い履歴データ処理 |
| 使用するシーン | バッチ処理を直接サポートしており、 履歴データ分析およびクエリ シナリオ に適しています。できるだけ早く分析結果を取得できるようにしたいと考えています。バッチ処理をより直接的かつ効率的に行うことができ、これらのニーズに応えます。 | これは Lambda の代替アーキテクチャではありません。Kappa はバッチ処理のサポートを放棄し、増分データ書き込みシナリオのビジネス自体の分析ニーズにより優れています。 。 |
その他の関連する推奨事項:
システム アーキテクチャのマイクロサービス アーキテクチャ
システム アーキテクチャ設計のマイクロカーネル アーキテクチャ
Hongmeng オペレーティング システムアーキテクチャ
コラム:システム アーキテクト