Microsoft Fabric のレイクハウスは「何でも入れる場所」ではないという話

はじめに

Microsoft Fabric を触り始めると、ほぼ必ず登場するのがレイクハウスです。

• データを置く場所として案内される
• SQL でクエリできる
• Delta 形式が使われる

以上のような説明を受け一見すると、
「とりあえず全部 Lakehouse に入れておけばいいのでは？」
と思ってしまいがちです。

しかし、Fabric の Lakehouse は単なる“データの置き場”ではありません。この記事では、

• Fabric における Lakehouse の位置づけ
• 何を入れるべきで、何を入れるべきでないか
• Warehouse や KQL DB との違い

を整理し、Lakehouse を正しく使うための考え方を解説します。

Fabric の Lakehouse は 「SQLが使えるデータレイク」

まず前提として、Fabric の Lakehouse は次の特徴を持ちます。

• OneLake 上のデータレイク
• Delta 形式（ACID / スキーマ管理）
• SQL エンドポイントを持つ
• Spark / SQL / Power BI から利用可能

「データレイクでありながら、DWH 的にも扱える」というのが Lakehouse という名前の由来です。
ただし、ここで重要なのは何でもDWHの代わりになるわけではないという点です。

Lakehouse が担うべき役割

Fabric 全体で見ると、Lakehouse は 中間層（加工・蓄積層） としての役割が最も自然です。
役割として整理すると、次のようになります。

Lakehouse の主な責務

• 生データ〜加工途中データの蓄積
• Spark / Dataflow などによる変換処理の受け皿
• 分析用データを作るための土台
• 将来の再加工に耐えられる形での保存

特徴としては、

• スキーマはあるが、完全に固定しない
• 書き込み・再処理が前提
• 履歴や再計算を許容する

という性質を持ちます。

「全部 Lakehouse」はなぜ危険か

Fabric 初期でよくある設計が、「まずは全部 Lakehouse に入れよう」という判断です。
短期的には楽ですが、中長期では次の問題が起きやすくなります。

• 業務向けデータと分析途中データが混在する
• SQL で見せてはいけないデータが見えてしまう
• Power BI から直接参照され、構造が壊れる
• 最終成果物の責任範囲が曖昧になる

Lakehouse は 自由度が高いがゆえに、境界を決めないと破綻しやすい のです。

Lakehouse と Warehouse の違い（Fabric視点）

Fabric では、Lakehouse と Warehouse が並立しています。両者の違いを「役割」で見ると、次のようになります。

Lakehouse

• 加工途中・分析途中のデータ
• 再処理・再計算を前提
• エンジニア主導で作る
• 柔軟性重視

Warehouse

• 業務・分析の最終形データ
• 安定したスキーマ
• 利用者向けの責任範囲が明確
• SQL / BI 重視

つまり、Lakehouse は作業場、Warehouse は成果物置き場 のように考えるとわかりやすいかもしれません。

Fabric において、Lakehouse は 最終的な提供レイヤーである必要はありません。
典型的な流れは、

1. 外部データを Lakehouse に取り込む
2. 加工・クレンジング・結合を行う
3. 利用目的に応じて
   • Warehouse に載せる
   • セマンティックモデルにする
   • KQL 側に流す

という形です。Lakehouse は 柔軟な中継地点 として使うのが最も健全です。

Lakehouse 設計で意識すべき3つの観点

1. 誰が触るデータか

• エンジニアだけが触るのか
• BI 利用者が直接見るのか

→ 直接見せるなら Warehouse / Semantic 側に出す。

2. 再処理される前提か

• 再計算・再ロードがあるか
• ロジックが変わる可能性があるか

→ Yes なら Lakehouse 向き。

3. 「成果物」として責任を持てるか

• 数字がブレないか
• 問い合わせに耐えられるか

→ 成果物なら Warehouse に昇格させる。

まとめ

Microsoft Fabric の Lakehouse は、何でも入れる万能ストレージではありません。

「変化を許容するデータを、安全に溜めておく場所」
というのが Fabric における Lakehouse の本質です。

• 自由度が高いからこそ、境界を決める
• SQL が使えるからこそ、使いすぎない
• 最終形は別レイヤーに切り出す

この前提を押さえると、なぜ Fabric は分かれているのかが、自然につながって見えてきます。

参照：