システムアーキテクチャ設計における高度なスキル・ビッグデータアーキテクチャ設計の理論と実践

シリーズ記事の目次

システムアーキテクチャ設計の高度なスキル ・ソフトウェアアーキテクチャの概念、アーキテクチャスタイル、ABSD、アーキテクチャ再利用、DSSA (1) 【システムアーキテクト】 システムアーキテクチャ設計の高度なスキル ・システムの品質属性とアーキテクチャ評価 (2) 【
システムアーキテクト
】システムアーキテクチャ設計・ソフトウェア信頼性解析・設計(3) 【システムアーキテクチャ設計者】

现在的一切都是为将来的梦想编织翅膀，让梦想在现实中展翅高飞。
Now everything is for the future of dream weaving wings, let the dream fly in reality.

1. 従来のデータ処理システムの問題点

1.1 従来のデータベースのデータ過負荷の問題

従来のアプリケーションのデータ システム アーキテクチャを設計する場合、アプリケーションはデータベース システムに直接アクセスします。ユーザーの訪問数が増加すると、データベースは増大するユーザー要求の負荷をサポートできなくなり、データベース サーバーがユーザー要求にタイムリーに応答できなくなり、タイムアウト エラーが発生します。

この問題に対する一般的な解決策は次のとおりです。
(1) 非同期処理キューを追加する
(2) データベースの水平パーティショニングを確立する
(3) データベースのシャーディングまたは再シャーディングを確立する
(4) 読み取り/書き込み分離テクノロジーを導入する
(5) サブサーバーを導入するデータベースとサブテーブル技術

1.2 ビッグデータの特徴

ビッグデータは、大容量で障害が強いという特徴を持っています。構造が単調ではありません。第二に、種類が多様です。ビッグデータを処理する場合、データの過負荷、複雑なソース、多様なデータにより、従来のデータ処理システムのパフォーマンスは低下します。タイプやその他多くの理由がある 新しい手法を採用する必要がある コンピューティング アーキテクチャとインテリジェント アルゴリズムに代表される新しいテクノロジ、ビッグ データの応用は、従来の論理的な因果関係ではなく、データ間の相関関係を調査することに重点を置いているため、目的と価値ビッグデータの活用とは、新しい知識を発見し、洞察を得て、科学的な決定を下すことです。

最新のビッグデータ処理テクノロジーは主に次のカテゴリに分類されます。

(1)分散ファイルシステム Hadoop をベースとしています。
(2) Map/Reduce または Spark データ処理テクノロジを使用します。
(3) Kafaka データ送信メッセージ キューと Avro バイナリ形式を使用します。

1.3 ビッグデータの活用プロセス

ビッグデータの活用プロセスは、収集、クリーニング、統計、マイニングの4つのプロセスに分かれます。

2. ビッグデータ処理システムのアーキテクチャ分析

2.1 ビッグデータ処理システムが直面する課題

ビッグ データ処理システムが直面する主な課題は次のとおりです。
(1) 情報技術やその他の手段を使用して非構造化データおよび半構造化データを処理する方法。
(2) ビッグデータの複雑性、不確実性の特徴付けの特徴付け方法、およびビッグデータのシステムモデリングを調査する方法。
(3) データの異質性と意思決定の異質性の関係がビッグデータの知識発見と経営上の意思決定に及ぼす影響。

2.2 ビッグデータ処理システムの特徴

ビッグ データ処理システムが持つべき属性と特性には、
堅牢性とフォールト トレランス、低レイテンシー、水平スケーラビリティ (マシンのパフォーマンス向上によるスケーリング)、汎用、スケーラブル、アドホック クエリ (ユーザーが独自の要件に従ってクエリを実行する)、メンテナンスが最小限でデバッグ可能。

3. 典型的なビッグデータ アーキテクチャ

2.1 ラムダアーキテクチャ

Lambda アーキテクチャは、オフライン データとリアルタイム データを同時に処理するための耐障害性とスケーラブルな分散システムです。

図に示すように、Lambda アーキテクチャは次のとおりです。

Lambda アーキテクチャは、次の 3 つの層に分かれています:
(1)バッチ層: データセットを保存します。この層の中心的な機能は、メインデータセットを保存することです。バッチ層は、データセットに対してクエリ関数を事前計算し、クエリを構築します。対応するビュー。Batch Layer はオフライン データをうまく処理できますが、リアルタイムで継続的に生成され、リアルタイムのクエリ処理が必要なシーン データが多く、この状況には Speed Layer の方が適しています。

(2)アクセラレーション レイヤー (スピード レイヤー) : バッチ レイヤーはデータ セット全体を処理します。このレイヤーの中核機能は増分リアルタイム データを処理することであり、スピード レイヤーは最新の増分データ ストリームを処理します。効率を高めるため、スピード レイヤーは新しいデータを受信した後にリアルタイム ビューを継続的に更新しますが、バッチ レイヤーはオフライン データ セット全体に基づいてバッチ ビューを直接取得します。

(3)サービス層: この層の中心的な機能はユーザーのリクエストに応答することであり、バッチ ビューとリアルタイム ビューの結果データ セットを最終データ セットにマージするために使用されます。

Lambda アーキテクチャの利点と欠点:

メリット
(1) 耐障害性が高い。Lambda アーキテクチャは、ビッグ データ システムに対してよりフレンドリーなフォールト トレランスを提供し、エラーが発生した場合は、
アルゴリズムを修復したり、ビューを最初から再計算したりできます。
(2) クエリの柔軟性が高い。バッチ処理レイヤーにより、あらゆるデータに対するアドホック クエリが可能になります。
(3) 伸縮が容易です。すべてのバッチ処理、アクセラレーション、サービス層は簡単に拡張できます。どちらも完全分散システムであるため
、新しいマシンを追加することで簡単にスケールアップできます。
(4)拡張が容易です。ビューの追加は、メイン データ セットにいくつかの新しい関数を追加するのと同じくらい簡単です。

欠点
(1) シーン全体をカバーすることによって発生するコーディングのオーバーヘッド。
(2) 特定のシナリオに対してオフラインで再トレーニングすることは有益です。

2.2 カッパアーキテクチャ

Kappa アーキテクチャは Lamada アーキテクチャに基づいて最適化され、バッチ層アーキテクチャを削除し、データ チャネルをメッセージ キューに置き換えます。

使用シナリオの観点から見ると、Kappa アーキテクチャと Lambda の間には 2 つの主な違いがあります。

(1) Kappa は Lambda の代替アーキテクチャではなく、Lambda の簡易版です。Kappa はバッチ処理のサポートを放棄し、さまざまな時系列データなどの増分データ書き込みシナリオに対するビジネス自体の分析ニーズに優れています。シナリオ、自然存在時間 ウィンドウ、ストリーミング コンピューティングの概念は、リアルタイム コンピューティングと履歴補償タスクの要件を直接満たします。

(2) Lambda はバッチ処理を直接サポートしているため、履歴データ分析やクエリ シナリオにより適しています。たとえば、データ アナリストは条件の任意の組み合わせに従って履歴データの探索的分析を実行する必要があり、特定のリアルタイム要件とできるだけ早く分析を取得したいと考えているため、バッチ処理はこれらのニーズをより直接的かつ効率的に満たすことができます。

Kappa アーキテクチャの利点は、リアルタイム コードとオフライン コードを統合し、メンテナンスを容易にし、データ キャリバーの問題を統合し、Lambda アーキテクチャでのオフライン データのマージの問題を回避できることです。履歴データをクエリする場合、必要なのは再生だけです。保存された履歴データ。

Kappa の欠点も明らかです。

(1) メッセージミドルウェアがキャッシュするデータ量とトレースバックデータが性能のボトルネックとなります。通常、アルゴリズムには過去 180 日間のデータが必要ですが、メッセージ ミドルウェアがある場合は、間違いなく大きなプレッシャーがかかります。同時に、180 日分のデータを一度に遡って修正すると、大量のリアルタイム コンピューティング リソースが消費されます。

(2) リアルタイム データ処理では、相関関係を調べるために多数の異なるリアルタイム ストリームが発生する場合、リアルタイム コンピューティング システムの機能に大きく依存するため、データ フローのシーケンスによりデータ損失が発生する可能性があります。問題。

(3) Kappa がオフライン データ処理モジュールを放棄したとき、オフライン コンピューティングのより安定した信頼性の高い機能も放棄しました。Lambda はオフライン コンピューティングの安定性を保証しますが、デュアル システムのメンテナンス コストは高く、2 つのコード セットは後の運用とメンテナンスに困難をもたらします。Kappa フレームワークの上記の問題には現在いくつかの解決策があり、メッセージ キュー キャッシュ データのパフォーマンスの問題に対して、Kappa+ フレームワークは中間データの保存に HDFS を使用することを提案しています。Kappa フレームワークの表示層の機能が不十分であるという問題に対応して、ハイブリッド解析システムの解決策を提案する人もいます。

2.3 Lambda アーキテクチャと Kappa アーキテクチャの比較

Lambda アーキテクチャと Kappa アーキテクチャの比較

内容を比較する	ラムダアーキテクチャ	カッパ建築
複雑さと開発および保守コスト	2 つのシステム (エンジン) を保守する必要があるため、複雑であり、開発および保守コストが高くなります。	保守する必要があるシステム (エンジン) は 1 つだけであり、複雑さが少なく、開発および保守のコストも低くなります。
計算オーバーヘッド	バッチ処理とリアルタイム計算は常に実行する必要があるため、高いコンピューティング オーバーヘッドが必要になります。	必要に応じて完全な計算が実行され、計算のオーバーヘッドは比較的小さくなります。
リアルタイム	リアルタイム性を満足させる	リアルタイム性を満足させる
履歴データ処理機能	完全なバッチ処理、大規模なスループット、および強力な履歴データ処理機能	完全なストリーミング処理、比較的低いスループット、比較的弱い履歴データ処理機能

Lambda アーキテクチャと Kappa アーキテクチャの設計の選択

2 つのアーキテクチャの比較分析に基づいて、ビジネス ニーズ、技術要件、システムの複雑さ、開発および保守コスト、履歴データ処理能力が選択の際に考慮されました。計算オーバーヘッドには多少の違いはありますが、その差はそれほど大きくないため、要因として考慮されません。

(1)ビジネスニーズと技術要件
ユーザーは、自身のビジネスニーズに応じてアーキテクチャを選択する必要がありますが、ビジネスが Hadoop、Spark、Strom などの主要テクノロジーに必須に依存している場合は、Lambda アーキテクチャを選択する方が適切である可能性があります。 ; データ処理時にストリーミング コンピューティングを好み、Flink コンピューティング エンジンに依存する場合は、Kappa アーキテクチャを選択する方が適切な場合があります。

(2)複雑さ
プロジェクト内でアルゴリズム モデルのパラメーターを頻繁に変更する必要があり、Lambda アーキテクチャが 2 セットのコードを繰り返し変更する必要がある場合、明らかに Kappa アーキテクチャほど単純かつ便利ではありません。同時に、アルゴリズム モデルがバッチ処理とストリーミング コンピューティングを同時にサポートしている場合、またはデータ処理に 1 つのコードを使用したい場合は、Kappa アーキテクチャを選択できます。一部の複雑なケースでは、リアルタイム処理とオフライン処理の結果を統合できないことがあります。たとえば、一部の機械学習予測モデルでは、最初にオフライン バッチ処理を通じてトレーニング モデルを取得し、次にそれをリアルタイム ストリーミング処理に送信する必要があります。この場合、バッチ処理層とストリーム処理層を組み合わせることができないため、Lambda アーキテクチャを選択する必要があります。

(3)開発・保守コスト：
Lambda アーキテクチャは、2 つのシステムの開発、デプロイ、テスト、保守など、ある程度の開発・保守コストが必要となるため、経済的、技術的、人材的リソースに余裕のある開発者に適しています。Kappa アーキテクチャは 1 つのシステムのみを保守する必要があるため、開発と保守にあまりコストをかけたくない開発者に適しています。

(4)履歴データの処理能力
過去 10 年間の地域別降水量データなど、プロジェクトでは分析対象となる大量のデータセットを頻繁に扱う場合がありますが、この種のデータはバッチ処理システムの分析に適しており、Lambdaアーキテクチャを選択する必要があります。常に小規模なデータ セットを使用し、ストリーム処理システムが完全に使用可能な場合は、Kappa アーキテクチャを選択する必要があります。

4. ビッグデータアーキテクチャの実践

4.1 大規模なビデオネットワーク

図に示すように、あるネットワーク オリンピックの Lambda アーキテクチャは次のとおりです。

4.2 広告プラットフォーム

図に示すように、特定のオンライン広告プラットフォームの Lambda アーキテクチャは次のとおりです。

図に示すように、ある証券ビッグデータ システムのアーキテクチャは次のとおりです。

4.3 電子商取引のインテリジェントな意思決定ビッグデータ システム

図に示すように、電子商取引のインテリジェントな意思決定ビッグ データ システムのアーキテクチャは次のとおりです。