業務のデータベースで重い集計を回さないと決めたら、次に迷うのは、分析用のデータをどこに集めるかです。
候補としてよく並べられるのが、データウェアハウス、データレイク、レイクハウスの 3 つです。
3 つの違いは「データの形をいつ決めるか」と「整った状態を何が守るか」に分けると見えてきて、S3・Athena・Redshift・Lake Formation といった AWS のサービスの役割分担にも説明がつきます。
私はどれも運用したことがなく、各社の公式ドキュメントや論文を読みながら学んでいるところです。
分析を業務のデータベースから切り離す理由は、OLTP と OLAP の違いとして別の記事にまとめました。
データウェアハウス・データレイク・レイクハウスとは
3 つとも分析のためにデータを集める場所ですが、データを入れる前に整えるか、置いてから整えるかで性格が分かれます。
データウェアハウスは入れる前に形を決める
データウェアハウスは、業務のシステムや複数のデータベースから集めた表形式のデータを、決めておいた形にそろえてから入れる置き場所です。
AWS のデータウェアハウスとデータレイクの比較ページは、ウェアハウスのデータを、よく整えられていて「中心となる正しい版」として使われるものと説明しています。
表の形は入れる前に設計しておくことが多く、これをスキーマ・オン・ライトと呼びます。
利用者はそろった表だけを見ればよいので、決まったレポートや BI のダッシュボードと相性のよい作りです。
データレイクは生のまま置き、読むときに形を決める
AWS のデータレイクの解説は、データレイクを、構造化されたデータもされていないデータも、規模を問わずすべて保存できる中央の置き場所と定義しています。
業務の表だけでなく、ログや画像、文書のように形のそろわないデータも、元の形式のまま置けます。
形は分析するときに当てはめるので、こちらはスキーマ・オン・リードと呼ばれます。
置き場所には、S3 のような安いオブジェクトストレージを使うのが一般的です。
レイクハウスはレイクのファイルに表の管理を足す
レイクハウスの考え方は、2021 年に CIDR というデータベースの学会で発表された論文「Lakehouse: A New Generation of Open Platforms that Unify Data Warehousing and Advanced Analytics」で整理されています。
論文の定義では、レイクハウスは、安くて直接読める保存先を土台にしたデータ管理の仕組みです。
その上に、ACID トランザクション、データの版の管理、監査、インデックス、キャッシュ、クエリの最適化といった、分析用データベースの機能を備えます。
中心になるのは、オブジェクトストレージに置いた Parquet などのファイルについて、どのファイルがどの版の表に含まれるかを記録するメタデータの層です。
論文はこの層の例として Delta Lake と Apache Iceberg を挙げ、Apache Hudi も同じ分野の仕組みとして紹介しています。
なお、論文の著者 4 人はいずれも Databricks に所属していて、Delta Lake も Databricks が 2016 年に開発を始めたものです。
提唱する側が書いた文章である点は、頭に置いて読んでおくとよいでしょう。
3 つを並べると、次のようになります。
| 観点 | データウェアハウス | データレイク | レイクハウス |
|---|---|---|---|
| 置くデータ | 業務のシステムから集めた表形式のデータ | 表・ログ・画像・文書など何でも | 何でも置けて、表として扱う部分を持つ |
| 形を決めるとき | 入れる前（スキーマ・オン・ライト） | 読むとき（スキーマ・オン・リード） | 表として登録した部分は、書き込むときに形を確かめられる |
| データの整い方 | 整えたデータだけ | 生のデータも含む | 生のデータから整えたデータまで段階的に |
| 保存の形式 | 製品ごとの独自形式が多い | Parquet・CSV など汎用の形式 | Parquet などのファイルの上に Iceberg や Delta Lake のメタデータ |
| AWS の代表例 | Redshift | S3＋Glue Data Catalog＋Athena | S3 上の Iceberg テーブル・S3 Tables |
ウェアハウスは入れる前に整え、レイクは置いてから整え、レイクハウスは置いたファイルのまま整った状態を守る、と覚えると 3 つを取り違えにくくなります。
なぜレイクハウスが出てきたのか
論文によると、クラウドではデータレイクとデータウェアハウスを 2 段に重ねる構成が広く使われてきました。
S3 のようなレイクに生のデータを集め、その一部を ETL で Redshift や Snowflake のようなウェアハウスへ写す構成です。
論文は、この 2 段構えに 4 つの問題があると指摘しています。
- 信頼性: レイクとウェアハウスの中身をそろえ続けるのが難しく、写す処理のたびに失敗やバグが入り込む余地がある
- データの古さ: ウェアハウスのデータはレイクより遅れ、新しいデータが届くまで何日もかかることがある
- 高度な分析の弱さ: 機械学習のように大量のデータをコードで読む処理は、ウェアハウスの独自形式を直接読めず、ファイルへ書き出す手間が増える
- 総コスト: 写し続ける処理の費用に加えて、同じデータの保存料を二重に払い、独自形式に入れたデータは別の製品へ移しにくい
論文の答えは、レイクのファイルをそのまま正本にして、表の管理と速さのほうをレイクの側へ持ち込むことでした。
機械学習の処理は Parquet のような汎用の形式を直接読めるので、ウェアハウスを経由せずに同じデータへ届きます。
一方で論文自身も、整えたデータを作る ETL の作業そのものはレイクハウスでも残ると書いています。
減るのは ETL を挟む段数のほうで、データを整える手間が消えるわけではありません。
どこで使われるか
AWS で組む場合、どのサービスがどこを受け持つかを順に見ると、3 つの関係がつかみやすくなります。
データレイクの土台は S3 で、AWS Glue のクローラーがファイルを読んで表の形を取り出し、Glue Data Catalog に登録します。
カタログに載った表は、Athena や Amazon EMR から SQL や Spark で読めます。
そのうえで、誰がどの列や行を読めるかを決めるのが AWS Lake Formation です。
Lake Formation の開発者ガイドは、S3 のデータレイクのデータと Glue Data Catalog のメタデータについて、細かいアクセス制御を管理するサービスだと説明しています。
データウェアハウスの役は Redshift が受け持ちます。
レイクハウスに当たるのは、S3 に置いた Apache Iceberg のテーブルです。
Athena の Iceberg の説明によると、Athena は Iceberg のテーブルに対して、読み取り、過去の版を読むタイムトラベル、書き込み、DDL のクエリを実行できます。
Amazon S3 Tables は、表形式のデータを Iceberg 形式で置くための、テーブルバケットという専用のバケットを使うサービスです。
AWS のレイクハウスの解説では、S3 のデータレイクと Redshift のデータウェアハウスをまとめて扱う仕組みとして、Amazon SageMaker のレイクハウスアーキテクチャが紹介されています。
レイクやレイクハウスの中は、データの整い具合で層に分けて置くことが多く、Databricks はこれをメダリオンアーキテクチャと呼んでいます。
ブロンズは取り込んだままの生データ、シルバーは重複を除いて検証したデータ、ゴールドは分析やレポート向けに集計したデータの層です。
私の個人開発では、2 つのサイトの CloudFront のアクセスログが、gzip で圧縮した TSV のまま S3 に届くようにしています。
Python のスクリプトが毎日それを読み、訪問者数やエラーを数えています。
生のまま置き、読むときに形を決める点はデータレイクと同じです。
ただ、カタログも SQL のエンジンも置いていないので、データレイクと呼べるほどの仕組みではありません。
先に知っておく用語
この先の選び分けと落とし穴で出てくる言葉を、短く確かめておきます。
- スキーマ・オン・ライト: データを書き込む前に表の形を決めておき、合わないデータは入れない考え方
- スキーマ・オン・リード: 形を決めずに置いておき、読むときに形を当てはめる考え方
- オープンテーブルフォーマット: Parquet などのファイルの集まりを 1 つの表として扱うための公開された仕様で、Apache Iceberg・Delta Lake・Apache Hudi が代表例
- データカタログ: どこにどんな表があり、列の名前と型が何かを記録する台帳で、AWS では Glue Data Catalog が当たる
- スナップショット: Iceberg などで、ある時点の表の状態を記録したもの。過去の版を読むタイムトラベルにも使う
- データスワンプ: 目録や権限の仕組みが無いまま、何がどこにあるか分からなくなったデータレイク
いつ使わないか
3 つは上下関係ではないので、データの種類と使い道に合わせて選びます。
| 状況 | 選ぶもの | 理由 |
|---|---|---|
| 業務のシステムの表を集め、決まったレポートや BI に使う | データウェアハウス（Redshift） | 整えた表だけを利用者に見せられる |
| ログや画像など形のそろわないデータを、使い道が決まる前から残しておきたい | データレイク（S3＋Glue Data Catalog） | 安い保存先に元の形のまま置ける |
| 同じデータを BI と機械学習の両方から使い、ウェアハウスへの二重コピーを減らしたい | レイクハウス（Iceberg のテーブル・S3 Tables） | 1 つの保存先を複数のエンジンから読める |
| 複数の表をまとめて 1 つのトランザクションで更新する処理が多い | データウェアハウス | 表をまたぐ更新はウェアハウスのほうが素直に書ける |
| データが小さく、集計の種類も決まっている | 業務のデータベースのまま | 集める仕組みを増やすと、その保守も増える |
データレイクを選ばなくてよいのは、集めるものがほぼ業務の表だけで、使い道も決まっている場合です。
生のまま置ける利点が生きず、読むたびに形を当てはめる手間だけが残ってしまいます。
レイクハウスは、表の管理をレイクの側で引き受ける分、ファイルの整理のような手入れも自分たちの仕事になります。
論文が書かれた 2021 年の時点では、Delta Lake・Iceberg・Hudi のトランザクションは 1 つの表の単位にとどまっていました。
表をまたぐ更新が多い処理なら、まずウェアハウスを候補にしたほうが組みやすいでしょう。
反対に、ウェアハウスだけで済ませにくいのは、画像や文書のようなデータを扱う場合と、機械学習から大量のデータを直接読みたい場合です。
独自形式に入れたデータを後から別の製品へ移せるかどうかも、選ぶ前に確かめておきたいところです。
データを自分たちの形式で取り出せるかという撤退の道の確かめ方は、作るか買うかの判断を扱った記事でも書きました。
形のそろったデータを決まった問いに使うならウェアハウス、使い道の決まらないデータを残すならレイク、同じデータを BI と機械学習で分け合うならレイクハウス、と考えると出発点を決めやすくなります。
課金と落とし穴
レイクやレイクハウスは保存が安い代わりに、課金の対象が細かく分かれ、手入れも自分の側に残ります。
課金の軸
金額は改定されやすいので、ここでは何に対して払うかだけを挙げます。
Athena と Redshift の課金の軸は OLTP と OLAP の記事で触れたので、ここでは省きました。
- S3: 保存した量と、バケットやオブジェクトへのリクエストに課金される
- Glue Data Catalog: 保存したメタデータのオブジェクト数と、カタログへのリクエスト数で課金される。どちらも毎月 100 万までは無料で、表だけでなくパーティションや表の版も 1 オブジェクトとして数える
- Glue のクローラー: 使った処理能力（DPU）の時間で課金される。秒単位で、1 回の実行につき最低 10 分ぶん
- Lake Formation: 権限の作成と利用は無料で、保存先の S3 や Glue Data Catalog にはそれぞれの料金がかかる
- S3 Tables: 保存量とリクエスト、オブジェクトの数に応じた監視の料金に加え、自動で行う圧縮（コンパクション）で処理したオブジェクト数とデータ量にも課金される
置いただけのレイクはデータスワンプになる
AWS のデータレイクの解説は、データを目録にまとめて守る仕組みが無いと、データが見つからず信頼もされない「データスワンプ」になると注意しています。
先ほどの私のアクセスログも、ファイルの中身の意味を知っているのは、読んでいるスクリプトだけです。
読む人やスクリプトが増えるなら、表としてカタログに登録しておかないと、同じ形を何度も調べ直すことになります。
小さなファイルと古いスナップショットがたまる
Athena の Iceberg テーブルの最適化の説明によると、データがたまるにつれて、扱うファイルの数と行単位の削除を記録したファイルが増え、クエリの効率が落ちていきます。
そのために用意されている操作が 2 つあります。
OPTIMIZE は、小さなファイルや削除の記録を、ほどよい大きさのファイルへ書き直す圧縮の操作です。
VACUUM は、期限を過ぎた古いスナップショットと、今の表の状態から参照されないファイルを消します。
次は、ドキュメントにある例からの抜粋です。
-- 削除の記録をデータのファイルへまとめ、目標の大きさに近いファイルへ書き直す
OPTIMIZE iceberg_table REWRITE DATA USING BIN_PACK
WHERE category = 'c1'
-- 3 日（259200 秒）より古いスナップショットを消す設定にしてから VACUUM する
ALTER TABLE iceberg_table SET TBLPROPERTIES (
'vacuum_max_snapshot_age_seconds'='259200'
)
VACUUM iceberg_tableS3 Tables は、圧縮やスナップショットの管理、参照されないファイルの削除を自動で続けます。
S3 のドキュメントは、この手入れで使われないオブジェクトが片付き、保存料も下がると説明しています。
ただし、前の節で挙げたとおり、圧縮の処理そのものは課金の対象です。
権限が IAM と Lake Formation の二重になる
Lake Formation の権限モデルは、IAM の権限モデルを補う独自のものです。
ハイブリッドアクセスモードでは、Lake Formation の権限と、S3・Glue の IAM ポリシーの両方でアクセスを制御できます。
少しずつ移せる反面、ある人が表を読めるとき、どちらで許可されたのかを両方確かめる必要が出てきます。
Athena の説明には、Lake Formation に登録した Iceberg のテーブルには、Athena から DDL を実行できないとも書かれています。
さらに、VACUUM・MERGE・UPDATE・OPTIMIZE といった操作の権限は、Lake Formation では管理できません。
なお、S3 Tables のテーブルバケットでは S3 のブロックパブリックアクセスが常に有効で、無効にはできません。
他クラウドでは
Google Cloud では、BigQuery がデータウェアハウス、Cloud Storage がデータレイクの保存先に当たります。
レイクハウスに当たるのは、Cloud Storage 上の Apache Iceberg のテーブルを管理する Lakehouse というサービスです。
Google Cloud の Lakehouse の説明によると、2026 年 4 月 20 日に BigLake は Lakehouse へ名前が変わりました。
メタデータを管理する BigLake metastore も、Lakehouse runtime catalog という名前になっています。
API やコマンド、IAM の名前は BigLake のままなので、古い資料と読み比べるときは名前の違いに気をつけてください。
同じ Iceberg のテーブルを、BigQuery・Apache Spark・Apache Flink・Trino などのエンジンから読めます。
Azure では、Azure Data Lake Storage がデータレイクの保存先です。
独立したサービスではなく、Blob Storage で階層型名前空間を有効にすると使える機能の集まりです。
データウェアハウスには Azure Synapse Analytics の専用 SQL プールがあり、レイクハウスには Microsoft Fabric のレイクハウスが当たります。
Fabric のレイクハウスの説明によると、レイクハウスは Delta Lake でデータを管理し、Apache Spark と SQL の両方で分析できます。
Fabric ではレイクハウスとウェアハウスが同じ SQL エンジンを使い、どちらも OneLake に Delta 形式でデータを置く作りです。
違いとして挙がっているのは、主に使う道具（Spark か T-SQL か）、扱うデータの種類、複数の表をまたぐトランザクションの有無で、表をまたぐトランザクションに対応するのはウェアハウスだけです。
クラウド事業者のサービスとは別に、Snowflake のように AWS・Google Cloud・Azure のどれの上にもアカウントを置ける製品もあります。
ここまでのサービスを 3 社で並べると、次のとおりです。
| 区分 | AWS | Google Cloud | Azure |
|---|---|---|---|
| データウェアハウス | Redshift | BigQuery | Azure Synapse Analytics の専用 SQL プール・Fabric のウェアハウス |
| データレイクの保存先 | S3 | Cloud Storage | Azure Data Lake Storage |
| レイクハウス | S3 上の Iceberg テーブル・S3 Tables | Lakehouse（旧 BigLake） | Fabric のレイクハウス |
参考
本文のリンクで紹介した公式ドキュメントと論文は、いずれも 2026-10-03 に参照しました。
製品名や料金は変わることがあり、Google Cloud の BigLake のように名前ごと変わる例もあるので、構成を決める前にはリンク先の最新の記述を確かめてください。
最後に
データウェアハウスは入れる前に形を決め、データレイクは生のまま置いて読むときに形を決めます。
レイクハウスは、レイクのファイルをそのまま正本にして、表の管理と速さをレイクの側へ持ち込む考え方でした。
資格試験では、AWS の SAA-C03 の試験ガイドのドメイン 3 のタスク 3.5 が、Athena・Lake Formation・Glue と、データレイクの構築と保護を挙げています。
Azure の DP-900 の学習ガイドでも、分析のワークロードの中で、分析用のデータストアの選択肢と、Azure Databricks・Microsoft Fabric が出題範囲に入っています。
集めたいデータが表だけかどうかと、誰がどの道具で読むのかを先に書き出してみると、3 つのうちどこから始めるかを決める手がかりになります。
以上です。
コメントを残す