Microsoft Fabric 決定ガイド: データ ストアを選択する
このリファレンス ガイドとシナリオ例を使用すると、Microsoft Fabric ワークロードのためのデータ ストアを選択するのに役立ちます。
データ ストアのプロパティ
この情報を使い、データのボリューム、種類、開発者のペルソナ、スキル セット、操作、その他の機能に基づいて、ウェアハウス、レイクハウス、Eventhouse、SQL データベース、Power BI データマートなどの Fabric データ ストアを比較してください。 これらの比較は、次の 2 つの表にまとめられています。
| レイクハウス | 倉庫 | イベントハウス | |
|---|---|---|---|
| データ量 | 無制限 | 無制限 | 無制限 |
| データの種類 | 非構造化、 半構造化、 構造化 |
構造化、 半構造化 (JSON) |
非構造化、 半構造化、 構造化 |
| 主要開発者ペルソナ | データ エンジニア、データ サイエンティスト | データ ウェアハウス開発者、データ アーキテクト、データ エンジニア、データベース開発者 | アプリ開発者、データ サイエンティスト、データ エンジニア |
| 主な開発スキル | Spark (Scala、PySpark、Spark SQL、R) | SQL | コードなし、KQL、SQL |
| データの編成 | フォルダーとファイル、データベース、テーブル | データベース、スキーマ、およびテーブル | データベース、スキーマ、およびテーブル |
| 操作を読み取ります。 | Spark、T-SQL | T-SQL、Spark* | KQL、T-SQL、Spark |
| 書き込み操作 | Spark (Scala、PySpark、Spark SQL、R) | T-SQL | KQL、Spark、コネクタ エコシステム |
| 複数テーブル トランザクション | いいえ | はい | はい、マルチテーブル インジェストの場合 |
| プライマリ開発インターフェイス | Azure Notebooks、Spark ジョブ定義 | SQL スクリプト | KQL クエリセット、KQL データベース |
| Security | RLS、CLS**、テーブル レベル (T-SQL)、Spark の場合はなし | オブジェクト レベル、RLS、CLS、DDL/DML、動的データ マスク | RLS |
| ショートカットを使用してデータにアクセスする | はい | はい | はい |
| ショートカットのソースにすることができます | はい (ファイルとテーブル) | はい (テーブル) | はい |
| アイテム間のクエリ | はい | はい | はい |
| 高度な分析 | 大規模なデータ処理、組み込みのデータ並列処理、フォールト トレランスのためのインターフェイス | 大規模なデータ処理、組み込みのデータ並列処理、フォールト トレランスのためのインターフェイス | 時系列ネイティブ要素、完全地理空間、クエリ機能 |
| 高度な書式設定のサポート | PARQUET、CSV、AVRO、JSON、任意の Apache Hive 互換ファイル形式を使って定義されたテーブル | PARQUET、CSV、AVRO、JSON、任意の Apache Hive 互換ファイル形式を使って定義されたテーブル | JSON などのフリー テキストと半構造化データの完全インデックス作成 |
| インジェストの待ち時間 | クエリにすぐに使用可能 | クエリにすぐに使用可能 | キューインジェスト、ストリーミングインジェストには数秒の待ち時間があります |
* Spark では、ショートカットを使ったテーブルからの読み取りはサポートされていますが、ビュー、ストアド プロシージャ、関数などへのアクセスはまだサポートされていません。
| Fabric SQL Database | Power BI データマート | |
|---|---|---|
| データ量 | 4 TB | 最大 100 GB |
| データの種類 | 構造化、 半構造化、 非構造化 |
構造化 |
| 主要開発者ペルソナ | AI 開発者、アプリ開発者、データベース開発者、DB 管理者 | データ サイエンティスト、データ アナリスト |
| 主な開発スキル | SQL | コードなし、SQL |
| データの編成 | データベース、スキーマ、テーブル | データベース、テーブル、クエリ |
| 操作を読み取ります。 | T-SQL | Spark、T-SQL |
| 書き込み操作 | T-SQL | データフロー、T-SQL |
| 複数テーブル トランザクション | はい、完全な ACID コンプライアンス | いいえ |
| プライマリ開発インターフェイス | SQL スクリプト | Power BI |
| Security | オブジェクト レベル、RLS、CLS、DDL/DML、動的データ マスク | 組み込みの RLS エディター |
| ショートカットを使用してデータにアクセスする | はい | いいえ |
| ショートカットのソースにすることができます | はい (テーブル) | いいえ |
| アイテム間のクエリ | はい | いいえ |
| 高度な分析 | T-SQL 分析機能、分析のために OneLake の Delta Parquet にレプリケートされたデータ | 自動パフォーマンス チューニングを使用したデータ処理のためのインターフェイス |
| 高度な書式設定のサポート | OLTP、JSON、ベクトル、グラフ、XML、空間、キー値のテーブル サポート | PARQUET、CSV、AVRO、JSON、任意の Apache Hive 互換ファイル形式を使って定義されたテーブル |
| インジェストの待ち時間 | クエリにすぐに使用可能 | クエリにすぐに使用可能 |
** T-SQL を使い、SQL 分析エンドポイントを介してレイクハウスで利用できる列レベル セキュリティ。
シナリオ
これらのシナリオを確認すると、Fabric でデータ ストアを選択する際に役立ちます。
シナリオ 1
プロの開発者であるスーザンは、Microsoft Fabric を初めて使用します。 データのクリーニング、モデリング、分析を始める準備はできましたが、データ ウェアハウスとレイクハウスのどちらを構築するかを決める必要があります。 前の表の詳細を確認した後、主な決定ポイントは使用可能なスキル セットであり、複数テーブルトランザクションの必要性です。
スーザンは、リレーショナル データベース エンジンでデータ ウェアハウスを構築し、SQL の構文と機能に精通して長い年月を費やしてきました。 大規模なチームについて考えると、このデータの主要なコンシューマーは、SQL および SQL 分析ツールのスキルも備えています。 Susan は Fabric ウェアハウスを使うことにしました。これにより、チームは主に T-SQL と対話しながら、組織内のすべての Spark ユーザーがデータにアクセスできるようになります。
スーザンは新しいデータ ウェアハウスを作成し、他の SQL サーバー データベースと同様に T-SQL を使用して操作します。 SQL Server でウェアハウスを構築するために作成した既存の T-SQL コードのほとんどは、Fabric データ ウェアハウスで動作するため、移行が簡単になります。 選択した場合は、SQL Server Management Studio などの他のデータベースと同じツールを使用することもできます。 Fabric ポータルの SQL エディターを使うことで、スーザンや他のチームメンバーは、その他のデータウェアハウスやレイクハウス内の Delta テーブルを参照する分析クエリを、3 部構成の名前を使ってデータベース間で簡単に作成できます。
シナリオ 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 での高速データ更新などの高度な分析機能のため、Eventhouse を使うことにしました。 Power BI と KQL を使用してクエリを実行して、現在と以前の期間を比較したり、新たな問題をすばやく特定したり、陸上および海上ルートの地理空間分析を提供したりできます。
シナリオ 5
Kirby は、運用データ用の .NET アプリケーションの開発経験を持つアプリケーション アーキテクトです。 完全な ACID トランザクション コンプライアンスと、リレーショナル整合性のために厳密に適用された外部キーを持つ高コンカレンシー データベースが必要です。 Kirby は、日々のデータベース管理を簡素化するために、自動パフォーマンス チューニングの利点を望んでいます。
Kirby は、Azure SQL Database と同じ SQL データベース エンジンを使用する Fabric SQL データベースに決めます。 Fabric SQL データベースは、1 日を通して需要に合わせて自動的にスケーリングします。 トランザクション テーブルの完全な機能と、シリアル化可能なスナップショットから読み取り可能なスナップショットまでのトランザクション分離レベルの柔軟性を備えています。 Fabric SQL データベースは、時間をかけて観察された実行プランからの強力なシグナルに基づいて、非クラスター化インデックスを自動的に作成および削除します。
Kirby のシナリオでは、運用アプリケーションのデータを Fabric の他のデータ (Spark 内、ウェアハウス内、Eventhouse のリアルタイム イベントから) と結合する必要があります。 すべての Fabric データベースには SQL 分析エンドポイントが含まれているため、Spark から、または DirectLake モードを使った Power BI クエリで、リアルタイムにデータにアクセスできます。 これらのレポート ソリューションは、プライマリ運用データベースを分析ワークロードのオーバーヘッドから解放し、非正規化を回避します。 Kirby には他の SQL データベースにも既存の運用データがあり、変換せずにそのデータをインポートする必要があります。 データ型を変換しないで既存の運用データをインポートするため、Kirby は Fabric SQL データベースにデータをインポートするためのデータ パイプラインを、Fabric Data Factory を使って設計します。