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

この参考ガイドと例シナリオを使って、Microsoft Fabricワークロードのデータストアを選ぶのに役立ちます。 すべてのデータストアはOneLakeの統合ストレージで利用可能です。

• イベント データのストリーミングと高い粒度の対話型分析には、eventhouse を使用します。
• NoSQLデータベースの場合は、FabricのCosmos DBを使いましょう。
• 運用、トランザクション、OLTPワークロード、または正規化されたリレーショナルデータベースの場合は、Fabric内のSQLデータベースを使用します。
• ベクターデータ型でAIを開発するには、FabricのSQLデータベースやFabricのCosmos DBを使いましょう。
• エンタープライズデータウェアハウジング、SQLベースのBI、OLAP、フルSQLトランザクションサポートにはFabric Data Warehouseをご利用ください。
• ビッグデータや機械学習、非構造化、半構造化、構造化データ、データエンジニアリングにはレイクハウスを使いましょう。
• すべてのFabricデータストアはデフォルトでOneLakeでオープンテーブル形式で利用可能ですが、イベントハウス内のKQLデータベースのみ、OneLakeの利用可能性はオプトイン機能として利用可能です。

ペルソナとスキルセット

シナリオ

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

シナリオ 1

プロの開発者であるスーザンは、Microsoft Fabric を初めて使用します。 彼らはデータのクリーニング、モデリング、分析を始める準備ができていますが、データウェアハウスを作るかレイクハウスを作るかを決める必要があります。 前の表の詳細を確認すると、主な意思決定ポイントは利用可能なスキルセットとマルチテーブル取引の必要性です。

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

スーザンは新しいデータ ウェアハウスを作成し、他の SQL サーバー データベースと同様に T-SQL を使用して操作します。 彼女が倉庫を構築するために書いた既存のT-SQLコードの多くはSQL Server Fabric Data Warehouseで動作するため、移行は容易です。 選択した場合は、SQL Server Management Studio などの他のデータベースと同じツールを使用することもできます。 FabricポータルのSQLエディタを使い、スーザンや他のチームメンバーは、3つの部分名を使ってクロスデータベースクエリを実行することで、レイクハウス内の他のデータウェアハウスやデルタテーブルを参照する分析クエリを書きます。

シナリオ 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 データベースにデータをインポートします。

次のステップ