「レイクとDWHって、結局何が違うんですか」
データ基盤の話をしていると、この質問に何度も向き合ってきました。名前が似ていて、しかもどちらも「データを置く場所」に見えるので、混同されるのも無理はありません。ですが、この違いを曖昧にしたまま設計を進めると、後になって「何が正しいデータなのか分からない」という厄介な事態を招きます。
3層の役割分担
あらゆる形式の生データ（構造化・非構造化を問わず）を、加工せずそのまま貯める層。スキーマを事前に決めずに投入できる（スキーマオンリード）ため、将来何に使うか分からないデータでもとりあえず保全しておける
構造化され、整合性が取られたデータを蓄積する層。事前にスキーマを設計してから格納する（スキーマオンライト）。全社共通の「正」となるデータの置き場所で、Snowflake・BigQuery等が代表例
DWHの中から、特定部門・特定用途のためにあらかじめ絞り込み・集計した小さなデータ集合。「営業向けマート」「マーケ向けマート」のように部門別に作ることが多い
流れとしては「生データ（レイク）→整形・統合（DWH）→用途別に切り出し（マート）→BI/ダッシュボードで可視化」という順で処理されるのが典型です。
台所に例えると分かりやすいかもしれません。レイクは届いたばかりの食材をとりあえず放り込む倉庫、DWHは使いやすいように仕分けし直したパントリー、マートはその日の献立に合わせて必要な分だけ取り出した調理台の食材、というイメージです。倉庫から直接料理を作ろうとすると、探すだけで一苦労します。
なぜ分けるのか
- 生データを直接BIツールに繋ぐと、クエリが重くなり、部門ごとに解釈がばらつく
- DWH段階で「正の定義」を一元化しておくことで、部門別マートを作っても数字の意味がズレない
- マートを部門別に分けることで、権限管理（誰がどのデータまで見られるか）もしやすくなる
「収益指標・RevOpsガイド」で扱ったメトリクス辞書は、まさにこのDWH段階での「正の定義」を明文化する作業に相当します。定義が曖昧なままマートを作ると、部門ごとに微妙に違う数字が並び、共通言語として機能しなくなります。
データレイクハウス（Lakehouse）という統合の流れ
近年は、レイクの柔軟性（安価・大容量・スキーマオンリード）とDWHの信頼性（トランザクション整合性・クエリ性能）を1つの基盤で両立させる「データレイクハウス」というアーキテクチャも普及しています。Databricks・Snowflakeなど主要ベンダーがこの方向に統合を進めており、レイク・DWH・マートを別々のシステムで持つ必要が薄れつつあります。ただし小〜中規模の事業では、無理にレイクハウスを導入せず、DWH＋マート程度の構成で十分実務が回ることも多い点には注意が必要です。
ここで先に反論しておきます。「最新のレイクハウスを最初から入れておけば、後で悩まずに済むのでは」と思うかもしれません。技術的にはそのとおりです。ですが、扱うデータ量も利用者数もまだ少ない段階でフル装備のレイクハウスを構築しても、複雑さに見合うリターンは出ません。まず「正の置き場所」を1つ決め、必要になった段階で拡張する方が、多くの現場では手堅く進みます。
小規模チームが「DWHなし」から最初のマートを作るまで
いきなりレイク・DWH・マートの3層をフル整備する必要はありません。小規模チームが現実的に進められる最小限の順序です。
レイクやマートは後回しにし、まずDWH相当の「正の置き場所」（Snowflake・BigQuery等、または簡易な集計用DBでも可）を1つ決める
主要指標（MQL・受注等）の定義を1枚のドキュメントにまとめ、DWHに反映する定義として関係者と合意する
SalesforceなどSFA/CRMのデータを、まず1系統だけDWHに同期する。複数システムの同時統合は最初は狙わない
「営業向け」等、最も要望が強い部門のマートを1つだけ、DWHから絞り込み・集計して作る
マートをBI/ダッシュボードに接続し、実際に参照されているかを見てから次のマート・次のシステム統合に着手する
「メトリクス辞書を先に書く」ステップは、そのままコピーして埋められるフォーマットです。
| 指標名 | 定義（計算式レベル） | データソース | 使用マート |
|---|---|---|---|
| 記入例MQL数 | 記入例当月中にスコア閾値を超えたリード数 | 記入例MA（Marketing Automation） | 記入例営業向けマート |
レイクハウスへの統合や複数マートの並走は、この最小構成で「正の定義」と運用が回ることを確認してから検討しても遅くありません。
よくある質問
- 小規模な会社でもこの3層は必要ですか
- 必ずしも必要ではありません。データ量・利用者数が少ないうちは、DWH（またはそれに準じる集計用DB）だけで十分なケースが多く、レイクやマートを別立てで持つ必要性は事業規模とともに増していきます。まずはDWH相当の「正の置き場所」を1つ決めることが優先です
- SalesforceのデータはこのどこにDWH／レイクに入りますか
- SalesforceはSFA/CRMという業務システムであり、それ自体はDWHでもレイクでもありません。SalesforceのデータをETL/ELTツールでDWHに同期し、他システムのデータと統合した上で分析用途に使う、というのが一般的な位置づけです
- データマートは誰が作るべきですか
- DWH側の設計・運用はデータエンジニアやGTMエンジニアが担い、マートの中身（どの指標をどう集計するか）は利用する部門側の要件を反映すべきものです。部門側の関与がないまま作られたマートは、実際の意思決定に使われないまま放置されがちです
問い
「この数字はどこから来ましたか」と聞かれたとき、自社は何と答えられるでしょうか。もし答えが部署やツールによって毎回違うなら、それはレイク・DWH・マートの技術的な区分よりも先に、「正の置き場所」がまだ決まっていないというサインかもしれません。