【AWS】Schema on Write と Schema on Read を正しく理解する — Athena・Redshift での実践ガイド

Last updated at 2026-03-15Posted at 2026-03-15

【AWS】Schema on Write と Schema on Read を正しく理解する — Athena・Redshift での実践ガイド

はじめに

「S3 にデータを置いて Athena でクエリする」「Redshift にデータをロードして分析する」——AWS でデータ分析基盤を構築するとき、この 2 つのアプローチの違いを意識しているでしょうか。

この違いの根底にあるのが Schema on Write（書き込み時スキーマ）と Schema on Read（読み取り時スキーマ）という 2 つのデータ管理アプローチです。どちらを選ぶかによって、データパイプラインの設計、コスト構造、運用方法が大きく変わります。

この記事では、両アプローチの概念を整理した上で、AWS の主要データ分析サービス（S3、Athena、Redshift、QuickSight）との対応関係と、実践的なアーキテクチャパターンを解説します。

この記事で得られること：

Schema on Write / Schema on Read の本質的な違い
AWS サービスごとのスキーマアプローチの対応関係
ユースケース別の実践的なアーキテクチャパターン
自分のプロジェクトに最適なアプローチを選ぶ判断基準

Schema on Write と Schema on Read とは

Schema on Write — 「書く前に構造を決める」

Schema on Write は、データを格納する前にスキーマ（データ構造）を定義し、そのスキーマに合致するデータだけを書き込むアプローチです。

[データソース] → [スキーマ定義に従って変換] → [ストレージに書き込み]
                  ↑ ここでスキーマを適用

リレーショナルデータベースを使ったことがあれば馴染み深いはずです。CREATE TABLE で型や制約を定義し、INSERT 時にスキーマに合わないデータは拒否される——これが Schema on Write です。

特徴：

データの一貫性・整合性が保証される（型、制約、正規化）
クエリパフォーマンスが高い（データが事前に最適化されている）
BI ツールとの親和性が高い（構造が明確）
一方で、スキーマ設計が事前に必要で、変更コストが高い

Schema on Read — 「読むときに構造を決める」

Schema on Read は、データをそのままの形式で格納し、読み取り（クエリ）の時点でスキーマを適用するアプローチです。

[データソース] → [そのまま格納] → [クエリ時にスキーマを投影して読み取り]
                                    ↑ ここでスキーマを適用

JSON、CSV、ログファイルをそのまま保存しておき、必要なときに「この列は文字列、この列は数値」と解釈しながらクエリする——これが Schema on Read です。

特徴：

データ取り込みが高速（変換不要でそのまま格納）
スキーマの柔軟性が高い（後から自由に定義・変更可能）
多様なデータ形式に対応（JSON、CSV、ログ、画像など）
一方で、クエリ時のパフォーマンスは相対的に低い

ETL と ELT — パイプラインとの対応関係

この 2 つのアプローチは、データパイプラインの設計パターンと密接に対応しています。

パイプライン	処理順序	スキーマアプローチ
ETL	Extract → Transform → Load	Schema on Write
ELT	Extract → Load → Transform	Schema on Read

ETL ではデータをロードする前に変換（Transform）します。スキーマに合わせてデータを整形してから格納するので、Schema on Write に対応します。

ELT ではデータをまずそのままロードし、必要に応じて後から変換します。格納時点ではスキーマを強制しないので、Schema on Read に対応します。

よくある誤解： Schema on Read は「スキーマ定義が不要」という意味ではありません。Athena でも CREATE TABLE でスキーマ（カラム名・型）を定義します。違いは「データ格納時にスキーマを強制するか」です。Schema on Read では、スキーマはメタデータとして管理され、クエリ時に投影されます。

比較表

観点	Schema on Write	Schema on Read
スキーマ適用	書き込み時（事前）	読み取り時（事後）
パイプライン	ETL	ELT
データ取り込み速度	遅い（変換が必要）	速い（そのまま格納）
クエリパフォーマンス	高い	相対的に低い
スキーマ変更の柔軟性	低い	高い
データ品質	高い（事前バリデーション）	要注意（品質管理が別途必要）
対応データ形式	構造化データ	構造化 / 半構造化 / 非構造化
代表的な AWS サービス	Redshift	S3 + Athena

AWS サービスでの対応関係

AWS のデータ分析サービスは、それぞれ異なるスキーマアプローチを体現しています。まず全体像を把握しましょう。

サービス	スキーマアプローチ	役割
S3 + Athena	Schema on Read	データレイク + サーバーレスクエリ
Redshift	Schema on Write	データウェアハウス
Redshift Spectrum	ハイブリッド	データレイクと DWH の橋渡し
QuickSight	両対応	可視化レイヤー

各サービスの位置づけを見ていきましょう。

S3 + Athena = Schema on Read の王道

Amazon S3 はスキーマを一切強制しないオブジェクトストレージです。CSV でも JSON でも Parquet でも、どんなデータでもそのまま格納できます。これが Schema on Read の土台になります。

Amazon Athena は S3 上のデータに直接 SQL を実行するサーバーレスクエリエンジンです。テーブル定義でスキーマを宣言しますが、これはあくまで「S3 上のデータをどう解釈するか」というメタデータです。

-- 事前に CREATE DATABASE my_database; でデータベースを作成済みとする
-- Athena でのテーブル定義例
-- S3 上のデータには一切手を加えず、クエリ時にスキーマを投影する
CREATE EXTERNAL TABLE access_logs (
    request_time string,
    method string,
    path string,
    status_code int,
    response_time_ms double
)
ROW FORMAT SERDE 'org.apache.hadoop.hive.serde2.OpenCSVSerde'
LOCATION 's3://my-bucket/logs/';

ポイント：

データは S3 にそのまま配置するだけ。ETL は不要
AWS Glue Crawler でスキーマを自動検出し、Glue Data Catalog に登録できる
スキーマ進化にも柔軟に対応。Parquet 形式ならカラムの追加・削除・並び替えが可能
コストはスキャンしたデータ量に応じた課金（1 TB あたり $5）

Redshift = Schema on Write の代表格

Amazon Redshift はフルマネージドのデータウェアハウスで、Schema on Write を体現するサービスです。

-- Redshift でのテーブル定義例
-- データロード時にスキーマが厳密に適用される
CREATE TABLE sales_summary (
    sale_date DATE NOT NULL,
    product_id VARCHAR(50) NOT NULL,
    region VARCHAR(30),
    total_amount DECIMAL(12,2),
    quantity INT
)
DISTSTYLE KEY
DISTKEY(region)
SORTKEY(sale_date);

-- S3 からデータをロード
-- スキーマに合致しないデータはエラーで拒否される
COPY sales_summary
FROM 's3://my-bucket/staging/sales/'
IAM_ROLE 'arn:aws:iam::123456789012:role/RedshiftLoadRole'
FORMAT AS PARQUET;

ポイント：

テーブル定義で型・制約を厳密に指定。不正データはロード時に拒否
列指向ストレージ、ゾーンマップ、結果キャッシュ等で高いクエリパフォーマンス
ACID トランザクション対応でデータの一貫性を保証
AWS Glue ETL で S3 のデータを変換→Redshift にロードするのが典型パターン
コストはノード数・タイプに応じた時間課金（Serverless なら RPU ベース）

Redshift Spectrum = 両方を橋渡しするハイブリッド

Redshift Spectrum は、Redshift クラスタから S3 上のデータに直接クエリを実行する機能です。Schema on Write と Schema on Read をひとつのクエリで組み合わせられます。

-- 外部スキーマの作成（Glue Data Catalog を参照）
CREATE EXTERNAL SCHEMA lake
FROM DATA CATALOG
DATABASE 'my_data_lake'
IAM_ROLE 'arn:aws:iam::123456789012:role/SpectrumRole';

-- Redshift 内部テーブル（Schema on Write）と
-- S3 外部テーブル（Schema on Read）を JOIN
SELECT
    s.product_id,
    s.total_amount,
    h.historical_trend
FROM sales_summary s                -- Redshift 内部テーブル
JOIN lake.historical_data h         -- S3 上の外部テーブル
  ON s.product_id = h.product_id;

ポイント：

Redshift 内部テーブル（高速）と S3 外部テーブル（低コスト）を統一的にクエリ
Athena と同じ Glue Data Catalog を参照可能
ホット/コールドストレージパターンに最適：頻繁にアクセスするデータは Redshift に、履歴データは S3 に配置

QuickSight = スキーマ方式を問わない可視化レイヤー

Amazon QuickSight はデータソースとして Athena と Redshift の両方をサポートし、スキーマアプローチに依存しない可視化レイヤーとして機能します。

データソース	スキーマアプローチ	QuickSight での特徴
Athena	Schema on Read	S3 上の多様なデータを柔軟に可視化
Redshift	Schema on Write	構造化データの高速な可視化
Redshift Spectrum	ハイブリッド	内部テーブルと S3 外部テーブルを統合して可視化

QuickSight のクエリモードも、スキーマアプローチとの相性があります。

SPICE モード：データを QuickSight のインメモリエンジンにインポート。定型ダッシュボードの高速表示に向いており、Schema on Write で品質が保証されたデータとの相性が良い
Direct Query モード：データソースにリアルタイムでクエリを発行。最新データの表示が必要な場合やアドホック分析に向いており、Schema on Read の柔軟性と相性が良い

データソース選択の目安：

月次レポートなど更新頻度が低い定型ダッシュボード → Redshift + SPICE（高速表示）
リアルタイムに近いモニタリング → Athena + Direct Query（最新データ）
履歴データを含む横断的な分析 → Redshift Spectrum + SPICE（コスト最適化）

実践パターン: どう組み合わせるか

パターン 1: データレイク中心 — S3 + Athena で始める

データソース → S3（raw データ） → Glue Crawler → Glue Data Catalog → Athena → QuickSight

向いているケース：

アドホック分析・探索的データ分析が中心
データソースの形式が多様（JSON、CSV、ログ等）
利用頻度が不定期で、コストを抑えたい
スキーマが頻繁に変わる、または事前に確定できない

強み： サーバーレスで運用負荷が低く、スキャン量課金のため利用頻度が低い場合にコスト効率が良い。データ取り込みは S3 にファイルを配置するだけで完了します。

注意点： S3 上のデータを Parquet や ORC などの列指向フォーマットに変換しておくと、クエリパフォーマンスとコストの両方が大幅に改善します。CSV のまま放置すると、全データスキャンが発生してコストが膨らみます。

パターン 2: DWH 中心 — Redshift で本格運用

データソース → S3（staging） → Glue ETL（変換） → Redshift → QuickSight

向いているケース：

定型レポート・ダッシュボードが中心
複雑な集計・JOIN が頻繁に発生
データ品質・一貫性が重要（経営指標、KPI レポートなど）
利用頻度が高い（常時クエリが走る）

強み： 事前に最適化されたデータに対する高いクエリパフォーマンス。データ品質が保証され、BI ツールとの連携がスムーズです。

注意点： AWS Glue 等での ETL パイプライン構築が必要で、スキーマ変更には計画的な移行が求められます。クラスタの固定費が発生するため、利用頻度が低い場合はコスト効率が悪くなります（Redshift Serverless で緩和可能）。

パターン 3: レイクハウス — 両方の強みを活かす

データソース → S3（data lake）
                ├→ Athena → QuickSight（アドホック分析）
                ├→ Redshift Spectrum（S3 外部テーブル + 内部テーブル JOIN）
                └→ Glue ETL → Redshift → QuickSight（定型レポート）

向いているケース：

アドホック分析と定型レポートの両方が必要
データの鮮度と品質のバランスを取りたい
コスト最適化（ホット/コールドの分離）が求められる

強み： AWS が推奨するモダンデータアーキテクチャです。Glue Data Catalog を共通のメタストアとして、Athena・Redshift Spectrum・Glue ETL が同じメタデータを参照できます。

段階的な構築が可能なのも大きなメリットです。

まず S3 + Athena で Schema on Read のデータレイクを構築
定型レポートの需要が増えたら Redshift を追加
Redshift Spectrum でデータレイクと DWH を接続

発展：Apache Iceberg でさらに進化

Apache Iceberg などのオープンテーブルフォーマットを使うと、S3 上のデータに ACID トランザクション、スキーマ進化、タイムトラベルを提供できます。Schema on Read の柔軟性を保ちながら、Schema on Write に近いデータ品質管理が可能です。AWS では Athena、Redshift Spectrum、EMR、Glue のすべてが Iceberg テーブルをサポートしています。

どちらを選ぶべきか — 判断基準の整理

判断軸	Schema on Read（Athena）寄り	Schema on Write（Redshift）寄り
クエリの性質	アドホック・探索的	定型・反復的
データ形式	多様（JSON、CSV、ログ等）	構造化データ中心
利用頻度	不定期・低頻度	高頻度・常時
スキーマの安定性	変動的	安定的
データ品質要件	柔軟（探索段階）	厳格（本番レポート）
パフォーマンス要件	秒〜分で許容	ミリ秒〜秒が必要
コスト優先度	変動費（従量課金）	固定費（クラスタ課金）
運用体制	小規模・サーバーレス志向	データエンジニアリングチームあり

実務的な推奨：

まず S3 + Athena（Schema on Read）から始める。 データレイクとして S3 にデータを集約し、Athena でアドホック分析。初期コストと運用負荷が最も低い構成です
定型レポートの需要が増えたら Redshift を追加。 高頻度クエリや複雑な JOIN が必要になった段階で、Redshift を導入してレイクハウスアーキテクチャに進化させます
Redshift Spectrum で段階的に統合。 内部テーブルと S3 外部テーブルを組み合わせ、コストとパフォーマンスを最適化します

二者択一ではなく、段階的に組み合わせていくのが AWS データ分析基盤の現実的な進め方です。

まとめ

Schema on Write と Schema on Read は、データ分析基盤の設計における根本的なアーキテクチャ選択です。

Schema on Write（Redshift）は、データ品質とクエリパフォーマンスを重視する場合に適しています。ETL パイプラインでデータを事前に構造化し、定型レポートや高頻度クエリに対応します
Schema on Read（S3 + Athena）は、柔軟性とコスト効率を重視する場合に適しています。データをそのまま格納し、アドホック分析や多様なデータ形式の探索に対応します
ハイブリッド（Redshift Spectrum / レイクハウス）は、両方の強みを活かすアプローチです。AWS の Glue Data Catalog を共通基盤として、Athena と Redshift を統合できます

重要なのは、どちらか一方に決め打ちするのではなく、データの性質と利用パターンに応じて適切なアプローチを選ぶことです。まず S3 + Athena でスモールスタートし、需要に応じて Redshift を追加していく段階的アプローチが、多くのケースでうまくいきます。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up