データレイク・データウェアハウス・データマートの違い｜AWSとAzureのサービス対応表で理解するデータ基盤設計

「クラウドに移行したら、データ基盤もクラウドで作り直せと言われたけど、データレイクとデータウェアハウスって何が違うんだ？」——そんな疑問、インフラエンジニアなら一度は持ったはずです。

オンプレ時代はDWH製品（Teradata、Oracleなど）と共有ファイルサーバーくらいしか選択肢がなかったのに、クラウドに来た途端にAmazon S3、AWS Glue、Amazon Athena、Amazon Redshift……と選択肢が爆発します。Azureなら Azure Data Lake Storage、Azure Synapse Analytics、Azure Data Factory と名前も微妙に異なる。

この記事では、データレイク・データウェアハウス・データマートという3つの概念の違いを整理し、AWSとAzureのサービスがどれに対応するかを一覧表で示します。「どのサービスを何に使うか」が見えてくれば、クラウドデータ基盤の設計話にも臆せず入れるようになります。

3つの概念の違いをざっくり整理する

まず用語の意味から確認しましょう。現場ではこの3つが混同されがちですが、役割はかなり明確に分かれています。

1. データレイク（Data Lake）

生のデータをそのまま大量に溜め込む場所です。構造化データ（CSV、RDBのダンプ）だけでなく、半構造化データ（JSON、XML）、非構造化データ（画像、動画、ログファイル）も区別なく格納します。

・特徴: スキーマレス（Schema-on-Read）。書き込む時点でデータ形式を決めず、読み出す際に変換する
・コスト: オブジェクトストレージ（S3やAzure Data Lake Storage）ベースで安価に大容量保管できる
・使いどころ: ログの長期保管、機械学習のトレーニングデータ、将来の分析用に「とりあえず全部取っておく」

オンプレで例えると、NASに「とりあえず全ファイルを突っ込んでいる共有フォルダ」に近い感覚です。整理はされていないが、何かあればここを掘ればある。

2. データウェアハウス（Data Warehouse / DWH）

分析・集計クエリのために最適化されたデータベースです。データレイクから取り出してきたデータを、クレンジング・整形・集計しやすい形に変換して格納します。

・特徴: スキーマ定義済み（Schema-on-Write）。カラム指向型のストレージで集計クエリが高速
・コスト: データレイクより高価。スキャンするデータ量に応じて課金されるケースが多い
・使いどころ: 経営ダッシュボード、売上分析、Webアクセス統計など「定型的な分析クエリ」

オンプレ時代に使っていたOracleやTeradataのDWH製品がこれに相当します。クラウドではフルマネージドなので、ハードウェア調達やチューニングの手間がなくなります。

3. データマート（Data Mart）

データウェアハウスの中から、特定の部門・用途向けに切り出したサブセットです。「営業部門用の売上データだけを集めたDB」「マーケティング部門が使うキャンペーン効果測定用DB」のように、目的別に分割・最適化します。

・特徴: DWHのサブセット。特定ユーザーが速く使えるよう最小限に絞り込む
・コスト: データが絞られているので、クエリコストが抑えられる
・使いどころ: 部門別BIツール連携、部署ごとのアクセス権限制御が必要な場合

「DWHは全社共通の大きな倉庫、データマートは各部門の棚」とイメージすると理解しやすいです。

3つの関係性と一般的なデータフロー

現代のクラウドデータ基盤では、次の流れが標準的なパターンです。

データレイクは「収集」、データウェアハウスは「整理」、データマートは「配布」の役割と覚えると現場での会話がスムーズになります。

AWSサービスの対応表

次にAWSの各サービスがどのレイヤーに対応するか整理します。

AWSのデータ基盤では「S3がデータレイクの土台、Redshiftがデータウェアハウス、GlueがETLの橋渡し」と覚えておくと全体像が把握しやすくなります。

# AWS Athena でS3のParquetファイルにクエリを実行する例（AWS CLI）
# 事前にGlueデータカタログにテーブル定義を登録しておくこと

aws athena start-query-execution \
  --query-string "SELECT event_type, COUNT(*) FROM access_logs WHERE dt='2026-06-01' GROUP BY event_type" \
  --query-execution-context Database=my_database \
  --result-configuration OutputLocation=s3://my-query-results/athena/ \
  --region ap-northeast-1

# クエリ実行IDを取得後、結果を確認
aws athena get-query-results \
  --query-execution-id  \
  --region ap-northeast-1

Azureサービスの対応表

Azure側のサービスマッピングも確認しましょう。AWSと名前が違うだけで役割はほぼ対応しています。

Azure環境では「ADLS Gen2がデータレイク、Synapse Analyticsがデータウェアハウス、ADFがETLの橋渡し」がセットで出てきます。AWS経験者であれば、S3→ADLS Gen2、Redshift→Synapse、Glue→ADFと読み替えると設計の議論に追いつきやすくなります。

AWS vs Azure のサービス対応早見表

料金の仕組みと設計時の注意点

1. データレイクのストレージコスト（2026年3月時点）

Amazon S3の東京リージョン（ap-northeast-1）の場合、スタンダードストレージで月額約$0.025/GBです。100TBを保管すると月額$2,500前後になります。ここで注意が必要なのはデータ転送料です。S3からEC2（同一リージョン）の転送は無料ですが、インターネット経由では別途費用がかかります。

Azure Data Lake Storage Gen2はLRS（ローカル冗長ストレージ）で月額約$0.020/GBとS3より若干安価ですが、ETLの実行コストや接続費用も含めて総合的に比較する必要があります。

2. Athena vs Redshift のクエリコスト比較

・Amazon Athena: スキャンしたデータ1TBあたり$5。アドホックな分析には向くが、スキャン対象を絞らないと費用が膨らむ
・Amazon Redshift: ノード課金（dc2.largeで$0.25/時）。RA3なら使ったストレージ分だけ課金。クエリ頻度が高い定型分析ならRedshiftのほうが割安になるケースが多い

現場での判断基準として、「月に数回しか使わないアドホック分析 → Athena、毎日バッチで動くレポート → Redshift」と使い分けるのが定石です。

3. ETLコストの落とし穴

AWS GlueのETLジョブはDPU（Data Processing Unit）単位で課金され、1DPUあたり$0.44/時（2026年3月時点）です。データ量が少ないジョブでも最低10分課金されるため、小さなデータ変換を大量に走らせると予想外の費用が発生します。AWS Glue Studioを使う場合は、ジョブの実行時間とDPU数のモニタリングを忘れずに設定してください。

よくあるつまずきと対処法

1. 「データレイクに入れたのに分析できない」問題

S3にデータを放り込んだだけではAthenaでクエリできません。AWS Glueクローラーを実行してデータカタログにスキーマを登録するか、手動でテーブル定義を作る必要があります。「データを入れた → すぐ分析できる」と思い込むと最初の壁になります。

2. データ形式の混在によるパフォーマンス劣化

データレイクにCSVとJSONとParquetが混在していると、Athenaのクエリコストが跳ね上がります。可能な限りParquet形式（カラム指向）に統一し、パーティション（例: 日付別フォルダ）を設定することで、スキャン対象データ量を大幅に削減できます。AthenaのコストはS3のスキャン量に直結するため、この最適化は費用対効果が高いです。

3. RedshiftへのデータロードはCOPYコマンドを使う

RedshiftへのデータロードはCOPYコマンドを使います。CSVやJSONを直接INSERT文で入れようとするのは、パフォーマンス面でNGです。S3からのCOPYコマンドを使えば、並列ロードで高速にデータを取り込めます。

# Amazon RedshiftへS3からデータをロードする例（Redshift Query Editor）
# IAMロールにS3ReadOnlyAccessを付与しておくこと

COPY my_schema.sales_data
FROM 's3://my-data-lake/sales/2026/06/'
IAM_ROLE 'arn:aws:iam::123456789012:role/RedshiftCopyRole'
FORMAT AS PARQUET;

4. Azure Synapse Analyticsの「プール」概念で混乱する

Azure Synapse Analyticsには「Dedicated SQL Pool」「Serverless SQL Pool」「Spark Pool」の3つのエンジンがあります。最初は混乱しますが、「Dedicated = 常時起動のDWH（Redshiftに近い）」「Serverless = Athenaのようなアドホッククエリ」「Spark = Amazon EMRのようなビッグデータ処理」と読み替えると整理できます。

実務でよく使われるデータ基盤設計パターン

1. ラムダアーキテクチャ（バッチ + リアルタイムの並立）

バッチ処理（毎日ETLでDWHに取り込む）とリアルタイム処理（Kinesis/Event Hubsでストリーミング分析）を並立させる設計です。オンプレ時代にはシステム構築コストが高かったため敬遠されがちでしたが、クラウドではサービスを組み合わせるだけで実現できます。

2. データレイクハウス（レイクとDWHの統合）

Delta Lake（Databricks）やApache Icebergなどのオープンテーブルフォーマットを使い、S3/ADLS Gen2上のデータレイクに対してDWH相当のACID準拠クエリを実行する設計です。AWSでは「S3 + Athena + Glueデータカタログ + Iceberg」の組み合わせがこれに相当し、RedshiftとAthenaの中間的な用途をカバーします。

3. ETLパイプラインのIaC化

ETLパイプラインの設定はGUIだけで管理せず、AWS Glueのジョブ定義はTerraformまたはAWS CloudFormationでコード管理することを推奨します。Azure Data Factoryは「ARMテンプレート」または「Bicep」でのエクスポートが可能です。パイプラインの変更も必ずGitで管理し、本番環境への直接変更は避けましょう。

クラウド上のLinuxサーバー構築については、姉妹サイトLinuxMaster.JPで詳しく解説しています。EC2やAzure VMでデータパイプラインのスクリプトを動かす際は、Linuxコマンドの基礎が欠かせません。

本記事のまとめ

データレイクは「とりあえず全部取っておく倉庫」、データウェアハウスは「分析用に整理された書棚」、データマートは「各部門の専用棚」です。クラウド移行の文脈でこの3つの区別ができていれば、データ基盤の設計会議でも議論についていけるようになります。

AWSならS3 + Glue + Athena + Redshiftの構成、AzureならADLS Gen2 + ADF + Synapse Analyticsの構成が定番の出発点です。まずは一つの構成で小さく始め、データ量とクエリ頻度に応じてスケールアップしていくアプローチを取ると、コスト管理もしやすくなります。