Microsoft Fabric Lakehouse vs Warehouse 完全比較｜エンジン・T-SQL 互換性・性能・選定基準

エンジンと開発スタイルが根本的に異なる。Lakehouse: Apache Spark エンジン、PySpark / Spark SQL / Scala で開発、Notebook ベースのインタラクティブ開発、Delta Lake 形式、Schema-on-Read 柔軟、Big Data / ML / Streaming 向け。Warehouse: Microsoft SQL エンジン、T-SQL ベース、SSMS / Azure Data Studio で開発、Distributed Query Processing、Schema-on-Write 厳密、BI / レポート向け最適化。両者は同じ OneLake 上で動作 (Delta Parquet 形式共有)、Cross-warehouse Query で相互結合可能。データエンジニア (Lakehouse) と BI 開発者 / SQL アナリスト (Warehouse) が同じデータ基盤で協業可能、Microsoft Fabric の設計思想の中核。新規プロジェクトでは両方を組み合わせた『Lakehouse (Bronze/Silver) + Warehouse (Gold)』のハイブリッド構成が標準パターンです。

Cross-warehouse Query は、Lakehouse SQL Endpoint と Warehouse を相互に JOIN・参照する Fabric の機能。同一 Workspace 内であれば 3-part-name (database.schema.table) または fully qualified name で別データソースのテーブル参照可能。代表例: 1) Lakehouse の Bronze データと Warehouse の Reference Data を JOIN、2) Warehouse の Gold データを Lakehouse の Notebook で読み取り、3) Lakehouse Delta Table と Warehouse Table の Hybrid 分析。これにより データエンジニア が Lakehouse でデータ準備 → BI 開発者 が Warehouse + Lakehouse 統合クエリで分析、というシームレスな協業が実現。従来は Synapse の SQL Pool / Spark Pool を別途構築 → ETL でデータ複製、というアーキテクチャだったが、Fabric では Cross-warehouse Query で論理統合のみ・複製不要というアーキテクチャ革新を実現しています。

Warehouse の T-SQL 互換性: 基本的な SELECT / INSERT / UPDATE / DELETE / MERGE・JOIN・Window Function・CTE は完全サポート、Stored Procedure・User-defined Function・Sequence Object・Trigger も対応。Lakehouse SQL Endpoint の T-SQL: Read-only クエリのみサポート (SELECT / JOIN / CTE / Window Function 対応)、INSERT / UPDATE / DELETE は不可 (Spark Notebook 経由でのみ書き込み)、Stored Procedure 不可。判断: T-SQL での DML 操作 (INSERT / UPDATE) 必要 → Warehouse、Read-only Analytics → Lakehouse SQL Endpoint で十分。SQL Server から Warehouse への移行は基本的に Lift and Shift 可能だが、一部 SQL Server 固有機能 (CLR・SSIS Job など) は対応していないため、事前互換性チェックが必要です。

Lakehouse Spark: Spark Job 起動オーバーヘッド (Cold Start 数秒-数十秒)、起動後は高並列処理可能、Large Dataset (TB-PB 級) で性能発揮、Notebook の Persistent Spark Session で対話的処理高速化。Warehouse: 即時クエリ実行 (Cold Start なし)、複雑 JOIN・集計クエリ高速 (Distributed Query)、小-中規模 (GB-TB) で性能良好、Result Set Caching で繰り返しクエリ高速化。判断: 1) インタラクティブ短時間クエリ → Warehouse、2) 大量データバッチ処理 → Lakehouse、3) ML 学習 → Lakehouse Spark、4) Power BI Direct Lake 接続では両方とも同等高速 (Delta Parquet 直接読み込みのため)。本番運用では Workload 特性に応じて両方を使い分け、Fabric の Capacity (CU) は両方に共通で消費されるためコスト管理は統一可能です。

Microsoft が推奨する選定基準: Lakehouse 推奨: 1) Spark / Python での開発経験チームが多い、2) 大量データ (10 TB+) のバッチ処理、3) ML / AI ワークロード、4) 半構造化・非構造化データ (JSON・画像・動画)、5) Streaming データ取り込み、6) Open Source Data Format (Iceberg・Hudi など将来対応) 重視、7) Notebook ベースの探索的データ分析。Warehouse 推奨: 1) 既存 SQL Server / Synapse Dedicated SQL Pool からの移行、2) SQL アナリスト・BI 開発者が主担当、3) 中規模データ (TB レベル) の高頻度分析、4) ACID トランザクション必須の Operational Data、5) Stored Procedure / Function による複雑業務ロジック、6) サードパーティ BI ツール (Tableau・Qlik) との SQL 接続。両方推奨: 1) Bronze/Silver = Lakehouse + Gold = Warehouse のハイブリッド構成、2) データエンジニア (Lakehouse) + BI 開発者 (Warehouse) の協業環境。

両者とも Fabric Capacity (CU) を消費する単一課金体系で、別途追加コストなし。CU 消費パターンの違い: Lakehouse Spark Job: 起動時に CU を高負荷消費、処理完了後 CU 解放、Idle 時間ゼロ消費。Warehouse Query: 常時 Background Process で CU 消費 (Always Warm)、クエリ実行時にスパイク。判断: 1) バッチ処理中心 → Lakehouse のほうが CU 効率良い (処理時間のみ消費)、2) 常時 BI アクセス → Warehouse の常時 CU 消費を見込む、3) 開発・テストは Lakehouse の Pause 可能性活用。Capacity Metrics App で Workload 別 CU 消費を可視化、月次レビューで Right-sizing。Microsoft Fabric の Capacity 共有設計により、Lakehouse / Warehouse を別々に予算化する必要がなく、Workload 全体での最適化が可能です。

標準的なハイブリッドアーキテクチャ: 1) Bronze Lakehouse (Raw データ取り込み・Spark で Schema 検出・Notebook 開発)、2) Silver Lakehouse (クレンジング・JOIN・Spark でデータ品質処理)、3) Gold Warehouse (集計・Star Schema・SQL アナリストが直接クエリ・Stored Procedure で業務ロジック)、4) Power BI Semantic Model に Direct Lake 接続 (Gold Warehouse 経由)、5) Pipeline で Lakehouse → Warehouse のデータ移動 Orchestration、6) Cross-warehouse Query で Lakehouse データを Warehouse から参照可能。アクセス権限: Lakehouse はデータエンジニアのみ書き込み可・SQL アナリストは Read-only、Warehouse は BI 開発者・SQL アナリストが業務ロジック実装可。役割分担が明確になり、組織全体のデータ活用効率が大幅向上します。

DP-700 (Fabric Data Engineer Associate) で両方の使い分けが深く問われる本領域の本命認定。DP-600 (Fabric Analytics Engineer Associate) で Warehouse + Power BI 統合、AZ-305 (Solutions Architect Expert) でアーキテクト視点での Fabric アーキテクチャ判断、AI-103 (2026-06 GA) で Lakehouse + Azure AI Foundry の統合シナリオ。Microsoft Fabric の差別化機能の理解が DP-700 試験合格の鍵で、Cross-warehouse Query・Direct Lake・Medallion 実装パターンを実機で習得することが推奨されます。