Microsoft Fabric 決定ガイド: データ ストアを選択する
このリファレンス ガイドとシナリオ例を使用すると、Microsoft Fabric ワークロードのためのデータ ストアを選択するのに役立ちます。
データ ストアのプロパティ
次の表では、データ ボリューム、種類、開発者ペルソナ、スキル セット、操作に基づいて、ウェアハウス、レイクハウス、Power BI データマート、イベントハウスなどのデータ ストアを比較します。 およびその他の機能。
| 倉庫 | レイクハウス | Power BI データマート | イベントハウス | |
|---|---|---|---|---|
| データ量 | 無制限 | 無制限 | 最大 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、動的データ マスキング | 行レベル、列レベル (SQL 分析エンドポイント経由でアクセスされるレイクハウスの場合)、テーブル レベル (T-SQL を使用する場合)、Spark の場合はなし | 組み込みの RLS エディター | 行レベルのセキュリティ |
| ショートカットを使用してデータにアクセスする | はい、3 部構成の名前を使用したレイクハウスを使用して | はい | いいえ | はい |
| ショートカットのソースにすることができます | はい (テーブル) | はい (ファイルとテーブル) | いいえ | はい |
| アイテム間のクエリ | はい、レイクハウス テーブルとウェアハウス テーブル全体でクエリを実行します | はい、レイクハウステーブルとウェアハウステーブル間でクエリを実行し、レイクハウス間でクエリを実行します (Spark を使用したショートカットを含む) | いいえ | はい。ショートカットを使用して KQL データベース、レイクハウス、ウェアハウス全体でクエリを実行します |
シナリオ
これらのシナリオを確認すると、Fabric でデータ ストアを選択する際に役立ちます。
シナリオ 1
プロの開発者であるスーザンは、Microsoft Fabric を初めて使用します。 データのクリーニング、モデリング、分析を開始する準備はできましたが、データ ウェアハウスまたはレイクハウスの構築を決定する必要があります。 前の表の詳細を確認した後、主な決定ポイントは使用可能なスキル セットであり、複数テーブルトランザクションの必要性です。
スーザンは、リレーショナル データベース エンジンでデータ ウェアハウスを構築し、SQL の構文と機能に精通して長い年月を費やしてきました。 大規模なチームについて考えると、このデータの主要なコンシューマーは、SQL および SQL 分析ツールのスキルも備えています。 スーザンは データ ウェアハウス を使用することにしました。これにより、チームは主に T-SQL と対話しながら、組織内のすべての Spark ユーザーがデータにアクセスできるようになります。
スーザンは新しいレイクハウスを作成し、レイクハウス SQL 分析エンドポイントを使用してデータ ウェアハウス機能にアクセスします。 Fabric ポータルを使用して、外部データ テーブルへのショートカットを作成し、/Tables フォルダーに配置します。 スーザンは、ショートカットを参照してレイクハウス内の Delta Lake データにクエリを実行する T-SQL クエリを記述できるようになりました。 ショートカットは SQL 分析エンドポイントのテーブルとして自動的に表示され、3 部構成の名前を使用して T-SQL を使用してクエリを実行できます。
シナリオ 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 での高速データ更新などの高度な分析機能のため、イベントハウスを使用することにしました。 Power BI と KQL を使用してクエリを実行して、現在と以前の期間を比較したり、新たな問題をすばやく特定したり、陸上および海上ルートの地理空間分析を提供したりできます。