次の方法で共有

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

  • [アーティクル]

このリファレンス ガイドとシナリオ例を使用して、Microsoft Fabric ワークロードのデータ ストアを選択します。

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

この情報を使用して、データ ボリューム、種類、開発者ペルソナ、スキル セット、操作、およびその他の機能に基づいて、ウェアハウス、lakehouse、Eventhouse、SQL データベース、Power BI データマートなどの Fabric データ ストアを比較します。 これらの比較は、次の 2 つの表にまとめられます。

表 1 / 2 レイクハウス 倉庫 Eventhouse
データ量 無制限 無制限 無制限
データの種類 非構造化、
半構造化、
構造化		 構造化、
半構造化 (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 データベース
セキュリティ RLS、CLS**、テーブル レベル (T-SQL)、Spark の場合はなし オブジェクト レベルの、RLS 、CLS、DDL/DML、動的データ マスキング RLS
ショートカット を使用してデータにアクセスする はい はい(SQL 分析エンドポイント経由) はい
ショートカット のソースにすることができます はい (ファイルとテーブル) はい (テーブル) はい
項目間のクエリ はい はい はい
高度な分析 大規模データ処理、内蔵データ並列処理、フォールトトレランスのためのインターフェース 大規模データ処理、障害耐性、および組み込みのデータ並列処理のためのインターフェイス Time Series ネイティブ要素、完全な地理空間およびクエリ機能
高度な書式設定のサポート PARQUET、CSV、AVRO、JSON、Apache Hive 互換ファイル形式を使用して定義されたテーブル PARQUET、CSV、AVRO、JSON、Apache Hive 互換ファイル形式を使用して定義されたテーブル フリー テキストと JSON などの半構造化データの完全なインデックス作成
インジェスト遅延 クエリにすぐに使用できる クエリにすぐに使用できる キューインジェスト、ストリーミングインジェストには数秒の待ち時間があります

* Spark では、ショートカットを使用したテーブルからの読み取りがサポートされています。ビュー、ストアド プロシージャ、関数などのアクセスはまだサポートされていません。

表 2/2 Fabric SQL データベース Power BI データマート
データ量 4テラバイト (4 TB) 最大 100 GB
データの種類 構造化、
半構造化、
非構造化		 構造化
主要開発者ペルソナ AI 開発者, アプリ開発者, データベース開発者, DB 管理者 データ サイエンティスト、データ アナリスト
主な開発スキル SQL コードなし、SQL
によって整理されたデータ データベース、スキーマ、テーブル データベース、テーブル、クエリ
読み取り操作 T-SQL Spark、T-SQL
書き込み操作 T-SQL データフロー、T-SQL
複数テーブル トランザクション はい、完全なACID準拠です。 いいえ
主要開発インターフェース SQL スクリプト Power BI
セキュリティ オブジェクト レベル、RLS、CLS、DDL/DML、動的データ マスク 組み込みの RLS エディター
ショートカット を使用してデータにアクセスする はい いいえ
ショートカット のソースにすることができます はい (テーブル) いいえ
項目間のクエリ はい いいえ
高度な分析 T-SQL 分析機能、分析のために OneLake の Delta Parquet にレプリケートされたデータ 自動パフォーマンス チューニングを使用したデータ処理のインターフェイス
高度な書式設定のサポート OLTP、JSON、ベクター、グラフ、XML、空間、キー値のテーブルサポート PARQUET、CSV、AVRO、JSON、Apache Hive 互換ファイル形式を使用して定義されたテーブル
インジェストの待ち時間 クエリにすぐに使用できる クエリにすぐに使用できる

** T-SQL を使用して、SQL 分析エンドポイントを介して Lakehouse で利用できる列レベルのセキュリティ。

シナリオ

Fabric でのデータ ストアの選択に関するヘルプについては、これらのシナリオを確認してください。

シナリオ 1

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

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

スーザンは新しいデータ ウェアハウスを作成し、他の SQL サーバー データベースと同様に T-SQL を使用して操作します。 SQL Server でウェアハウスを構築するために作成した既存の T-SQL コードのほとんどは、Fabric データ ウェアハウスで動作するため、移行が簡単になります。 選択した場合は、SQL Server Management Studio などの他のデータベースと同じツールを使用することもできます。 Fabric ポータルの SQL エディターを使用して、スーザンや他のチームメンバーは、たった三部構成の名前を使用するだけでデータベース間のクエリを実行し、他のデータウェアハウスとレイクハウス内の Delta テーブルを参照する分析クエリを作成します。

シナリオ 2

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

Rob は、lakehouseを使用することにしました。これにより、データ エンジニアリング チームはデータに対して多様なスキルを使用しながら、T-SQL の高度なスキルを持つチーム メンバーがデータを使用できるようになります。

シナリオ 3

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

Ash は、Power BI と Microsoft Office に精通しているビジネス アナリストと連携し、Premium 容量サブスクリプションを既に持っていることを認識しています。 大規模なチームについて考えると、このデータの主なコンシューマーは、コーディング不要の分析ツールと SQL 分析ツールに精通しているアナリストであることを認識しています。 Ash は、power BI datamartを使用することにしました。これにより、チームはコードなしのエクスペリエンスを使用して、迅速に機能を構築できます。 クエリは 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 Database エンジンを使用して、FabricのSQL データベースを決定します。 Fabric の SQL データベースは、1 日を通して需要に合わせて自動的にスケーリングされます。 トランザクション テーブルの完全な機能と、シリアル化可能なスナップショットから読み取り可能なスナップショットまでのトランザクション分離レベルの柔軟性を備えています。 Fabric の SQL データベースは、時間の経過と同時に観察された実行プランからの強力なシグナルに基づいて、非クラスター化インデックスを自動的に作成および削除します。

Kirby のシナリオでは、運用アプリケーションのデータを Fabric の他のデータ (Spark、ウェアハウス、Eventhouse のリアルタイム イベント) と結合する必要があります。 すべての Fabric データベースには SQL 分析エンドポイントが含まれているため、Spark または DirectLake モードを使用した Power BI クエリを使用してリアルタイムでデータにアクセスできます。 これらのレポート ソリューションは、分析ワークロードのオーバーヘッドからプライマリ運用データベースを解放し、非正規化を回避します。 Kirby には他の SQL データベースにも既存の運用データがあり、変換せずにそのデータをインポートする必要があります。 データ型を変換せずに既存の運用データをインポートするために、Kirby は Fabric Data Factory を使用してデータ パイプラインを設計し、Fabric SQL データベースにデータをインポートします。

関連コンテンツ