ビッグ データ アーキテクチャは、従来のデータベース システムでは大きすぎるデータや複雑なデータの取り込み、処理、分析を処理するように設計されています。
ビッグ データ ソリューションには、通常、次の種類のワークロードが 1 つ以上含まれます。
- 保存されているビッグ データ ソースのバッチ処理
- 移動中のビッグ データのリアルタイム処理
- ビッグ データの対話型探索
- 予測分析と機械学習
ほとんどのビッグ データ アーキテクチャには、次のコンポーネントの一部またはすべてが含まれます。
データ ソース: ビッグ データ ソリューションは、1 つ以上のデータ ソースから始めることができます。
リレーショナル データベースなどのデータ ストア
Web サーバー ログ ファイルや API 応答など、アプリケーションによって生成されるファイル
ストリーミング デバイス、Webhook、リレーショナル データベースの上流にあるアプリケーションなどのリアルタイム データ ソース
データ ストレージ: バッチ処理操作のデータは、通常、さまざまな形式で大量の大きなファイルを格納できる分散ファイル ストアに格納されます。 この種のストアは、多くの場合 、データ レイクと呼ばれます。 このストレージを実装するためのオプションには、Azure Data Lake Storage または Microsoft Fabric OneLake が含まれます。
バッチ処理: データを分析用に準備し、過去のイベントや傾向を反映したレポートで使用できるようにする必要がある場合は、バッチ処理が役立ちます。 通常、これらのジョブには、ソース ファイルの読み取り、処理、新しいファイルへの出力の書き込みが含まれます。 オプションには、Fabric でのデータ フローまたはデータ パイプラインの使用が含まれます。
リアルタイム処理: ソリューションにリアルタイム ソースが含まれている場合、アーキテクチャには、ストリーム処理のためにリアルタイム メッセージをキャプチャして格納する方法が含まれている必要があります。 データは、クリーニング、変換、運用または分析アクションでの最終的な使用によって生成された瞬間から動き続けることができます。 多くのソリューションでは、スケールアウト処理、信頼性の高い配信、およびその他のメッセージ キュー セマンティクスをサポートする必要があります。 オプションには、Fabric Real-Time Intelligence イベントストリーム、Azure Event Hubs、Azure IoT Hub、Apache Kafka などがあります。
分析データ ストア: 多くのビッグ データ ソリューションは、分析用にデータを準備し、分析ツールを使用してクエリできる構造化された形式で処理されたデータを提供します。 シナリオに応じて、これらのクエリの処理に使用される分析データ ストアは、移動中のデータを処理する Microsoft Fabric のイベントハウスになり、ストリームが処理中に処理されます。 また、ほとんどの従来のビジネス インテリジェンス (BI) ソリューションやレイクハウス (ブロンズ、シルバー、ゴールド) で見られるように、ディメンション データ ウェアハウスを使用することもできます。 Microsoft Fabric には、イベントハウス、倉庫、レイクハウスなど、いくつかのオプションが用意されています。 ユース ケースに応じて、SQL または Spark を使用して各オプションのクエリを実行できます。 Fabric データ ストアの意思決定ガイドを使用して、決定を導きます。
分析とレポート: データ ソリューションの目標の 1 つは、分析とレポートを通じてデータに関する分析情報を提供することです。 ユーザーがデータを分析できるようにするために、アーキテクチャには、多次元オンライン分析処理 (OLAP) キューブや Azure Analysis Services の表形式データ モデルなどのデータ モデリング レイヤーが含まれる場合があります。 また、Power BI または Excel のモデリングおよび視覚化テクノロジを使用して、セルフサービス BI をサポートする場合もあります。 分析とレポートは、データ サイエンティストやデータ アナリストによる対話型データ探索の形式を取ることもできます。 これらのシナリオでは、Microsoft Fabric にはノートブックなどのツールが用意されています。このツールでは、ユーザーは SQL または選択したプログラミング言語を選択できます。
アクションとアラート: ビッグ データ ソリューションのもう 1 つの目標は、ビジネス プロセスの現在の状態に関する運用上の分析情報を提供することです。 アーキテクチャにはアクション システム レイヤーを含める必要があります。このレイヤーは、処理中のデータのリアルタイム ストリームを受け取り、組織内で発生する例外や異常を検出します。 ユーザーがレポートを確認する代わりに、これらのアラート システムを使用して、異常なアクティビティについてユーザーとリーダーシップに事前に通知することができます。 Real-Time インテリジェンス アクティベーター アラートは、この種のプロアクティブな監視を提供します。
オーケストレーション： ビッグ データ ソリューションは、ワークフローにカプセル化された繰り返しのデータ処理操作で構成できます。 これらのワークフローは、ソース データの変換、複数のソースとシンク間でのデータの移動、処理されたデータの分析データ ストアへの読み込み、またはレポートまたはダッシュボードへの結果の直接プッシュを行います。 これらのワークフローを自動化するには、Azure Data Factory や Microsoft Fabric パイプラインなどのオーケストレーション テクノロジを使用できます。
Microsoft では、ビッグ データ アーキテクチャ用の多くのサービスを、大まかに次のカテゴリにグループ化しています。
Microsoft Fabric などのサービスとしてのソフトウェア (SaaS) ソリューション
Data Lake Storage、Azure Stream Analytics、Event Hubs、IoT Hub、Azure Data Factory、Azure SQL Database、Azure Cosmos DB などのマネージド サービス
このアーキテクチャを使用する状況
次のアクションを実行する必要がある場合は、このアーキテクチャ スタイルを検討してください。
- データの生成中にリアルタイムでデータに対応します。
- 従来のデータベースでは大きすぎるボリュームにデータを格納して処理します。
- 分析とレポートのために非構造化データを変換します。
- Azure Machine Learning または Azure AI サービスを使用します。
メリット
テクノロジの選択肢: Microsoft Fabric は、SaaS インターフェイスを介してこれらのサービスの多くを提供し、事前にさまざまなコンポーネントを接続します。 このアプローチにより、エンドツーエンドのデータ ソリューションを構築するプロセスが簡略化されます。 また、Azure マネージド サービスを組み合わせて、既存のスキルやテクノロジへの投資を活用することもできます。
並列処理によるパフォーマンス: ビッグ データ ソリューションでは並列処理を利用します。これにより、大量のデータにスケーリングする高パフォーマンス ソリューションが可能になります。
エラスティック スケール: ビッグ データ アーキテクチャのすべてのコンポーネントは、スケールアウト プロビジョニングをサポートします。 その結果、小規模または大規模なワークロードに合わせてソリューションを調整し、使用するリソースに対してのみ支払うことができます。
既存のソリューションとの相互運用性: ビッグ データ アーキテクチャのコンポーネントは、モノのインターネット (IoT) 処理とエンタープライズ BI ソリューションにも使用されます。 この多様性により、データ ワークロード間で統合ソリューションを作成できます。
課題
スキルセット: 一部のビッグ データ テクノロジは高度に特殊化されており、一般的なアプリケーション アーキテクチャで使用されているものとは異なるフレームワークと言語に依存しています。 あるいは、より確立された言語を基盤とする新しい API が登場しています。
安全： ビッグ データ ソリューションは、通常、すべての静的データを一元化されたデータ レイクに格納することに依存します。 このデータへのアクセスのセキュリティ保護は、特に複数のアプリケーションとプラットフォームがデータを取り込んで使用する必要がある場合に困難になる可能性があります。
ベスト プラクティス
並列性を使用します。 ほとんどのビッグ データ処理テクノロジは、複数の処理ユニットにワークロードを分散します。 この分散では、静的データ ファイルを作成し、分割可能な形式で格納する必要があります。 Hadoop 分散ファイル システム (HDFS) などの分散ファイル システムでは、読み取りと書き込みのパフォーマンスを最適化できます。 複数のクラスター ノードが並列で実際の処理を実行するため、全体的なジョブ時間が短縮されます。 Parquet などの分割可能なデータ形式を使用することをお勧めします。
データをパーティション分割します。 バッチ処理は通常、毎週や毎月などの定期的なスケジュールで行われます。 処理スケジュールに合わせた一時的な期間に基づいて、テーブルなどのデータ ファイルとデータ構造をパーティション分割します。 この戦略により、データ インジェストとジョブのスケジュール設定が簡素化され、トラブルシューティングが容易になり、クエリのパフォーマンスが大幅に向上します。
読み取り時のスキーマ セマンティクスを適用します。 データ レイクを使用すると、構造化、半構造化、非構造化のいずれであっても、複数の形式のファイルのストレージを結合できます。 スキーマ読み取り時セマンティクスを適用します。このセマンティクスは、ストレージ時ではなく、処理中にスキーマをデータに投影します。 この方法により、ソリューションに柔軟性が追加され、データの入力規則と型チェックの原因となるデータ インジェスト中のボトルネックを防ぐことができます。
到着時にバッチ データを処理します。 従来の BI ソリューションでは、多くの場合、抽出、変換、読み込み (ETL) プロセスを使用してデータ ウェアハウスにデータを移動します。 ただし、大量のデータとさまざまな形式を使用するビッグ データ ソリューションでは、通常、抽出、読み込み、変換 (ELT) などの ETL のバリエーションが採用されます。
処理中のストリーミング データを処理します。 ストリーミング ソリューションの場合は、データの送信中にペイロードを変換します。 ネットワーク経由で処理するパケットがはるかに小さいため、生成時にこれらの小さな行セットを変換する方がはるかに簡単です。 変換されたストリームを、イベント ベースのデータ用に最適化されたエンジン (Real-Time Intelligence イベントハウスなど) に配置します。これにより、データをすぐにアクションに使用できるようになります。
使用量と時間コストのバランスを取ります。 バッチ処理ジョブの場合は、コンピューティング ノードのユニットごとのコストと、それらのノードを使用してジョブを完了する分単位のコストを考慮することが重要です。 たとえば、4 つのクラスター ノードでバッチ ジョブに 8 時間かかる場合があります。 ただし、ジョブでは最初の 2 時間にのみ 4 つのノードがすべて使用され、その後は 2 つのノードのみが必要になることがあります。 その場合、2 つのノードでジョブ全体を実行すると、ジョブの合計時間は増加しますが、2 倍にならないので、合計コストは少なくなります。 一部のビジネス シナリオでは、使用率の低いクラスター リソースを使用するコストが高いほど、処理時間が長くなる場合があります。
リソースを分離します。 可能な場合は、ワークロードに基づいてリソースを分離して、1 つのワークロードがすべてのリソースを使用し、もう一方が待機している間に発生するシナリオを回避します。
データ インジェストを調整します。 場合によっては、既存のビジネス アプリケーションがバッチ処理用のデータ ファイルを Azure ストレージ BLOB コンテナーに直接書き込む場合があります。この場合、Microsoft Fabric などのダウンストリーム サービスで使用できます。 ただし、多くの場合、オンプレミスまたは外部のデータ ソースからデータ レイクへのデータの取り込みを調整する必要があります。 Azure Data Factory や Microsoft Fabric でサポートされているオーケストレーション ワークフローまたはパイプラインを使用して、予測可能で一元的に管理されたデータ移動を実現します。
機密データを早期にスクラブする。 データ インジェスト ワークフローでは、データ レイクに格納されないように、プロセスの早い段階で機密データをスクラブする必要があります。
IoT アーキテクチャ
IoT は、ビッグ データ ソリューションの特殊なサブセットです。 次の図は、IoT で使用できる論理アーキテクチャを示しています。 この図は、アーキテクチャのイベント ストリーミング コンポーネントを強調しています。
クラウド ゲートウェイは、クラウド境界でデバイス イベントを取り込みます。 信頼性の高い待機時間の短いメッセージング システムを使用して、効率的なデータ転送を実現します。
デバイスは、クラウド ゲートウェイまたは フィールド ゲートウェイを介してイベントを直接送信する場合があります。 フィールド ゲートウェイは特殊なデバイスまたはソフトウェアであり、通常はデバイスと併置され、イベントを受信してクラウド ゲートウェイに転送します。 フィールド ゲートウェイでは、フィルター処理、集計、プロトコル変換などの機能を実行して、生のデバイス イベントを前処理することもできます。
インジェスト後、イベントは、データをルーティングしたり、分析やその他の処理を実行したりできる 1 つ以上の ストリーム プロセッサ を通過します。
次の一般的な種類の処理について考えてみましょう。
データは、Real-Time Intelligence のイベント ハウスなどのイベント ベースのデータ ストアに読み込まれ、建物の場所やデバイス情報などのメタデータを使用して IoT デバイスをコンテキスト化します。
リアルタイムでイベントストリームを分析して異常を検出したり、ローリング タイム ウィンドウでのパターンを認識したり、ストリームで特定の条件が発生したときにアラートをトリガーしたりします。
通知やアラームなど、デバイスからの特殊な非テレメトリ メッセージを処理。
機械学習モデルを使用してイベントをスコア付けし、異常を検出したり、障害を予測したり、デバイスの動作を分類したりします。
灰色のボックスには、イベントストリーミングに直接関連しない IoT システムのコンポーネントが表示されます。 これらは完全のためにここに含まれています。
デバイス レジストリは、プロビジョニングされたデバイスのデータベースです。 これにはデバイス ID が含まれており、通常は場所などのメタデータが含まれます。
プロビジョニング API は、新しいデバイスをプロビジョニングおよび登録するための一般的な外部インターフェイスです。
一部の IoT ソリューションでは 、コマンドおよび制御メッセージ をデバイスに送信できます。