Microsoft Fabric 決定ガイド: データ ストアを選択する

  • [アーティクル]

このリファレンス ガイドとシナリオ例を使用すると、Microsoft Fabric ワークロードのためのデータ ストアを選択するのに役立ちます。

データ ストアのプロパティ

データ ウェアハウス レイクハウス Power BI データマート KQL データベース (Eventhouse)
データ量 無制限 無制限 最大 100 GB 無制限
データの種類 構造化 非構造化,半構造化,構造化 構造化 非構造化、半構造化、構造化
主要開発者ペルソナ データ ウェアハウス開発者、SQL エンジニア データ エンジニア、データ サイエンティスト 市民開発者 市民データ サイエンティスト、データ エンジニア、データ サイエンティスト、SQL エンジニア
主な開発者スキル セット SQL Spark(Scala、PySpark、Spark SQL、R) コードなし、SQL コードなし、KQL、SQL
データの編成 データベース、スキーマ、およびテーブル フォルダーとファイル、データベース、テーブル データベース、テーブル、クエリ データベース、スキーマ、およびテーブル
操作を読み取ります。 T-SQL、Spark (ショートカットを使用したテーブルからの読み取りをサポートし、ビュー、ストアド プロシージャ、関数などへのアクセスはまだサポートしていません) Spark,T-SQL Spark,T-SQL,Power BI KQL、T-SQL、Spark、Power BI
書き込み操作 T-SQL Spark(Scala、PySpark、Spark SQL、R) データフロー、T-SQL KQL、Spark、コネクタ エコシステム
複数テーブル トランザクション はい いいえ いいえ はい、マルチテーブル インジェストの場合はそうです。 更新ポリシーを参照してください。
プライマリ開発インターフェイス SQL スクリプト Spark ノートブック,Spark ジョブ定義 Power BI KQL クエリセット、KQL データベース
Security オブジェクト レベル (テーブル、ビュー、関数、ストアド プロシージャなど)、列レベル、行レベル、DDL/DML、動的データ マスキング 行レベル、テーブル レベル (T-SQL を使用する場合)、Spark の場合はなし 組み込みの RLS エディター 行レベルのセキュリティ
ショートカットを使用してデータにアクセスする はい (レイクハウスを間接的に経由) はい いいえ はい
ショートカットのソースにすることができます はい (テーブル) はい (ファイルとテーブル) いいえ はい
アイテム間のクエリ はい、レイクハウス テーブルとウェアハウス テーブル全体でクエリを実行します はい、レイクハウステーブルとウェアハウステーブル間でクエリを実行し、レイクハウス間でクエリを実行します (Spark を使用したショートカットを含む) いいえ はい。ショートカットを使用して KQL データベース、レイクハウス、ウェアハウス全体でクエリを実行します
高度な分析 時系列ネイティブ要素、完全地理空間格納およびクエリ機能
高度な書式設定のサポート JSON などのフリー テキストと半構造化データの完全インデックス作成
インジェストの待ち時間 キューインジェスト、ストリーミングインジェストには数秒の待機時間があります

Note

Eventhouse は、複数の KQL データベース用のワークスペースです。 KQL データベースは一般提供されますが、Eventhouse はプレビュー段階です。 詳細については、「Eventhouse の概要 (プレビュー)」を参照してください。

シナリオ

これらのシナリオを確認すると、Fabric でデータ ストアを選択する際に役立ちます。

シナリオ 1

プロの開発者であるスーザンは、Microsoft Fabric を初めて使用します。 データのクリーニング、モデリング、分析を開始する準備はできましたが、データ ウェアハウスまたはレイクハウスの構築を決定する必要があります。 前の表の詳細を確認した後、主な決定ポイントは使用可能なスキル セットであり、複数テーブルトランザクションの必要性です。

スーザンは、リレーショナル データベース エンジンでデータ ウェアハウスを構築し、SQL の構文と機能に精通して長い年月を費やしてきました。 大規模なチームについて考えると、このデータの主要なコンシューマーは、SQL および SQL 分析ツールのスキルも備えています。 スーザンは データ ウェアハウス を使用することにしました。これにより、チームは主に T-SQL と対話しながら、組織内のすべての Spark ユーザーがデータにアクセスできるようになります。

シナリオ 2

データ エンジニアである Rob は、数テラバイトのデータを Fabric に格納してモデル化する必要があります。 チームには、PySpark と T-SQL のスキルが混在しています。 T-SQL クエリを実行しているチームのほとんどはコンシューマーであるため、INSERT、UPDATE、または DELETE ステートメントを記述する必要はありません。 残りの開発者はノートブックでの作業に慣れ、データは Delta に格納されているため、同様の SQL 構文と対話できます。

Rob は レイクハウ を使用することにしました。これにより、Data Engineering チームはデータに対して多様なスキルを使用しながら、T-SQL の高度なスキルを持つチーム メンバーがデータを使用できるようになります。

シナリオ 3

市民開発者である Ash は、Power BI 開発者です。 Excel、Power BI、Office に精通しています。 ビジネス ユニットのデータ製品を構築する必要があります。 彼らは、データ ウェアハウスやレイクハウスを構築するスキルが十分に備わっていないことを知っており、ニーズやデータ ボリュームには多すぎるように見えます。 前の表の詳細を確認し、主な決定ポイントは、独自のスキルと、セルフサービスの必要性、コード機能なし、100 GB 以下のデータ ボリュームであることを確認します。

Ash は、Power BI と Microsoft Office に精通しているビジネス アナリストと連携し、Premium 容量サブスクリプションが既にあることを認識しています。 大規模なチームについて考えるにつれて、このデータの主要なコンシューマーはアナリストであり、コードなしおよび SQL 分析ツールに精通している可能性があることに気付きます。 Ash は Power BI データマート を使用することにしました。これにより、チームはコードなしのエクスペリエンスを使用して、機能を迅速に構築できます。 クエリは Power BI と T-SQL を使用して実行できますが、組織内のすべての Spark ユーザーもデータにアクセスできます。

シナリオ 4

Daisy は、大規模なグローバル小売チェーンのサプライ チェーンのボトルネックを分析するために Power BI を使用した経験を持つビジネス アナリストです。 数十億行のデータを処理できるスケーラブルなデータ ソリューションを構築する必要があり、ビジネス上の意思決定に使用できるダッシュボードとレポートを構築するために使用できます。 データは、さまざまな構造化、半構造化、非構造化形式でプラント、サプライヤー、荷送人、およびその他のソースから取得されます。

Daisy は、スケーラビリティ、迅速な応答時間、および時系列分析、地理空間関数、Power BI での高速データ更新などの高度な分析機能のため、KQL データベースを使用することにしました。 Power BI と KQL を使用してクエリを実行して、現在と以前の期間を比較したり、新たな問題をすばやく特定したり、陸上および海上ルートの地理空間分析を提供したりできます。

関連するコンテンツ