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

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

サービス レイヤーは、ホット パスとコールド パスの両方から処理されたデータを処理します。 ラムダ アーキテクチャでは、サービス レイヤーは 2 つのレイヤーに分割されます。 速度サービス レイヤーには、増分処理されたデータが含まれています。 バッチ 処理レイヤーには、バッチ処理された出力が含まれています。

サービス レイヤー全体では待機時間の短いランダム 読み取り を強力にサポートする必要があります。このストアへのデータのバッチ読み込みでは望ましくない遅延が発生するため、速度レイヤーのデータ ストレージでもランダム 書き込 みをサポートする必要があります。 逆に、バッチ レイヤーのデータ ストレージでは、ランダムな書き込みではなく、バッチ書き込みをサポートする必要があります。

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

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

分析データ ストアの選択

Microsoftには、ニーズに応じて、ストレージを提供するデータに関するいくつかのオプションが用意されています。

異なるデータベース モデルは、さまざまな種類のタスクに適しています。

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

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

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

    • 名、ミドルネーム、姓
    • 郵便の宛先
    • 生年月日や性別などのプロファイル情報

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

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

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

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

主要な選択条件

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

  • データのホットパスとして使えるサービングストレージが必要ですか。 [はい] の場合は、速度サービス レイヤーに最適なオプションを選択します。

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

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

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

能力マトリックス

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

一般的な機能

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

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

[2] Kusto クエリ言語 (KQL) では、部分的な T-SQL 言語がサポートされています。

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

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

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

スケーラビリティ機能

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

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

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

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

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

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

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

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

セキュリティ機能

能力 Lakehouse Data Warehouse Eventhouse Fabric SQL データベース 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] プライベート リンクとMicrosoft Entra 条件付きアクセスを使用して、Fabric リソースへのアクセスを制限します。

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

[4] Fabric SQL エンドポイント レベルで適用します。

貢献者達

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

主要著者:

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

次のステップ

  • Last updated on