Fabricのデータ保存先、どこにする？レイクハウス（Lakehouse）とデータウェアハウス（Data Warehouse）の違いと選び方

はじめに

これまでの記事では、Fabricの「レイクハウス」を中心にデータを取り込み、整形してきました。

しかし、Fabricのメニューを開くと、レイクハウスの隣に「データウェアハウス（Data Warehouse）」というよく似たアイコンがあることにお気づきでしょうか？
「データを溜める場所っぽいけど、何が違うの？どっちを使えばいいの？」という疑問を持つ方に向けて、今回はこの2つのコンポーネントの違いと明確な使い分け基準を解説します。

似ているようで違う？2つのデータストア

結論から言うと、どちらも内部的には「OneLake」という同じ共通ストレージの上に、世界標準の「Delta Lake（Parquet）」形式でデータを保存しています。

そのため、どちらを使ってもPower BIと爆速で連携できる「Direct Lakeモード」の恩恵を受けられます。
違いは、「そのデータに対して、どんな言語やツールでアクセスしたいか」というアプローチの差にあります。

レイクハウス（Lakehouse）の特徴と向いているケース

レイクハウスは、第1回・第2回で私たちが使ったものです。

　・特徴
　　　CSVやParquetなどの「ファイル」と、構造化された「テーブル」の両方を混在して管理できます。

　・アクセス方法
　　　データフローGen2（Power Query）だけでなく、PythonやSpark（Notebook）を使って、
　　　プログラムでゴリゴリとデータ解析や機械学習に繋げることができます。

　・向いているケース
　　　画像やログ、音声などの「非構造化データ」も扱いたい場合や、
　　　社内にPythonなどを扱うデータサイエンティスト・データエンジニアがいる場合。

データウェアハウス（Data Warehouse）の特徴と向いているケース

データウェアハウスは、従来の基幹システムやSQL Serverの正統進化版です。

　・特徴
　　　完全に整理された「テーブル」のみを扱います。
　　　ファイルとして直接中身を見ることはできませんが、その分強固な管理が可能です。

　・アクセス方法
　　　100%「T-SQL」で行います。
　　　ストアドプロシージャやビュー、トランザクション処理など、従来のSQLの高度な機能をフル活用できます。

　・向いているケース
　　　社内にSQL ServerやOracleなどのデータベースエンジニアが多く、
　　　過去のSQL資産（クエリやビューのロジック）をそのまま移植したい場合。

どちらを選ぶべき？判断基準まとめ

迷ったら、以下の基準で選ぶのがおすすめです。

　・エンジニアのスキルで選ぶ
　　　SQLが中心なら「ウェアハウス」、Pythonやローコード（Power Query）が中心なら「レイクハウス」。

　・データの種類で選ぶ
　　　きっちりした売上数値だけなら「ウェアハウス」、センサーログやテキストなども含めて柔軟に分析したいなら「レイクハウス」。

実は、Fabric内ではこれらを両方作って「レイクハウスからウェアハウスへデータを渡す」といった融合も簡単にできます。

おわりに

今回はFabricの2大データストアについて解説しました。自社のメンバーのスキルや扱うデータに合わせて最適な形を選択できるのが、Fabricの懐の深さですね。

さて、データ基盤の構築方法が見えてきたところで、最終回となる次回は、今最も熱い「生成AI（Copilot）」との連携についてご紹介します。

データ分析をAIが加速させる！Microsoft Fabric × Copilotでできることと今後の期待
https://www.qes.co.jp/media/microsoft/fabric/a989