Microsoft Fabric のアーキテクチャを読み解く：Lakehouse と Data Warehouse の違い

By Mirko Peters · 2026-08-27

ブログへようこそ。最近のポッドキャスト エピソードをお聴きいただいている方はご存じのとおり、データ プラットフォーム、最新の分析、エンタープライズ アーキテクチャの進化について掘り下げています。分析基盤の設計は画一的にはいかず、Microsoft Fabric の登場によって、データ エンジニアリング、データ ウェアハウス、ビジネス インテリジェンス、AI を単一の運用基盤の下にまとめた統合環境が手に入るようになりました。ただし、統合プラットフォームがあるからといって、アーキテクチャ上の選択が不要になるわけではありません。データ アーキテクトやエンジニアリング チームが Microsoft Fabric の導入を始めて最初に直面する判断のひとつが、Lakehouse と Data Warehouse のどちらを選ぶかです…

Automatically translated with AI from the original post. Read the English original

ブログへようこそ。最近のポッドキャスト エピソードをお聴きいただいている方はご存じのとおり、データ プラットフォーム、最新の分析、エンタープライズ アーキテクチャの進化について掘り下げています。分析基盤の設計は画一的にはいかず、Microsoft Fabric の登場によって、データ エンジニアリング、データ ウェアハウス、ビジネス インテリジェンス、AI を単一の運用基盤の下にまとめた統合環境が手に入るようになりました。ただし、統合プラットフォームがあるからといって、アーキテクチャ上の選択が不要になるわけではありません。Microsoft Fabric の導入を始めたデータ アーキテクトやエンジニアリング チームが最初に直面する判断のひとつが、Lakehouse と Data Warehouse のどちらを選ぶかです。

このアーキテクチャの判断は、組織がデータを保存、処理、提供する方法の土台になります。Lakehouse の柔軟性とオープンソースの性質を活かすか、それとも従来のリレーショナル データベースが持つ構造化された強みを維持するか。この選択を本当に使いこなすには、Microsoft Fabric のストレージの階層を掘り下げ、チームのスキル セットがこの判断にどう影響するかを分析し、Delta Lake などの最新のデータ形式が両者のアプローチをどう橋渡しするかを見ていく必要があります。それでは、Microsoft Fabric のアーキテクチャを読み解き、組織にとって適切な道を選ぶ方法を見ていきましょう。

Microsoft Fabric のストレージ オプションの概要

Microsoft Fabric 以前は、包括的なデータ プラットフォームを構築するには、Azure 全体にわたる複数のサービスを組み合わせるのが一般的でした。Azure Data Lake Storage を設定し、専用 SQL プールをプロビジョニングし、Azure Databricks クラスターを管理し、Power BI ワークスペースを接続する、といった具合です。強力ではあるものの、このアプローチではデータのサイロ化や情報の重複コピーが生じやすく、さまざまなサービスをまたいでセキュリティとコンピューティング リソースを管理する際の管理負荷も大きくなりがちでした。

Microsoft Fabric は、OneLake を導入することでこの断片化を解消します。OneLake は、組織のデータにとっての OneDrive のような役割を果たす、統合された SaaS ベースのマルチテナント データ レイクです。Fabric 内のすべて、つまり Lakehouse、Data Warehouse、KQL データベース、Power BI セマンティック モデルのいずれであっても、OneLake の上に配置されます。この統合ストレージ層の中で、組織は分析データの構造化と利用方法を選択できます。Fabric において分析データの保存とクエリを担う主要なエンジンは、Lakehouse と Data Warehouse の 2 つです。両者は共通の基盤技術を共有していますが、異なるワークロード、ユーザー ペルソナ、運用パラダイムを想定して設計されています。

Microsoft Fabric Lakehouse の理解

Microsoft Fabric Lakehouse は、データ レイクとデータ ウェアハウスの長所を 1 つの環境にまとめるために設計された、データ アーキテクチャのパターンです。ファイルベースのデータ エンジニアリング ワークロードと構造化された分析クエリの両方に最適化されており、データ エンジニアやデータ サイエンティストに好まれています。

Fabric の Lakehouse は、その中核において、従来のデータ レイクと同じようにファイルとフォルダーを管理しますが、オープンソースの Delta Parquet 形式を使用した重要なトランザクション層を追加します。これにより、画像、PDF、音声ファイル、生の JSON ログなどの非構造化データを、構造化データや半構造化の表形式データと並べて保存できます。さらに、Lakehouse は Apache Spark とネイティブに統合されています。チームが PySpark ノートブック、分散データ変換、大規模な高負荷のデータ エンジニアリングに依存している場合、Lakehouse は理想的な環境を提供します。データ プロフェッショナルは、コードファーストの手法を使って複雑な変換を実行し、機械学習モデルをトレーニングし、堅牢なデータ パイプラインを構築できます。

Microsoft Fabric データウェアハウスの概要

スペクトラムの反対側にあるのが Microsoft Fabric Data Warehouse です。組織が長年、従来のエンタープライズ データ ウェアハウス、SQL Server、専用の分析データベースに依存してきた場合、Fabric Data Warehouse はすぐに馴染みがあり、使いやすく感じられるでしょう。

Lakehouseがさまざまなストレージ形式を組み合わせ、非構造化ファイルも受け入れるのとは異なり、Fabric Data Warehouseはリレーショナルデータと構造化テーブルに厳密に特化しています。高性能なT-SQLクエリ機能を提供するように設計されています。Fabricで Warehouse をプロビジョニングすると、リレーショナル操作、複雑な結合、ビジネス インテリジェンス レポートに最適化された、ストレージとコンピュートが分離されたモデルを利用できます。データベース管理者、SQL開発者、データアナリストは、Sparkを習得したりクラスター構成を管理したりしなくても、標準のT-SQLスクリプトを記述し、データベース スキーマを管理し、ビューを作成し、ストアド プロシージャを適用できます。従来のエンタープライズデータチームが、エンタープライズ グレードのデータ ウェアハウスに期待する予測可能なガバナンス、セキュリティ、トランザクションの一貫性も備えています。

Lakehouse と Warehouse のアーキテクチャの主な違い

Microsoft Fabric の Lakehouse と Data Warehouse を並べて比較すると、違いは Spark を使うか T-SQL を使うかだけにとどまりません。これらのアーキテクチャ上の違いを理解しておくと、過剰な設計を避けたり、チームの運用習慣に合わないストレージ モデルを選んでしまうことを防げます。

まず、各オプションが優先するデータの種類を見てみましょう。Lakehouse は、未加工の非構造化ドキュメントから構造化された Delta テーブルまで、あらゆるデータを扱います。Data Warehouse は、構造化データと半構造化のリレーショナル データに厳密に最適化されています。次に、コンピュート エンジンを見てみましょう。Lakehouse はデータ処理に Apache Spark を多く利用するのに対し、Data Warehouse は超並列処理 (MPP) の SQL エンジンを利用します。3 つ目は、データの管理方法です。Lakehouse は基盤となるファイルへのオープンなアクセスを提供するため、データ サイエンティストは外部ツールや Python ライブラリを使って Parquet ファイルを直接読み取れます。Warehouse は基盤ストレージをより強く抽象化し、分析レポートと同時実行クエリのパフォーマンスに最適化された、すっきりとしたリレーショナル SQL データベースのインターフェイスを提供します。

チームのスキルセットとストレージの選択を合わせる

アーキテクチャの決定は、真空状態で行うべきではありません。チームが既に持っているスキルセットという現実的な事情を考慮する必要があります。テクノロジーは、それを使う人次第で効果が決まります。

組織に Power BI 開発者、従来型のデータベース管理者、そして T-SQL に日々精通した SQL アナリストが多く在籍している場合、Spark 中心の Lakehouse アーキテクチャを強いると、不必要な学習コストが生じ、開発のスピードが落ちかねません。このシナリオでは、Fabric Data Warehouse が取り組みやすい導入ルートとなり、既存の SQL 人材が現在の専門知識をすぐに活かせます。逆に、Python、Scala、分散コンピューティング フレームワークに精通したデータ エンジニアやデータ サイエンティストが在籍している場合は、Lakehouse が、高度な変換パイプラインや AI ソリューションを構築するために必要なプログラミングの柔軟性と計算能力を提供します。Fabric のストレージ オプションを正しく選ぶには、チームの能力を率直に見極め、そのチームを活かし、疎外しないアーキテクチャを設計することが必要です。

異なるデータの種類とワークロードへの対応

Microsoft Fabric で Lakehouse と Data Warehouse のどちらを選ぶかを最終的に決めるのは、多くの場合ワークロードの要件とデータの多様性です。すべてのデータがリレーショナル テーブルにきれいに整理された形で届くわけではなく、すべての分析が同じ形をしているわけでもありません。

取り込みパイプラインが大量の未加工のテレメトリ、IoT センサー ストリーム、非構造化テキスト ファイル、システム ログを取り込む場合、Lakehouse は自然な着地点になります。メダリオン アーキテクチャのブロンズ層に未加工データを素早く格納し、Spark ノートブックで処理して、整った分析用テーブルへと精製できる柔軟性があります。一方、主なワークロードが、きれいに構造化されたディメンショナル データ モデルを使う高同時実行のビジネス インテリジェンス ダッシュボードである場合は、Data Warehouse の出番です。その T-SQL エンジンは、複雑な分析クエリを低遅延で実行するように細かく調整されており、ビジネス ユーザーが Power BI セマンティック モデルから、速く信頼できる回答を得られるようにします。

Delta 形式を活用した統合ストレージ

Microsoft が Fabric の構築で行った最も優れたアーキテクチャ上の選択の 1 つは、すべての構造化テーブルの基盤として、オープンソースの Delta Parquet 形式を採用したことです。この選択により、Lakehouse と Warehouse の境界線が、さまざまな面で効果的にあいまいになっています。

PySparkを使ってFabric Lakehouse内でデータを取り込み処理する場合でも、T-SQLを使ってFabric Data Warehouseにデータを読み込む場合でも、OneLakeに保存される物理ファイルはDelta テーブルの形式になっています。このオープンなストレージ標準により、どちらの環境でもACID トランザクション、タイムトラベル、高いパフォーマンスが利用できます。LakehouseとWarehouseはどちらもDelta テーブルの読み取りと書き込みができるため、組織がプロプライエタリなストレージへのロックインを心配する必要はなくなります。つまり、データエンジニアはLakehouseでSparkを使ってデータを準備し、SQL開発者は同じテーブルをWarehouseでT-SQLを使って照会できます。データの重複した物理コピーを作成する必要はありません。

組織で適切なアプローチを選択するためのベストプラクティス

Microsoft Fabricの導入を計画する際、LakehouseとWarehouseのどちらを実装すべきか、あるいは両方を組み合わせるべきかをどのように判断すればよいでしょうか。成功している組織は通常、Fabric環境を設計する際に、いくつかの中核的なベストプラクティスに従っています。

まず、必要に応じてハイブリッドアプローチを採用してください。Microsoft Fabricは、同じテナントおよびワークスペース構造の中でLakehouseとWarehouseを並べて使えるように設計されています。たとえば、生データの取り込み、負荷の高いデータエンジニアリング変換、データサイエンスのワークロードにはLakehouseを使い、後段のレポート用データマートやエンタープライズの統合ディメンションはデータウェアハウスに配置する、といった使い方が考えられます。次に、OneLakeショートカットを活用して、ドメイン間での不要なデータの移動や重複を避けてください。3つ目として、常にコンシューマーを念頭に置いて設計してください。収集するデータの種類、データを変換する担当者のスキル、最終的なインサイトを利用するビジネスユーザーのパフォーマンス要件を評価することが重要です。

生データの取り込みから経営判断に至るまで、これらのアーキテクチャの要素がどのように組み合わさるかについて、実践的で現実に即した解説を聞きたい方は、関連するポッドキャストエピソードMicrosoft Fabric End-to-End: From Raw Data to Business Decisions with Amit Chandak [MVP]をぜひお聴きください。このエピソードでは、Amit が、組織がOneLakeをどのように活用し、LakehouseとWarehouseのどちらを選ぶかの判断をどう進めるか、変換処理をどう最適化するか、そして人間の意思決定者とAI駆動の体験の両方を支えるスケーラブルな分析ソリューションをどう構築するかを解説しています。