「ログも売上も、とりあえず S3 に置いてある。そこから分析したいと言われたが、データベースに入れ直すべきか、S3 のまま使えるのかが分からない」。データレイクという言葉は聞くのに、S3・Glue・Athena・Lake Formation・Redshift がどうつながるのかが1枚の絵になっていない——実務でこの段階にいる人向けの記事です。
データレイクは、特定の製品の名前ではなく、データを生のまま1か所に置き、台帳を付けて、読むときに形を当てるという置き方の考え方です。この1文を先に持っておくと、どのサービスがどの役割を担っているかを説明できるようになります。
この記事の結論
- データレイクは、形の決まったデータも決まっていないデータも、生のまま1か所に置いて、読むときに形を当てる置き場です。
- データウェアハウスは、あらかじめ形（スキーマ）を決めて整えたデータに、速い SQL を繰り返し投げるための置き場です。
- AWS の基本形は、S3 に置き、AWS Glue Data Catalog に表の定義を登録し、Amazon Athena で SQL を投げる3段です。
- Athena はスキャンした量で課金されるので、列指向の形式（Parquet）とパーティションで読む量を減らすことが費用の対策になります。
- 列や行の単位の権限は S3 のポリシーでは引けないので、AWS Lake Formation で Data Catalog のテーブルに対して付与します。
データレイクとは何か
データレイクは、業務システムの表のような構造化されたデータも、アプリのログ・画像・センサーの値のような構造の決まっていないデータも、取り込む時点ではスキーマを決めずにそのまま置いておく中央の置き場です（AWS の解説ページの定義）。どう使うかは、読むときに決めます。
これと対になるのがデータウェアハウスです。業務システムから集めたデータを、分析しやすい形に整えてから入れ、スキーマを先に決めておくことで、速い SQL の集計を繰り返し実行できるようにします。
LAKE OR WAREHOUSE2つの置き場
違いは形を決める時期。読むときか、入れる前か
データレイク
S3 ＋ Glue Data Catalog ＋ Athena
- 生のまま置く
- 形は読むときに当てる
- 構造のないデータも置ける
- 大量に安く置く
データウェアハウス
Amazon Redshift
- 整えてから入れる
- スキーマを先に決める
- 構造化されたデータが中心
- 繰り返しの SQL を速く返す
| 比べる点 | データレイク | データウェアハウス |
|---|---|---|
| 置くデータ | 構造化・半構造化・非構造化のすべて | 主に構造化されたデータ |
| スキーマを決める時期 | 読むとき（取り込みでは決めない） | 入れる前（先に設計する） |
| 整える手間 | 置くのは速い。使う側で整える | 入れる前に整える（ETL） |
| 得意なこと | 大量のデータを安く置く、機械学習や探索的な分析 | 定型のレポート・ダッシュボードへの速い SQL |
| AWS での代表 | Amazon S3 ＋ AWS Glue Data Catalog ＋ Amazon Athena | Amazon Redshift |
AWS の解説でも、多くの組織は両方を持ち、用途で使い分けるとしています。「どちらを選ぶか」より「何をどちらに置くか」を決めるものです。
AWS でのデータレイクの基本形とは
AWS でデータレイクを組むとき、最初に押さえる基本形は3段です。
THE BASIC SHAPEAWS の基本形
置いて、整えて、台帳に載せ、SQL で読む
-
S3
生のまま置く
-
Glue ジョブ
Parquet に整える
-
Data Catalog
表の定義を登録
-
Athena
SQL でその場で読む
1. 置く: Amazon S3
データの実体は S3 に置きます。容量を先に決める必要がなく、大量のファイルを安く置けるので、データレイクの置き場として定番です。取り込んだままの生データ、整形したデータ、分析用に整えたデータ、のようにプレフィックスで層を分けて置くのがよくある形です。層を分けておくと、変換をやり直したくなったときに生データから作り直せます。
2. 台帳を付ける: AWS Glue Data Catalog
S3 のファイルは、そのままでは「どこに・どんな列の・どの形式のデータがあるか」が分かりません。AWS Glue Data Catalog は、その定義（データベース・テーブル・列・形式・S3 上の場所・パーティション）を持つメタデータの台帳です。Glue のクローラーを S3 に向けて実行すると、ファイルを読んでスキーマとパーティションを推定し、テーブルとして登録・更新します。
Data Catalog は Athena だけでなく、Amazon EMR や Redshift Spectrum からも共通に参照できます。定義を1か所に持つことで、列を足したときに直す場所が1つで済みます。
整形そのもの（CSV を Parquet に変える、不要な列を落とす、日付で分けて書き直す）は、サーバーを管理しない ETL の仕組みである AWS Glue のジョブで行えます。
3. 読む: Amazon Athena
Amazon Athena は、S3 上のデータに標準の SQL を投げるサーバーレスのクエリサービスです。データを取り込まず、Data Catalog の定義に従って S3 のファイルをその場で読みます。サーバーを用意しなくてよい代わりに、クエリがスキャンしたデータの量で課金されるのが基本です。単価は改定されることがあるので、Athena の料金ページで確認してください。
CHECK 1ここまでの確認
S3 に置いたファイルを Athena から表として SQL で読めるのは、何があるから?
答えと解説
答え: 2. AWS Glue Data Catalog にテーブルの定義（列・形式・場所・パーティション）が登録されているから
Athena はデータを取り込まず、S3 のファイルをその場で読みます。どこに何がどんな形で置いてあるかを教えるのが Glue Data Catalog です。「AWS でのデータレイクの基本形とは」の章を読み直してください。
なぜ Parquet とパーティションで読む量が変わるのか
Athena の費用と速さは、クエリがどれだけのデータを読むかでほぼ決まります。読む量を減らす手段は、置き方の側にあります。
列指向の形式にする
CSV や JSON は行ごとにデータが並ぶ形式なので、数列しか使わないクエリでも行全体を読みます。Apache Parquet や ORC のような列指向の形式は、列ごとにまとめて保存するので、クエリが使う列だけを読めます。列ごとに圧縮も効きます。
| 形式 | 並び方 | 数列だけ使うクエリで読む量 |
|---|---|---|
| CSV / JSON | 行ごと | 行全体を読む |
| Parquet / ORC | 列ごと（圧縮も効く） | 使う列だけを読む |
よく絞り込む条件でパーティションを切る
パーティションは、よく使う絞り込みの条件（日付など）ごとに、S3 のプレフィックスを分けて置く方法です。
s3://example-datalake/curated/orders/dt=2026-09-27/part-0000.parquet
s3://example-datalake/curated/orders/dt=2026-09-28/part-0000.parquet
WHERE dt = '2026-09-28' のように絞り込むと、Athena は条件に合うパーティションだけを読みます。実際のクエリで使う条件で切るのが要点で、クエリで使わない値（作成者の名前など）で分けても読む量は減りません。
行単位で直したいなら、テーブル形式を選ぶ
Parquet のファイルは、一部の行だけを書き換えるのが苦手です。個人情報の削除依頼のように、行単位の更新・削除が定期的に発生するなら、Apache Iceberg のようなテーブル形式を使うと、Athena から DELETE や UPDATE で行単位に変更できます。
CHECK 2ここまでの確認
Athena で数百列あるログの数列だけを毎日集計しているとき、読む量を大きく減らせる置き方は?
答えと解説
答え: 2. Parquet のような列指向の形式にし、よく絞り込む日付でパーティションを切る
列指向なら使う列だけを、パーティションがあれば条件に合う場所だけを読めます。Athena はスキャンした量で課金されるので、読む量はそのまま費用になります。「なぜ Parquet とパーティションで読む量が変わるのか」の章を読み直してください。
権限はどこで引くのか
データレイクは部署をまたいで使われるので、「誰に、どのテーブルの、どの列・行まで見せるか」が必ず問題になります。ここで押さえるべきなのは、S3 のバケットポリシーや IAM ポリシーはオブジェクト（ファイル）単位の制御だということです。1つの Parquet ファイルの中の「氏名の列だけ隠す」「自分の地域の行だけ見せる」は、S3 の側では表現できません。
AWS Lake Formation は、S3 上のデータと Glue Data Catalog のメタデータに対して、きめ細かいアクセス制御を一元的に管理するサービスです。IAM の権限モデルを補う独自の権限モデルを持ち、Data Catalog のテーブルに対して権限を付与します。
FINE-GRAINED ACCESS列と行の権限
S3 では引けない列と行の境界を、Lake Formation で引く
Lake Formation の権限
- 列購買の列 見える分析担当に付与
- 列氏名・電話 見えない付与していない
- 行自分の地域 見える行フィルター式
- 共有事業部のアカウント 参照できるクロスアカウント共有
| やりたいこと | Lake Formation での手段 |
|---|---|
| 個人を特定できる列を見せない | 列を指定（または除外）してテーブルの権限を付与する |
| 自分の地域の行だけ見せる | データフィルターの行フィルター式を付与する |
| テーブルが増えても権限を付け直さない | LF タグを付け、タグの条件で権限を付与する（LF-TBAC） |
| 別アカウントからコピーなしで参照させる | クロスアカウントのデータ共有で権限を付与する |
データレイクの権限でやってはいけない3つ
- 列を隠すために、列を消したコピーのテーブルを作って配る（定義とデータが二重になり、どちらが正しいか分からなくなる）
- 他部署に見せるために、読み取り用のアクセスキーを渡す（鍵の管理と失効ができなくなる）
- 共有を急いで、バケットを公開する（S3 のブロックパブリックアクセスで止めておく）
Lake Formation を使うときも、利用者には Athena などを使うための IAM の権限が要ります。IAM は「サービスを使ってよいか」、Lake Formation は「どのテーブルのどこまで読めるか」と、役割を分けて考えると整理しやすくなります。
CHECK 3ここまでの確認
同じテーブルの中で、分析担当者には個人を特定できる列を見せたくないとき、権限を引く場所として合っているのは?
答えと解説
答え: 2. AWS Lake Formation のテーブルの権限
S3 のポリシーはオブジェクト（ファイル）単位の制御です。Lake Formation は Data Catalog のテーブルに対して、列・行を指定した権限を付与できます。「権限はどこで引くのか」の章を読み直してください。
Amazon Redshift はどこに置くのか
Amazon Redshift は AWS のデータウェアハウスです。大量の構造化データに対する複雑な集計や結合を、繰り返し速く返すことに向いています。データレイクと Redshift は、競合ではなく役割の分担です。
| 比べる点 | Amazon Athena（データレイクを直接読む） | Amazon Redshift（データウェアハウス） |
|---|---|---|
| データの置き場 | S3（取り込まない） | Redshift の中（COPY でロード） |
| 準備 | Data Catalog の定義があればすぐ読める | テーブル設計とロードが要る |
| 向いている使い方 | 探索的な分析、たまに走らせる集計 | 定型のダッシュボード、同時に多くの人が使う BI |
よくある分担は、直近でよく使うデータを Redshift に置き、長期の履歴は Parquet で S3 に置いたままにする形です。Redshift には Redshift Spectrum という機能があり、S3 のデータを Redshift にロードせずに外部テーブルとして読み、Redshift 内のテーブルと結合できます。Spectrum も Glue Data Catalog の定義を使えるので、ここでも「台帳は1か所」が効いてきます。
READ ALSO — 学習中向け・段1 入口
S3 とは何か｜バケットとオブジェクト・ストレージクラス・公開設定を「ディスクではない置き場」で理解する
まとめ
- データレイクは、データを生のまま1か所に置き、読むときに形を当てる置き場です。データウェアハウスは、形を決めて整えたデータに速い SQL を繰り返し投げる置き場です。
- AWS の基本形は、S3 に置く → Glue Data Catalog に表の定義を登録する → Athena で SQL を投げる、の3段です。
- Athena の費用はスキャン量で決まるので、Parquet のような列指向の形式と、実際のクエリの条件で切ったパーティションが効きます。
- 列や行の単位の権限は S3 のポリシーでは引けないので、Lake Formation で Data Catalog のテーブルに対して付与します。
- Redshift は定型の集計を速く返すデータウェアハウスで、Spectrum を使えば S3 のデータとも結合できます。
次は、データレイクを置くアカウントと、それを使う部署のアカウントをどう分けるかに進むと、クロスアカウントの共有の意味がはっきりします。
参照ソース
- What is a Data Lake?（AWS） — データレイクの定義（取り込み時にスキーマを決めない、構造化・非構造化のデータを置く）の根拠（2026-09 時点の記載）
- Data Lake vs Data Warehouse vs Data Mart（AWS） — データウェアハウスとの違い、多くの組織が両方を持つこと、S3 と Redshift の位置づけの根拠（2026-09 時点）
- What is AWS Glue?（AWS Glue 開発者ガイド） — Glue がサーバーレスのデータ統合（ETL）サービスであり、Data Catalog を持つことの根拠（2026-09 時点）
- Using crawlers to populate the Data Catalog（同） — クローラーがスキーマとパーティションを推定してテーブルを登録することの根拠（2026-09 時点）
- What is Amazon Athena?（Amazon Athena ユーザーガイド） — Athena が S3 上のデータに標準 SQL を投げるサーバーレスのサービスであることの根拠（2026-09 時点）
- Optimize data（Athena のパフォーマンスチューニング）・Partition your data（同） — 列指向形式・圧縮・パーティションで読む量が減ることの根拠（2026-09 時点）
- Query Apache Iceberg tables（同） — Iceberg テーブルに対する行単位の更新・削除の根拠（2026-09 時点）
- What is AWS Lake Formation?（AWS Lake Formation 開発者ガイド） — S3 のデータと Data Catalog のメタデータのきめ細かいアクセス制御、IAM を補う独自の権限モデルの根拠（2026-09 時点）
- Data filtering and cell-level security（同）・Lake Formation tag-based access control（同）・LF-TBAC によるクロスアカウントの権限付与（同） — 列・行の制御、LF-TBAC、クロスアカウント共有の根拠（2026-09 時点）
- Querying external data using Amazon Redshift Spectrum（Amazon Redshift データベース開発者ガイド） — S3 のデータをロードせずに外部テーブルとして読み、Redshift のテーブルと結合できることの根拠（2026-09 時点）
