ビッグ データ アーキテクチャは、従来のデータベース システムでは大きすぎるデータや複雑なデータの取り込み、処理、分析を管理します。 ビッグ データの領域に入るためのしきい値は、ツールとユーザーの機能によって組織によって異なります。 一部の組織では数百ギガバイトのデータを管理し、他の組織は数百テラバイトを管理しています。 ビッグ データセットを操作するためのツールが進化するにつれて、ビッグ データの定義は、データ サイズのみに焦点を当てることから、高度な分析から得られる値を強調することに変わるのです。 これらの種類のシナリオでは、大量のデータが含まれますが。
長年にわたって、データのランドスケープは変化してきました。 データで実行できること、実行できると期待されることは変化しています。 ストレージのコストは大幅に下がりましたが、データ収集の方法は拡大し続けます。 一部のデータは急速なペースで到着し、継続的な収集と観察が必要です。 他のデータは、より遅く届きますが、大きなまとまりで提供され、多くの場合、過去数十年分のデータとして提供されます。 高度な分析の問題や、機械学習を解決する必要がある問題が発生する可能性があります。 ビッグ データ アーキテクチャは、これらの課題の解決に努めています。
ビッグ データ ソリューションには、通常、次の種類のワークロードが 1 つ以上含まれます。
- 保存されているビッグ データ ソースのバッチ処理
- 移動中のビッグ データのリアルタイム処理
- ビッグ データの対話型探索
- 予測分析と機械学習
次のタスクを実行する必要がある場合は、ビッグ データ アーキテクチャを検討してください。
- 従来のデータベースに対して大きすぎるボリュームにデータを格納して処理する
- 分析とレポートのために非構造化データを変換する
- 無制限のデータ ストリームをリアルタイムまたは低待機時間でキャプチャ、処理、分析する
ビッグ データ アーキテクチャのコンポーネント
次の図は、ビッグ データ アーキテクチャの論理コンポーネントを示しています。 個々のソリューションには、この図のすべての項目が含まれていない場合があります。
ほとんどのビッグ データ アーキテクチャには、次のコンポーネントの一部またはすべてが含まれます。
データ ソース: すべてのビッグ データ ソリューションは、1 つ以上のデータ ソースから始まります。 たとえば、次のようになります。
- リレーショナル データベースなどのアプリケーション データ ストア。
- Web サーバー ログ ファイルなど、アプリケーションによって生成される静的ファイル。
- モノのインターネット (IoT) デバイスなどのリアルタイム データ ソース。
データ ストレージ: バッチ処理操作のデータは、通常、さまざまな形式で大量の大きなファイルを保持できる分散ファイル ストアに格納されます。 この種のストアは、多くの場合、 データ レイクと呼ばれます。 このストレージを実装するためのオプションには、Azure Data Lake Store、Azure Storage の BLOB コンテナー、または Microsoft Fabric の OneLake があります。
バッチ処理: データセットは大きいため、ビッグ データ ソリューションでは、多くの場合、実行時間の長いバッチ ジョブを使用してデータ ファイルを処理し、分析のためにデータをフィルター処理、集計、準備します。 通常、これらのジョブには、ソース ファイルの読み取り、処理、新しいファイルへの出力の書き込みが含まれます。 次のオプションを使用できます。
Azure Data Lake Analytics で U-SQL ジョブを実行します。
Azure HDInsight Hadoop クラスターで Hive、Pig、またはカスタム MapReduce ジョブを使用します。
HDInsight Spark クラスターで Java、Scala、または Python プログラムを使用します。
Azure Databricks ノートブックで Python、Scala、または SQL 言語を使用します。
Fabric ノートブックで Python、Scala、または SQL 言語を使用します。
リアルタイム メッセージ インジェスト: ソリューションにリアルタイム ソースが含まれている場合、アーキテクチャでは、ストリーム処理のためにリアルタイム メッセージをキャプチャして格納する必要があります。 たとえば、処理のために受信メッセージを収集する単純なデータ ストアを作成できます。 ただし、多くのソリューションでは、メッセージのバッファーとして機能し、スケールアウト処理、信頼性の高い配信、およびその他のメッセージ キュー セマンティクスをサポートするために、メッセージ インジェスト ストアが必要です。 ストリーミング アーキテクチャのこの部分は、多くの場合、 ストリーム バッファリングと呼ばれます。 オプションとして、Azure Event Hubs、Azure IoT Hub、Kafka などがあります。
ストリーム処理: ソリューションは、リアルタイム メッセージをキャプチャした後、分析のためにデータをフィルター処理、集計、および準備することによって処理する必要があります。 その後、処理されたストリーム データが出力シンクに書き込まれます。
Azure Stream Analytics は、無制限のストリームで動作する継続的に実行される SQL クエリを使用するマネージド ストリーム処理サービスです。
HDInsight クラスターまたは Azure Databricks では、Spark ストリーミングなどのオープンソースの Apache ストリーミング テクノロジを使用できます。
Azure Functions は、軽量ストリーム処理タスクに最適なイベント ドリブン コードを実行できるサーバーレス コンピューティング サービスです。
Fabric では、イベント ストリームと Spark 処理を使用したリアルタイム データ処理がサポートされています。
機械学習： バッチ処理またはストリーム処理から準備されたデータを分析するには、機械学習アルゴリズムを使用して、結果を予測したり、データを分類したりするモデルを構築できます。 これらのモデルは、大規模なデータセットでトレーニングできます。 結果のモデルを使用して、新しいデータを分析し、予測を行うことができます。
Azure Machine Learning を使用してこれらのタスクを実行します。 Machine Learning には、モデルを構築、トレーニング、デプロイするためのツールが用意されています。 また、Azure AI サービスの事前構築済み API を使用して、ビジョン、音声、言語、意思決定タスクなどの一般的な機械学習タスクを行うこともできます。
分析データ ストア: 多くのビッグ データ ソリューションは、分析のためにデータを準備し、分析ツールがクエリを実行できる構造化された形式で処理されたデータを提供します。 これらのクエリを処理する分析データ ストアは、Kimball スタイルのリレーショナル データ ウェアハウスにすることができます。 ほとんどの従来のビジネス インテリジェンス (BI) ソリューションでは、この種類のデータ ウェアハウスが使用されます。 または、HBase などの待機時間の短い NoSQL テクノロジや、分散データ ストア内のデータ ファイルに対するメタデータ抽象化を提供する対話型 Hive データベースを使用してデータを表示することもできます。
Azure Synapse Analytics は、大規模なクラウドベースのデータ ウェアハウス用のマネージド サービスです。
HDInsight では、対話型 Hive、HBase、Spark SQL がサポートされます。 これらのツールは、分析用のデータを提供できます。
Fabric には、SQL データベース、データ ウェアハウス、レイクハウス、イベントハウスなど、さまざまなデータ ストアが用意されています。 これらのツールは、分析用のデータを提供できます。
Azure には、Azure Databricks、Azure Data Explorer、Azure SQL Database、Azure Cosmos DB などの他の分析データ ストアが用意されています。
分析とレポート: ほとんどのビッグ データ ソリューションでは、分析とレポートを通じてデータに関する分析情報を提供するよう努めています。 ユーザーがデータを分析できるようにするために、アーキテクチャには、多次元オンライン分析処理キューブや Azure Analysis Services の表形式データ モデルなどのデータ モデリング レイヤーが含まれる場合があります。 また、Power BI または Excel のモデリングおよび視覚化テクノロジを使用して、セルフサービス BI をサポートする場合もあります。
データ サイエンティストまたはデータ アナリストは、対話型のデータ探索を通じて分析およびレポートを作成することもできます。 これらのシナリオでは、多くの Azure サービスが Jupyter などの分析ノートブックをサポートし、これらのユーザーが Python または Microsoft R で既存のスキルを使用できるようにします。大規模なデータ探索では、スタンドアロンまたは Spark で Microsoft R Server を使用できます。 Fabric を使用してデータ モデルを編集することもできます。データ モデルは、データ モデリングと分析の柔軟性と効率を提供します。
オーケストレーション： ほとんどのビッグ データ ソリューションは、ワークフローにカプセル化された繰り返しのデータ処理操作で構成されています。 この操作では、次のタスクを実行します。
- ソース データの変換
- 複数のソースとシンク間でデータを移動する
- 処理されたデータを分析データ ストアに読み込む
- 結果をレポートまたはダッシュボードに直接プッシュする
これらのワークフローを自動化するには、Azure Data Factory、Fabric、Apache Oozie、Apache Sqoop などのオーケストレーション テクノロジを使用します。
ラムダ アーキテクチャ
大規模なデータセットを操作する場合、クライアントが必要とする種類のクエリの実行に時間がかかる場合があります。 これらのクエリをリアルタイムで実行することはできません。 また、多くの場合、データセット全体で並列に動作する MapReduce などのアルゴリズムが必要です。 クエリ結果は生データとは別に格納され、さらにクエリを実行するために使用されます。
この方法の欠点の 1 つは、待機時間が発生することです。 処理に数時間かかる場合、クエリは数時間前の結果を返す可能性があります。 理想的には、精度が低下する可能性のある結果をリアルタイムで取得し、これらの結果をバッチ分析の結果と組み合わせる必要があります。
ラムダ アーキテクチャでは、データフロー用の 2 つのパスを作成することで、この問題に対処します。 システムに入ってくるすべてのデータは、次の 2 つのパスを経由します。
バッチ レイヤー (コールド パス) は、すべての受信データを生形式で格納し、データに対してバッチ処理を実行します。 この処理の結果は、バッチ ビューとして格納されます。
速度レイヤー (ホット パス) は、リアルタイムでデータを分析します。 このレイヤーは、精度と引き換えに待機時間が短くなるように設計されています。
バッチ レイヤーは、効率的なクエリを実行するためにバッチ ビューのインデックスを作成する サービス レイヤー にフィードされます。 速度レイヤーは、最新のデータに基づく増分更新でサービス レイヤーを更新します。
ホット パスに流れ込むデータは、速度レイヤーが課す待機時間の要件により、迅速に処理する必要があります。 迅速な処理により、データをすぐに使用できる状態が確保されますが、不正確性が生じる可能性があります。 たとえば、多数の温度センサーがテレメトリ データを送信する IoT シナリオを考えてみましょう。 速度レイヤーは、受信データのスライディング 時間枠を処理する場合があります。
コールド パスに流れ込むデータは、同じ低待機時間要件の対象ではありません。 コールド パスでは、大規模なデータセット間で高い精度の計算が提供されますが、時間がかかる場合があります。
最終的に、ホット パスとコールド パスは分析クライアント アプリケーションに収束します。 クライアントは、タイムリーに表示する必要があるが、正確でない可能性があるデータをリアルタイムで表示する必要がある場合は、ホット パスから結果を取得します。 それ以外の場合、クライアントはコールド パスから結果を選択して、より短い時間で正確なデータを表示します。 言い換えると、ホット パスは、比較的短い時間枠のデータを持ちます。その後、コールド パスのより正確なデータで結果を更新することができます。
バッチ レイヤーに格納されている生データは不変です。 受信データは既存のデータに追加され、前のデータは上書きされません。 特定のデータムの値に対する変更は、新しいタイムスタンプ付きイベント レコードとして格納されます。 タイムスタンプ付きイベント レコードを使用すると、収集されたデータの履歴全体を任意の時点で再計算できます。 システムの進化に応じて新しいビューを作成できるため、元の生データからバッチ ビューを再計算する機能が重要です。
カッパ アーキテクチャ
ラムダ アーキテクチャの欠点は、その複雑さです。 処理ロジックは、異なるフレームワークを介して、コールド パスとホット パスの 2 つの異なる場所に表示されます。 このプロセスにより、計算ロジックが重複し、両方のパスのアーキテクチャが複雑に管理されます。
Kappa アーキテクチャは、ラムダ アーキテクチャに代わるアーキテクチャです。 ラムダ アーキテクチャと同じ基本的な目標がありますが、すべてのデータはストリーム処理システムを介して 1 つのパスを通過します。
ラムダ アーキテクチャのバッチ レイヤーと同様に、イベント データは不変であり、データのサブセットではなく、そのすべてが収集されます。 データは、イベントのストリームとして、分散型のフォールト トレラントな統合ログに取り込まれます。 これらのイベントには順序が付けられ、イベントの現在の状態は、新しいイベントが追加されることでのみ変更されます。 ラムダ アーキテクチャの速度レイヤーと同様に、すべてのイベント処理が入力ストリームで実行され、リアルタイム ビューとして保持されます。
データセット全体を再計算する必要がある場合 (ラムダ アーキテクチャでのバッチ レイヤーの処理と同等)、ストリームを再生できます。 通常、このプロセスでは並列処理を使用して、タイムリーに計算を完了します。
レイクハウスのアーキテクチャ
Data Lake は、構造化データ (データベース テーブル)、半構造化データ (XML ファイル)、非構造化データ (イメージとオーディオ ファイル) を格納する一元化されたデータ リポジトリです。 このデータは生の元の形式であり、定義済みのスキーマは必要ありません。 Data Lake は大量のデータを処理できるため、ビッグ データの処理と分析に適しています。 データ レイクでは、低コストのストレージ ソリューションが使用されるため、コスト効率に優れた方法で大量のデータを格納できます。
データ ウェアハウスは、レポート、分析、BI の目的で構造化された半構造化データを格納する一元化されたリポジトリです。 データ ウェアハウスは、データの一貫した包括的なビューを提供することで、情報に基づいた意思決定を行うのに役立ちます。
Lakehouse アーキテクチャは、データ レイクとデータ ウェアハウスの最適な要素を組み合わせたものになります。 このパターンは、構造化データと非構造化データの両方をサポートする統合プラットフォームを提供することを目的としています。これにより、効率的なデータ管理と分析が可能になります。 通常、これらのシステムでは、生データと処理済みデータの両方を格納するために、Parquet や Optimized Row Columnar などのオープン形式の低コストのクラウド ストレージが使用されます。
レイクハウス アーキテクチャの一般的なユース ケースは次のとおりです。
統合分析: 履歴データ分析とリアルタイムデータ分析の両方に単一のプラットフォームを必要とする組織に最適
機械学習： データ管理機能を統合することで、高度な分析と機械学習のワークロードをサポートします
データ ガバナンス: 大規模なデータセット全体でコンプライアンスとデータ品質を確保する
IoTの
IoT は、インターネットに接続し、データを送受信するすべてのデバイスを表します。 IoT デバイスには、PC、携帯電話、スマート ウォッチ、スマート サーモスタット、スマート 冷蔵庫、コネクテッド 自動車、心臓モニタリング インプラントが含まれます。
接続されているデバイスの数は毎日増え、生成されるデータの量も増えます。 このデータは、多くの場合、大きな制約があり、場合によっては待機時間が長い環境で収集されます。 その他のケースでは、数千または数百万のデバイスが待機時間の短い環境からデータを送信します。これには、迅速なインジェストと処理が必要です。 これらの制約と一意の要件を適切に処理する計画を立てる必要があります。
イベント ドリブン アーキテクチャは、IoT ソリューションにとって重要です。 次の図は、IoT の論理アーキテクチャを示しています。 この図は、アーキテクチャのイベント ストリーミング コンポーネントを強調しています。
クラウド ゲートウェイは、信頼性の高い低待機時間メッセージング システムを介して、クラウド境界でデバイス イベントを取り込みます。
デバイスは、クラウド ゲートウェイまたは フィールド ゲートウェイを介してイベントを直接送信する場合があります。 フィールド ゲートウェイは特殊なデバイスまたはソフトウェアで、通常はデバイスと共に配置され、イベントを受信してクラウド ゲートウェイに転送します。 フィールド ゲートウェイは、フィルター処理、集計、またはプロトコル変換関数の実行を含む未加工のデバイス イベントを前処理することもできます。
インジェスト後、イベントは、ストレージなどの宛先にデータをルーティングしたり、分析やその他の処理を実行したりできる 1 つ以上の ストリーム プロセッサ を通過します。
一般的な処理の種類は次のとおりです。
アーカイブまたはバッチ分析のためにコールド ストレージにイベント データを書き込む。
ホット パス分析。 イベント ストリームをほぼリアルタイムで分析して、異常を検出したり、ローリング タイム ウィンドウでのパターンを認識したり、ストリームで特定の条件が発生したときにアラートをトリガーしたりします。
通知やアラームなど、デバイスからの特殊な非テレメトリ メッセージを処理。
機械学習。
前の図では、灰色のボックスは、イベント ストリーミングに直接関連しない IoT システムのコンポーネントです。 これらは、完成度を高める図に含まれています。
デバイス レジストリは、プロビジョニングされたデバイスのデータベースであり、デバイス ID と通常はデバイス メタデータ (場所など) を含みます。
プロビジョニング API は、新しいデバイスをプロビジョニングおよび登録するための一般的な外部インターフェイスです。
一部の IoT ソリューションでは 、コマンドおよび制御メッセージ をデバイスに送信できます。