次の方法で共有

Azure で使用する分析データ ストアの選択

ビッグ データ アーキテクチャでは、多くの場合、分析ツールを使用してクエリを実行できる構造化形式で処理されたデータを提供する分析データ ストアが必要です。 ホット パス データとコールド パス データの両方のクエリをサポートする分析データ ストアは、まとめて サービス レイヤーまたは データ サービス ストレージと呼ばれます。

サービス レイヤーは、ホット パスとコールド パスの両方から処理されたデータを処理します。 ラムダ アーキテクチャでは、サービス レイヤーは 2 つのレイヤーに分割されます。 速度サービス レイヤーには、増分処理されたデータが含まれています。 バッチ 処理レイヤーには、バッチ処理された出力が含まれています。 サービス レイヤーでは、待機時間が短いランダム読み取りを強力にサポートする必要があります。 速度レイヤーのデータ ストレージでは、このストアにデータをバッチ読み込むと望ましくない遅延が発生するため、ランダム書き込みもサポートする必要があります。 または、バッチ レイヤーのデータ ストレージでは、ランダムな書き込みではなく、バッチ書き込みをサポートする必要があります。

すべてのデータ ストレージ タスクに最適なデータ管理の選択肢は 1 つもありません。 各データ管理ソリューションは、異なるタスクに合わせて最適化されています。 ほとんどの実際のクラウド アプリとビッグ データ プロセスには、さまざまなデータ ストレージ要件があり、多くの場合、データ ストレージ ソリューションの組み合わせを使用します。

Microsoft Fabricなどの最新の分析ソリューションは、さまざまな分析ニーズを満たすためにさまざまなデータ サービスとツールを統合する包括的なプラットフォームを提供します。 Fabric には、組織全体の単一の統合された論理データ レイクである OneLake が含まれています。 OneLake は、すべての組織データを 1 つの場所に格納、管理、セキュリティで保護するように設計されています。 この柔軟性により、組織はさまざまなデータ ストレージと処理の要件に対応できます。

分析データ ストアの選択

Azure にはデータ サービス ストレージのオプションがいくつかあり、必要に応じて選択できます。

次のデータベース モデルは、さまざまな種類のタスクに最適化されています。

  • キー値データベースには、キー値 ごとに 1 つのシリアル化されたオブジェクトが格納されます。 これらは、取得が特定のキーに基づいている場合に大量のデータを管理するのに適しています。他の項目プロパティを照会する必要はありません。

  • ドキュメント データベース は、値が ドキュメントであるキー値データベースです。 このコンテキストでは、ドキュメントは名前付きフィールドと値のコレクションです。 データベースは通常、XML、YAML、JSON、バイナリ JSON などの形式でデータを格納しますが、プレーン テキストを使用する場合があります。 ドキュメント データベースでは、キー以外のフィールドに対してクエリを実行し、セカンダリ インデックスを定義してクエリの効率を向上させることができます。 この機能により、ドキュメント データベースは、ドキュメント キーの値よりも複雑な条件に基づいてデータを取得する必要があるアプリケーションに適しています。 たとえば、製品 ID、顧客 ID、顧客名などのフィールドに対してクエリを実行することができます。

  • 列ストア データベース は、各列をディスクに個別に格納するキー値データ ストアです。 ワイド列ストア データベースは、単一の列だけでなく、列ファミリを格納する列ストア データベースの一種です。 たとえば、国勢調査データベースには、次の項目ごとに個別の列ファミリがある場合があります。

    • 人の名前、ミドルネーム、姓

    • そのユーザーの住所

    • そのユーザーのプロフィール情報 (生年月日や性別など)

    このデータベースは、各列ファミリを個別のパーティションに格納し、さらに 1 人のすべてのデータと同じキーへの関連付けを維持することができます。 アプリケーションは、エンティティのすべてのデータをスキャンすることなく、1 つの列ファミリを読み取ることができます。

  • グラフ データベースは 、オブジェクトとリレーションシップのコレクションとして情報を格納します。 グラフ データベースは、オブジェクトのネットワークとオブジェクト間のリレーションシップにまたがるクエリを効率的に実行することができます。 たとえば、人事データベースではオブジェクトは従業員の可能性があります。また、"佐藤さんのために直接的または間接的に働いているすべての従業員を検索する" などのクエリを簡単にすることもできます。

  • テレメトリ データベースと時系列データベースは、オブジェクトの追加専用のコレクションです。 テレメトリ データベースは、さまざまな列ストアとメモリ内構造のデータに効率的にインデックスを付けます。 この機能により、膨大な量のテレメトリと時系列データを格納および分析するための最適な選択肢になります。

Fabric では、キー値、ドキュメント、列ストア、グラフ、テレメトリ データベースなど、さまざまなデータベース モデルがサポートされています。 この柔軟性により、さまざまな分析タスクのスケーラビリティが確保されます。 分析ワークロードに適した Fabric データストアを選択するには、「 Fabric の決定ガイド: データストアを選択する」を参照してください。

主要な選択条件

選択プロセスを絞り込むには、次の条件を考慮してください。

  • データのホットパスとして使えるサービングストレージが必要ですか。 "はい" の場合、スピード サービス レイヤーに合わせて最適化されたオプションに絞り込みます。

  • クエリが複数のプロセスまたはノードに自動的に分散される、超並列処理のサポートが必要ですか? "はい" の場合、クエリのスケールアウトをサポートするオプションを選択します。

  • リレーショナル データ ストアを使用したいですか。 その場合は、リレーショナル データベース モデルを持つオプションに絞り込みます。 ただし、一部の非リレーショナル ストアではクエリ用の SQL 構文がサポートされており、SQL Endpoint などのツールを使用して、OneLake などの非リレーショナル データ ストアのクエリを実行できます。

  • 時系列データを収集しますか? 追加専用データを使用しますか。 Fabric OneLake では、Analysis Services、T-SQL、Apache Spark など、複数の分析エンジンがサポートされています。 Fabric Eventhouse を使用すると、時系列データのさまざまなデータ処理とクエリのニーズに適しています。

能力マトリックス

次の表は、これらのマネージド サービスの機能の主な違いをまとめたものです。

一般的な機能

能力 ファブリック レイクハウス Fabric Warehouse Fabric Eventhouse Fabric SQL Database Azure SQL Database Azure Cosmos DB Analysis Services
プライマリ データベース モデル Apache Parquet を使用した統合データレイク、リレーショナルデータベース、ユーザー管理のデルタレイク形式 統合されたデータレイクとリレーショナルシステム、Apache Parquet を使用したシステム管理のデルタレイク形式 時系列の追加指向データ ストア、グラフ、ベクター リレーショナル（列ストア インデックスを使用する場合における列ストア形式） リレーショナル（列ストア インデックスを使用する場合における列ストア形式） ドキュメントストア、グラフデータベース、キー・バリューストア、ワイドカラムストア 表形式のセマンティック モデル
SQL 言語のサポート Yes1 はい ○2 はい はい はい いいえ
スピード サービス レイヤーに合わせて最適化 はい はい ○3 あり4 ○5 はい いいえ

[1] SQL Analytics エンドポイント経由の T-SQL。

[2] KQL には部分的な T-SQL 言語のサポートがあります。

[3] キューに登録されたインジェストとストリーミング インジェストをサポートする。

[4] 待機時間の短いアクセスとリアルタイムの更新でトランザクションの精度をサポートします。

[5] メモリ最適化テーブルとハッシュインデックスまたは非クラスター化インデックスの使用。

スケーラビリティ機能

能力 ファブリック レイクハウス Fabric Warehouse Fabric Eventhouse Fabric SQL Database Azure SQL Database Azure Cosmos DB Analysis Services
高可用性のための冗長リージョン サーバー はい1,2 はい1,2 はい はい はい はい はい
クエリのスケールアウトをサポート ○3 あり4 ○5 はい いいえ はい はい
動的スケーラビリティ (スケールアップ) ○3 あり4 ○5 はい はい はい はい
データのメモリ内キャッシュをサポート はい6 はい6 はい7 はい はい はい いいえ

[1] SQL エンドポイントはグローバル トラフィック マネージャー経由でルーティングされますが、データは割り当てられたファブリック容量リージョンで常に処理されます。

[2] Lakehouse と Warehouse は、エンジン間のクエリとレプリケーションをサポートする Delta Parquet 形式を使用して OneLake にデータを格納します。

Lakehouse では、非構造化データと構造化データに対して Spark ベースのスケールアウトがサポートされている[3]。

[4] Warehouse では T-SQL を使用し、マルチテーブル トランザクション、自律ワークロード管理、分散クエリ処理 (DQP) をサポートしています。 DQP はクラスター マネージャーのように機能し、クエリの複雑さに基づいてコンピューティング リソースを動的に割り当てる。

Eventhouse は KQL と SQL フェデレーションをサポートし、複数のソース間でリアルタイム分析を可能にし、ホット キャッシュの使用量が最大 95%を超える場合はコンピューティング リソースをスケールアップします。

[6] Spark ジョブのインテリジェント キャッシュ、 メモリ内キャッシュ、SQL 分析エンドポイントの 結果セット キャッシュ 。

[7] 頻繁にアクセスされるデータは、メモリ内および SSD ストレージを含むホット キャッシュに格納されます。

セキュリティ機能

能力 ファブリック レイクハウス Fabric Warehouse Fabric Eventhouse Fabric SQL Database Azure SQL Database Azure Cosmos DB Analysis Services
認証 Microsoft Entra ID Microsoft Entra ID Microsoft Entra ID Microsoft Entra ID SQL または Microsoft Entra ID アクセス制御（IDとアクセス管理）を介したデータベースユーザーまたはMicrosoft Entra ID Microsoft Entra ID
保存データの暗号化 はい はい はい はい Yes1 はい はい
行レベルのセキュリティ はい はい はい はい はい いいえ はい
ファイアウォールをサポート ○2 ○2 ○3 はい はい はい はい
動的データマスキング あり4 あり4 いいえ はい はい いいえ いいえ

[1] 透過的なデータ暗号化を使用して、保存データの暗号化と暗号化解除を行う必要があります。

[2] プライベート リンクと Entra 条件付きアクセスを使用して、Fabric リソースへのアクセスを制限できます。

Fabric Eventhouse および Real-Time Intelligence ワークロードは、セキュリティで保護されたエンドポイントを介したルーティングを使用して、Kafka、Azure Event Hubs、AMQP などのセキュリティで保護されたソースからデータを取り込むことができます。

[4] これは Fabric SQL エンドポイント レベルで適用できます

貢献者達

Microsoft では、この記事を保持しています。 次の共同作成者がこの記事を書きました。

主要な著者:

公開されていない LinkedIn プロフィールを見るには、LinkedIn にサインインしてください。

次のステップ