このリファレンス ガイドとシナリオ例を使用して、Microsoft Fabric ワークロードのデータ ストアを選択し、OneLake の統合ストレージで使用できます。
| 理想的なユース ケース | Microsoft Fabric ワークロード | 既定で開いているテーブル形式で OneLake で使用できるデータ |
|---|---|---|
| 対話型分析用のストリーミング イベント データ、高い粒度 (時間、空間、詳細 – JSON/テキスト) アクティビティ データ | Eventhouse | はい |
| AI、NoSQL、ベクター検索 | Fabric の Cosmos DB (プレビュー) | はい |
| 操作トランザクション データベース、OLTP データベース | Fabric の SQL データベース (プレビュー) | はい |
| エンタープライズ データ ウェアハウス、SQL ベースの BI、OLAP、 完全な SQL トランザクションのサポート | Data Warehouse | はい |
| ビッグ データと機械学習、非/半構造化データ、 データ エンジニアリング | レイクハウス | はい |
ペルソナとスキルセット
| Microsoft Fabric ワークロード | 主な開発者ペルソナ | 主なスキルセット、ツール | 第 1 言語 |
|---|---|---|---|
| Eventhouse | アプリ開発者、データ サイエンティスト、データ エンジニア | コードなし、KQL、SQL | KQL (Kusto クエリ言語)、T-SQL |
| Fabric の Cosmos DB (プレビュー) | AI 開発者、アプリ開発者 | Azure Cosmos DB に似た NoSQL の概念、REST API | JavaScript/TypeScript、Python、C#、Java などを使用した REST API 統合 |
| Fabric の SQL データベース (プレビュー) | AI 開発者、アプリ開発者、データベース開発者、データベース管理者 | Azure SQL Database、SSMS、VS Code、SQL Server と互換性のあるクエリ ツールに似たデータベースの管理と開発 | T-SQL |
| Fabric Data Warehouse | データ ウェアハウス開発者、データ アーキテクト、データ エンジニア、データベース開発者 | データ ウェアハウスの概念、 スター スキーマ データベースの設計、SSMS、VS Code、および SQL Server と互換性のあるクエリ ツール | T-SQL、コードなし |
| レイクハウス | データ エンジニア、データ サイエンティスト | PySpark、Delta Lake、ノートブック | Spark (Scala、PySpark、Spark SQL、R) |
シナリオ
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
Daisyは、Power BI を使用して大規模なグローバル小売チェーンのサプライ チェーンのボトルネックを分析した経験を持つビジネス アナリストです。 何十億行ものデータを処理できるスケーラブルなデータ ソリューションを構築する必要があり、ビジネス上の意思決定に使用できるダッシュボードとレポートを構築するために使用できます。 データは、さまざまな構造化、半構造化、非構造化形式のプラント、サプライヤー、荷送人、およびその他のソースから取得されます。
Daisyは、スケーラビリティ、迅速な応答時間、時系列分析、地理空間関数、Power BI の高速直接クエリ モードを含む高度な分析機能により、Eventhouse を使用することにしました。 クエリは、Power BI と KQL を使用して実行して、現在と過去の期間を比較したり、新たな問題をすばやく特定したり、陸と海のルートの地理空間分析を提供したりできます。
シナリオ 4
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 データベースにデータをインポートします。