---
title: "データレイク・DWH・データマートの違い｜三層の役割比較と規模別の構成判断"
url: "https://www.issoh.co.jp/column/details/18975/"
published: 2026-10-27
updated: 2026-10-27
categories: ["Webシステム"]
publisher: "株式会社一創"
---

# データレイク・DWH・データマートの違い｜三層の役割比較と規模別の構成判断

データレイク・データウェアハウス（DWH）・データマートの違いは、「どんな形のデータを、どこまで整えて、誰に渡すか」の3点に集約できます。レイクは生データの貯水池、DWHは全社データを統合した倉庫、データマートは部門の問いに合わせて切り出した棚です。この記事では、三層の違いを10の比較軸の早見表で並べたうえで、業務システムから三層へデータが流れる順番と各層の加工、BigQueryで三層を作るSQL例を示します。後半では、競合の解説が触れていない「三層を全部そろえる必要はあるのか」を、企業規模とデータの種類から判断する基準として言い切ります。

## まとめ：三層は役割が違う置き場で、全部そろえるかは規模と用途で決まる

データレイクは形式を問わず生データを原形のまま貯める層、DWHは複数システムのデータを統合・整形して全社の正となる数字を持つ層、データマートはDWHから特定部門の分析に必要な分だけを集約した層です。三者は競合する製品カテゴリではなく、データが流れる順に並ぶ役割の違いです。

ただし、三層をすべて別々に構築する必要はありません。基幹システムやSaaSの構造化データが中心で、分析データが数百GB程度に収まる会社なら、クラウドDWH1つとビューで作るマートで十分です。レイクを足すのは、ログ・画像・センサーデータのように表に収まらないデータを貯めて、機械学習や後からの再分析に回す必要が出たときです。先に三層を作り込むより、DWHから始めて足りない層を後から足す順番を勧めます。

## データレイク・DWH・データマートの違いを10の比較軸で並べた早見表

三層の違いは、データそのものの性格と、使う人・費用の構造の2つに分けて見ると整理しやすくなります。

### データの形・スキーマを決める時点・品質で比べた三層の性格の違い

AWSの[データウェアハウス・データレイク・データマートの比較解説](https://aws.amazon.com/jp/compare/the-difference-between-a-data-warehouse-data-lake-and-data-mart/)をもとに、実務で判断に使う10軸へ整理しました。

| 比較軸     | データレイク       | DWH       | データマート     |
| ------- | ------------ | --------- | ---------- |
| 主な目的    | 生データの保管      | 全社データの統合  | 部門の定型分析    |
| データの形   | 表・JSON・画像・ログ | 表形式が中心    | 集約済みの表     |
| スキーマの決定 | 読む時（オンリード）   | 書く前に設計    | DWH側の定義を継承 |
| データ品質   | 未検証を含む       | 検証・名寄せ済み  | 用途別に集計済み   |
| 保持期間    | 全履歴          | 分析に要る履歴   | 直近や必要期間    |
| 主な利用者   | データ技術者       | 分析担当      | 部門の担当者     |
| 規模の目安   | 最大           | 数百GB〜PB   | 通常は数十GBまで  |
| 主な用途    | 機械学習・探索      | 全社レポート    | 部門ダッシュボード  |
| 費用の重心   | 安い保管と読込処理    | 計算と保管     | 更新処理の保守    |
| 代表的な基盤  | S3・GCS・ADLS  | BigQuery等 | DWH内のビュー   |

表の中でいちばん効く違いは「スキーマを決める時点」です。レイクは書き込み時に型を決めないため何でも入りますが、読む人が毎回解釈を補う必要があります。DWHは先に型と定義を決めるので、誰が集計しても同じ数字になる仕組みです。AWSの比較でも、DWHのサイズは数百ギガバイトからペタバイト、データマートは通常最大数十ギガバイトとされています。DWHそのものの仕組みと製品の選び方は[データウェアハウス（DWH）の仕組みと製品比較の記事](https://www.issoh.co.jp/column/details/7338/)で詳しく扱っています。

### 利用者・規模・費用構造で比べたときに三層の役割が分かれる理由

三層は、下流へ行くほどデータ量が減り、加工度と利用者数が増えます。レイクを直接触るのはSQLやPythonを書けるデータ技術者が数名、DWHは分析担当が数名から数十名、マートは営業や経理の担当者がBIの画面から毎日開く、という人数の広がり方が典型です。

費用のかかり方も層ごとに違います。レイクはオブジェクトストレージに置くため保管単価が安く、費用は読み出して処理するときに発生します。DWHで課金の対象になるのは、計算資源とデータ保管の両方です。BigQueryの[公式料金ページ](https://cloud.google.com/bigquery/pricing?hl=ja)では、オンデマンドのクエリは処理したデータ量に応じてTiB単位で課金され、毎月1TiBまでの処理と10GiBまでのストレージが無料です（2026年10月時点）。マートは保管量が小さい代わりに、元データの変更に合わせて更新処理を直し続ける人手が主な費用になります。

## 業務システムから三層を流れるデータの順番と各層で行う加工の中身

比較表の違いは、データの流れに沿って見るとつながります。ここでは受け渡しの順番、設計パターンとの対応、実際のSQLの3段で説明します。

### 生データを貯めるレイク、統合するDWH、切り出すマートの受け渡し

基本の流れは「業務システム・SaaS・ログ」から「データレイク」、そこから「DWH」、最後に「データマート」から「BI」へ、という一方向です。レイクには販売管理のCSV出力やWebのアクセスログを、加工せずに日付ごとのフォルダへ置きます。DWHへ移す段階で、顧客コードの名寄せ、日付型への変換、重複行の除去を行います。

マートは、DWHの統合テーブルから「営業部の月次受注」「経理の請求残高」のように問い単位で集約して作ります。マート側で独自に元データを取り込み直さないことが、部門間で数字をずらさない条件です。マートをどの粒度で切るかの設計手順は[データマートの種類と設計単位を解説した記事](https://www.issoh.co.jp/column/details/18128/)にまとめています。

### ブロンズ・シルバー・ゴールドのメダリオン構成と三層の対応関係

レイクハウス製品の解説では、三層の代わりにブロンズ・シルバー・ゴールドという名前がよく出ます。Microsoft Learnの[メダリオン レイクハウス アーキテクチャの解説](https://learn.microsoft.com/ja-jp/azure/databricks/lakehouse/medallion)では、ブロンズは生データの取り込み、シルバーはクリーニングと検証、ゴールドはディメンションモデリングと集計を行う層と定義されています。

対応関係は、ブロンズがデータレイク、シルバーがDWHの統合テーブル、ゴールドがデータマートとほぼ重なります。同じ解説には、人事・財務・ITのように業務ごとに複数のゴールド層を作る例もあり、これは部門別マートと同じ発想です。呼び名が違うだけで、生データ・検証済み・用途別という3段階の考え方は共通しています。

### BigQueryで外部テーブル・統合テーブル・マート用ビューを作るSQL例

三層は、1つのクラウドDWHの中でも作れます。次の例は、Cloud Storage上のParquetファイルをレイクとして参照し、検証済みの統合テーブルを作り、部門向けのマートをビューで切り出すBigQueryのSQLです。外部テーブルの構文は[Cloud Storage 外部テーブルの作成手順](https://docs.cloud.google.com/bigquery/docs/external-data-cloud-storage?hl=ja)に沿っています。

```
-- 1. レイク層：Cloud Storage の生ファイルをそのまま参照する
CREATE EXTERNAL TABLE raw.orders_ext
OPTIONS (
  format = 'PARQUET',
  uris = ['gs://example-lake/orders/*.parquet']
);

-- 2. DWH層：型をそろえ、欠損と重複を除いた統合テーブルを作る
CREATE OR REPLACE TABLE dwh.fact_orders
PARTITION BY order_date AS
SELECT DISTINCT
  CAST(order_id AS STRING) AS order_id,
  DATE(ordered_at) AS order_date,
  customer_id,
  amount
FROM raw.orders_ext
WHERE order_id IS NOT NULL;

-- 3. マート層：営業部が見る日別売上だけをビューで切り出す
CREATE OR REPLACE VIEW mart_sales.daily_sales AS
SELECT order_date, SUM(amount) AS sales
FROM dwh.fact_orders
GROUP BY order_date;
```

バケット名やデータセット名は自社の環境に置き換えてください。マートをビューにしておけば、DWH側の定義を直したときにマートへ自動で反映され、更新処理を別に持たずに済みます。統合テーブルを日付で分割しているのは、BigQueryが処理したデータ量で課金するため、期間を絞った集計で読む量を減らす狙いです。

## 三層を全部そろえる必要はあるかを企業規模とデータの種類で決める基準

ここからは立場をはっきりさせます。三層を教科書どおりに全部作る会社は多くありません。判断の軸は「データの種類」と「使う人の数」の2つで、規模の大きさそのものではありません。

### 基幹データ中心で分析データが数百GBの会社はDWHとビューのマートで足りる

分析したいデータが販売管理・会計・CRMなどの表形式で、合計が数百GB程度に収まるなら、データレイクは不要です。クラウドDWHに直接取り込み、部門ごとのマートはビューで作れば、三層の役割は1つの基盤の中で果たせます。BigQueryの無料枠（処理は毎月1TiB、保管は10GiB）の範囲で試作できるため、検証の初期費用もほとんどかかりません。

この段階でマートを物理テーブルとして別に作るのは過剰です。ビューで表示が遅いと分かった集計だけをテーブル化すれば足ります。

### ログ・画像・センサーデータを扱う段階でデータレイクを足すべき条件

レイクを足すべきなのは、次のいずれかに当てはまったときです。

- Webのアクセスログや設備のセンサーデータのように、1日に数GB以上増えるデータを全件残したい
- 画像・PDF・音声など、表に収まらないデータを機械学習や生成AIの入力に使う予定がある
- 集計方法がまだ決まっておらず、後から別の切り口で再計算できるよう生データを保管しておきたい

どれにも当てはまらないなら、レイクは後回しで構いません。レイクを先に作り、置き場所だけあって誰も読まない状態は「データスワンプ」と呼ばれる典型的な失敗です。生データの置き方とクエリの実装は[データレイクの仕組みを実装視点で解説した記事](https://www.issoh.co.jp/tech/details/13388/)を参照してください。

### レイクとDWHを一つにまとめるレイクハウスを選ぶ場面と見送る場面

レイクとDWHを両方持つと、同じデータを2か所に置き、2つの基盤を保守することになります。この重複を避ける構成がレイクハウスです。[Apache Iceberg](https://iceberg.apache.org/)のようなオープンなテーブル形式を使い、オブジェクトストレージ上のファイルにDWHと同じようなテーブル操作をかけます。

選ぶべきなのは、機械学習の担当者とBIの担当者が同じデータを別々の道具で読みたい場合です。反対に、利用者がBI中心で、データ技術者が1〜2名しかいない組織では見送ります。テーブル形式やカタログの運用は通常のクラウドDWHより手間がかかり、少人数では保守が回りません。構成要素の詳細は[データレイクハウスのアーキテクチャを解説した記事](https://www.issoh.co.jp/tech/details/13628/)で扱っています。

### 三層を先に全部作って使われない基盤になる失敗パターンと防ぎ方

よくある失敗は、「レイク・DWH・マートをそろえるのが正しい構成」と考えて、最初の半年を基盤づくりに使うケースです。基盤が完成した時点で、どの部門が何の数字を見るかが決まっておらず、マートが空のまま残ります。

防ぎ方は、最初に1つの部門の1つの問いを決めることです。例えば「営業部が毎週見る商品別の受注額」と決め、その数字を出すのに要るテーブルだけをDWHに入れます。その問いが回り始めてから、次の部門のマートと、必要になった時点でレイクを足します。

### 三層の構成を社内で決める手順と分析基盤の設計を外部に任せる目安

社内で決めるなら、次の順で進めると判断がぶれません。

1. 最初に答えたい問いと、見る部門・人数を決める
2. その問いに要るデータの種類（表形式か、ログや画像を含むか）を洗い出す
3. 表形式だけならDWH＋ビューのマート、それ以外も含むならレイクを加える
4. 利用部門が増えた時点で、マートの粒度と共通の定義をそろえ直す

複数の基幹システムを統合する場合や、ログ・画像を含めてレイクから設計する場合は、最初の設計がその後の保守費用をほぼ決めます。初期の構成判断とDWHの設計だけを外部と組み、マートの追加は社内で続ける分担が現実的です。三層の構成判断から構築・運用設計までをまとめて相談するなら、[データ分析基盤構築・MLOps構築支援](https://www.issoh.co.jp/service/ai/data-platform/)のように、レイクからマートまでを一続きで見られる体制を選ぶと、使われない層を作らずに済みます。

## データレイク・DWH・データマートの違いに関するよくある質問と回答

三層の違いと構成判断について、検索でよく調べられている疑問に答えます。

### データレイクとDWHはどちらを先に導入すべきですか？

分析したいデータが表形式の業務データ中心なら、DWHを先に導入してください。部門の数字をそろえる効果がすぐに出るためです。データレイクを先にするのは、ログや画像などを全件残す必要がすでにあり、集計方法がまだ決まっていない場合に限ります。迷うときはDWHから始め、表に収まらないデータが出てきた時点でレイクを足す順番が、作り直しの少ない進め方です。

### データマートはDWHなしで作れますか？

作れます。業務システムから直接データを取り込む「独立型」のデータマートが、その構成に当たる例です。立ち上げは速い反面、部門ごとに取り込み処理と集計の定義を別々に持つため、売上の数字が部署によってずれる原因になります。マートが2つ以上になる見込みなら、先にDWHで定義をそろえ、そこから切り出す「従属型」で作るほうが、後から数字を合わせる手間を減らせます。

### データレイクとデータレイクハウスの違いは何ですか？

データレイクは生データを原形のまま貯める置き場で、更新や削除をテーブル単位で安全に行う仕組みは持ちません。データレイクハウスは、レイクと同じオブジェクトストレージの上に、Apache Icebergなどのテーブル形式を重ねて、DWHのような更新・削除・履歴管理をできるようにした構成です。レイクとDWHの二重管理を減らせる一方、運用には専門の担当者が必要です。

### Excelやスプレッドシートの集計表はデータマートに当たりますか？

部門の分析用に切り出したデータという意味では近い役割ですが、データマートとは呼びにくい形です。手作業の転記やコピーで作られる集計表は、元データとの対応が追えず、更新のたびに担当者の手が入ります。データマートは、DWHなどの元データから決まった処理で自動的に作られ、誰が開いても同じ数字になることが条件です。Excelは、マートの数字を表示する出口として使うのが安全です。

### ETLやELTは三層のどこで使いますか？

層と層の間でデータを移す処理に使います。業務システムからレイクやDWHへ取り込む段階と、DWHからマートを作る段階の2か所が中心です。クラウドDWHでは、先に生データを取り込み、DWHの中でSQLで変換するELTが主流になっています。抽出・変換・格納の仕組みとツールの選び方は[ETLの仕組みとELTとの違いを解説した記事](https://www.issoh.co.jp/column/details/13364/)で詳しく説明しています。ETL・BI・CDPを含めた4要素の役割分担は[ETL・BI・DWH・CDPの違い｜4つの役割分担とどこから作るかの導入順序](https://www.issoh.co.jp/column/details/18981/)で比べています。

## 関連記事

- [データ分析基盤とは？構成要素・費用・内製と外注の判断基準](https://www.issoh.co.jp/column/details/16250/)：三層にBIや取り込み処理を加えた基盤全体の構成と費用感を整理しています。
- [dbtとは？ELTのTを担う仕組みとdbt Core・Cloudの選び方](https://www.issoh.co.jp/column/details/16548/)：DWHの中でマートを作る変換処理を、SQLで管理する道具を解説しています。
- [データレイクハウス実装の手順6ステップ](https://www.issoh.co.jp/tech/details/15381/)：レイクとDWHを一つにまとめる構成へ移行する手順を実装視点で解説しています。
- [オブジェクトストレージとは？仕組み・S3互換APIの範囲とブロックとの違い](https://www.issoh.co.jp/tech/details/13369/)：データレイクの土台になる保管基盤の仕組みを解説しています。

---

出典: [データレイク・DWH・データマートの違い｜三層の役割比較と規模別の構成判断](<https://www.issoh.co.jp/column/details/18975/>)（株式会社一創）