モジュール 11 · SAA-C03

データ分析

Kinesis、Firehose、Glue、Athena、EMR、Redshift、Lake Formation、OpenSearch: ビッグデータの収集、処理、クエリ。

分野高性能なアーキテクチャ
分野コスト最適化
図 12
出題パターン 11
サービス 12

5 分で押さえる要点

Kinesis Data Streams: リアルタイムのデータストリームで、consumer は自分で実装します。データは 24 時間保持され（最大 365 日まで延長可）、再読み取りもできます。「複数のアプリが同じストリームを読む」「過去のデータを再読み取り」「キー単位で順序を保持」という記述 → Kinesis Data Streams。
Amazon Data Firehose: ストリームデータを S3、Redshift、OpenSearch、Splunk などへニアリアルタイムでロードします。管理するシャードはありません。Firehose はバッファ（サイズまたは時間）単位でデータをまとめて書き込みます。Parquet への変換や Lambda による変換も可能です。「運用負荷が最小で S3 にログを送る」 → Firehose。
provisioned モードのシャード: 書き込み最大 1 MB/s または 1,000 レコード/s、読み取り 2 MB/s。on-demand モードは自動でスケールします。ProvisionedThroughputExceeded エラー: シャードを追加する、on-demand に切り替える、またはより均等に分散するパーティションキーを選びます（ホットシャードを避ける）。
Amazon MSK はマネージドの Apache Kafka です。「すでに Kafka を使っている」「Kafka API が必要」「Kafka クラスターを AWS に移行」 → Kinesis ではなく MSK。
Managed Service for Apache Flink はステートフルなストリーム処理を行います。Kinesis や Kafka 上で、フィルタリング、時間ウィンドウでの集計、異常検出ができます。「データストリームで 5 分ごとの平均を計算」 → Flink。
Athena: S3 上のデータに直接 SQL を実行します。サーバーレスで、スキャンしたデータ量に応じて課金されます。コスト削減と高速化: 列指向形式（Parquet / ORC）、圧縮、パーティション分割（例: 日付別）で、クエリごとのスキャン量を減らします。
AWS Glue: Data Catalog（共有メタデータストア）、スキーマを推定する crawler、Spark で動くサーバーレス ETL。Athena、Redshift Spectrum、EMR はいずれも Glue Data Catalog のテーブルを読み取ります。「S3 上の新しいデータのスキーマを自動検出」 → Glue crawler。
Redshift は列指向のデータウェアハウスで、大規模な構造化データの分析（OLAP）と BI に使います。複雑な JOIN、多数の分析者による同時利用、定期レポート → Redshift。負荷が不規則でクラスターを管理したくない → Redshift Serverless。
Redshift Spectrum は、Redshift にロードせずに S3 上のデータをクエリします。ホットデータは Redshift に置き、過去データは安価な S3 に置いたまま、1 つの SQL で JOIN できます。
Amazon EMR は、自分で構成する Hadoop / Spark / Hive / Presto クラスターを実行します。特定のビッグデータフレームワークやクラスターのカスタマイズが必要 → EMR。task node は HDFS データを持たないため、Spot でコストを下げられます。
Lake Formation は S3 上にデータレイクを構築し、列・行レベルまで権限を一元管理します。Athena / Redshift Spectrum / EMR 経由のクエリで「グループ A にはテーブルの一部の列だけを見せる」 → バケットポリシーではなく Lake Formation。
OpenSearch Service: 全文検索、ログ分析、ダッシュボード（OpenSearch Dashboards）。「商品カタログをキーワード検索」や「ダッシュボード付きでほぼリアルタイムにログ分析」 → OpenSearch。
Amazon Quick（旧 QuickSight）は BI ツールで、Athena、Redshift、S3、RDS などからダッシュボードを作成します。「ビジネスユーザー向けのサーバーレスなダッシュボード」 → Quick / QuickSight。

構成図

リアルタイムストリーム: Kinesis Data Streams と複数の consumer

複数のソースが 1 つのストリームに書き込みます。各 consumer は独立して自分のペースで読み取ります。Lambda はバッチ単位で処理し、Flink は時間ウィンドウで集計し、Firehose は生データを S3 に保存します。

ステップ

ソースはパーティションキー付きでレコードを書き込みます。同じキーは同じシャードに入り、順序が保たれます。
3 つの consumer が同じストリームを独立して読み取ります。失敗した consumer は、保持期間内なら元の位置から再読み取りできます。
Lambda は結果を DynamoDB に書き込み、Firehose はバッファリングして生データを S3 に保存します。

Firehose: ログを Parquet で S3 に送り、Athena でクエリ

管理するサーバーはありません。Firehose はバッファリングし、必要に応じて Lambda で変換し、Glue Data Catalog のスキーマに従って Parquet に変換して、日付プレフィックス付きで S3 に書き込みます。

ステップ

アプリがログを Firehose に送ります。
Firehose が Lambda を呼び出してデータをクレンジングし、Glue Data Catalog のスキーマで Parquet に変換します。
バッファのサイズまたは時間に達すると、S3 に 1 ファイルを書き込みます。
Athena が SQL でクエリし、必要な列だけを読み取ります。

パーティションキーがシャードを決める: ホットシャードを避ける

Kinesis はパーティションキーをハッシュしてシャードを選びます。1 つのキーがトラフィックの大半を占めると、他のシャードが空いていても、そのシャードの書き込みが 1 MB/s を超えます。

ステップ

値の種類が多いキー（例: user ID）なら、負荷がシャードに均等に分散します。
固定の 1 つのキーはすべて 1 つのシャードに集中します。1 MB/s または 1,000 レコード/s を超えると ProvisionedThroughputExceeded になります。
対処法: より分散するパーティションキーにする、シャードを追加する、または on-demand に切り替える。

S3 上のデータレイク: Glue Data Catalog と Lake Formation

データは raw → processed → curated の各ゾーンを流れます。crawler が Data Catalog を更新し、Lake Formation が Athena、Redshift Spectrum、EMR に対して列・行レベルの権限を付与します。

ステップ

Glue job が生データをクレンジングし、パーティション分割した Parquet に書き出します。
crawler が S3 をスキャンし、Data Catalog にテーブルとパーティションを作成 / 更新します。
Athena、Redshift Spectrum、EMR は Data Catalog からスキーマを読み取ります。Lake Formation が、誰がどのテーブル / 列 / 行を見られるかを決めます。

Athena は WHERE にあるパーティションだけをスキャン

テーブルは日付（dt=…）で分割されています。WHERE dt = '2026-10-16' を指定したクエリは、その日のディレクトリだけを読み取ります。Parquet も併用すれば、必要な列だけを読み取ります。

ステップ

クエリはパーティション列 dt で絞り込みます。
Athena は dt=2026-10-16 のディレクトリだけを読み取るため、スキャン量が少なく、費用も抑えられます。
他のパーティションは完全にスキップされます。

Redshift + Spectrum: ホットデータはクラスターに、過去データは S3 に

Redshift のテーブルには最近のデータがあり、外部テーブル（external table）は Glue Data Catalog 経由で S3 を指します。1 つの SQL で両方を JOIN できます。

ステップ

ダッシュボードは、Redshift 内のテーブルと外部テーブルを JOIN する 1 つの SQL を送ります。
外部テーブル部分は Spectrum が S3 上で直接並列処理し、スキーマは Data Catalog から取得します。クラスターにロードする必要はありません。

EMR クラスター: core node は On-Demand、task node は Spot

primary node が全体を調整します。core node はタスクを実行して HDFS を保持するため、安定している必要があります。task node は計算のみで、失ってもデータは失われないため、Spot に向いています。

ステップ

primary node が core node と task node に作業を割り振ります。
主要なデータは S3（EMRFS）に置きます。ジョブが終わればクラスターを停止しても、データは失われません。

OpenSearch によるニアリアルタイムのログ分析

アプリのログは Firehose 経由で OpenSearch に入り、検索とダッシュボード表示に使われます。全データのバックアップは安価な S3 に置きます。

ステップ

Firehose がログをまとめて OpenSearch にロードします。
OpenSearch Dashboards で全文検索とダッシュボード表示を行います。
Firehose がレコード（全件、またはエラーのレコードのみ）を S3 にバックアップします。

AWS Glue: crawler、Data Catalog、ETL job

crawler は生データを読み取ってスキーマを推定し、テーブル（パーティション含む）を Data Catalog に書き込みます。Glue ETL job（Spark）はソーステーブルを読み取り、Parquet 形式で S3 に書き出します。Athena と Redshift Spectrum は同じ Data Catalog を共有してクエリします。

ステップ

crawler が形式とスキーマを認識し、year=/month= 形式のディレクトリをパーティションにまとめて、テーブルを Data Catalog に書き込みます。
ETL job がクレンジングし、Parquet に変換してパーティション分割します。以降のクエリではスキャン量が減ります。
Athena と Redshift Spectrum は Data Catalog の同じテーブルを読み取るため、データをコピーする必要がありません。

Amazon EMR の 3 つの実行方式

同じ Spark / Hive ジョブを、EMR on EC2（マシンを自分で選び、構成は自由）、EMR on EKS（既存の Kubernetes クラスターを共有）、EMR Serverless（クラスター管理不要、worker が自動スケール）のいずれでも実行できます。

ステップ

EMR on EC2: マシンの種類、HDFS、Spot の task node を選び、アプリを追加インストールできます。クラスターは自分で運用します。
EMR on EKS: 他のアプリと共有する EKS クラスター上で Spark を実行します。
EMR Serverless: ジョブを送信すれば実行され、worker はジョブに応じて自動で増減します。

バッチパイプライン: S3 → Glue → Redshift → ダッシュボード

生データは S3 に入り、毎晩 Glue が Parquet にクレンジングし、Redshift が COPY でロードし（または Spectrum で直接読み取り）、Amazon Quick がビジネスユーザー向けのダッシュボードを描画します。

ステップ

スケジュールが毎晩 Glue job を起動し、生データをクレンジングして Parquet を書き出します。
Redshift が COPY でクレンジング済みのデータをロードします。
ダッシュボードが Redshift にクエリし、ビジネスユーザーは SQL を書かずに閲覧できます。

データ分析サービスの選び方

2 つのグループに分けて考えます。数秒で処理が必要なストリームデータと、すでにウェアハウスや S3 にあるクエリ対象のデータです。Managed Service for Apache Flink は Kinesis Data Analytics の現在の名称です。

ステップ

アプリログを数分おきに S3 へ送り、consumer は書かない場合: Firehose。
S3 の過去ログにときどき SQL でクエリする場合: Athena。

比較表

Kinesis Data Streams、Firehose、MSK

	Kinesis Data Streams	Amazon Data Firehose	Amazon MSK
レイテンシー	リアルタイム（ミリ秒）	ニアリアルタイム（バッファリングあり）	リアルタイム
データの読み手	自作の consumer（Lambda、KCL、Flink など）	Firehose が宛先へ自動で書き込み	Kafka consumer
過去データの再読み取り	可（保持期間内: 24 時間～365 日）	不可	可（Kafka の retention 設定による）
キャパシティ管理	シャード（provisioned）または on-demand	自動スケール	broker / serverless モード
向いている用途	複数の consumer、カスタム処理	S3 / Redshift / OpenSearch へのデータ投入	すでに Kafka を使っているシステム

クエリ・分析ツールの選び方

	Athena	Redshift	EMR	OpenSearch
種類	S3 上のサーバーレス SQL	データウェアハウス	Hadoop / Spark クラスター	検索とログ分析
データの置き場所	S3	Redshift のテーブル（+ Spectrum 経由で S3）	S3（EMRFS）または HDFS	OpenSearch の index
課金	スキャンしたデータ量	node 単位、または Redshift Serverless	クラスターの EC2 + EMR 料金	node 単位 / serverless
使う場面	アドホックなクエリ、インフラを持ちたくない	BI、大規模な JOIN、多数の同時ユーザー	カスタムのビッグデータジョブ、複数フレームワーク	全文検索、ログ、ダッシュボード

Athena を安く、速くする

方法	理由
列指向形式 Parquet / ORC	クエリに必要な列だけを読み取る
圧縮（Snappy、GZIP など）	スキャンするバイト数が減る
パーティション分割（例: year/month/day）	WHERE でパーティションを指定すると、そのディレクトリだけをスキャン
小さなファイルを大きなファイルに統合	S3 へのリクエストが減り、読み取りが効率的になる
workgroup でスキャン量を制限	スキャンしすぎるクエリを防ぐ

Glue、Lake Formation、EMR: 役割分担

サービス	データレイクでの役割
Glue Data Catalog	共有のテーブル / スキーマカタログ
Glue crawler	S3 をスキャンし、Data Catalog にテーブルを自動作成 / 更新
Glue job	サーバーレス ETL（Spark、Python）
Lake Formation	データベース / テーブル / 列 / 行単位の権限を一元管理
EMR	Glue では足りないときのカスタムビッグデータクラスター

よく出る出題パターン

1クリックストリームデータを 3 つの別々のアプリで独立して処理する必要があり、処理エラーが起きたときは 7 日前のデータを再読み取りできなければなりません。

答えを見る

正解: Kinesis Data Streams でデータ保持期間を 7 日に延ばし、各アプリを 1 つの consumer にする
複数の consumer が同じストリームを読み、保持期間内なら位置を指定して再読み取りできます。

不正解: Amazon Data Firehose
Firehose は宛先に直接書き込むだけで、カスタムの consumer も再読み取りもできません。

不正解: 1 つの SQS キュー
メッセージは読み取ると削除されます。複数のアプリが読むなら複数のキューが必要で、リプレイもできません。

2アプリケーションログを Parquet 形式で S3 に送り、Athena でクエリしたい。運用負荷は最小にします。

答えを見る

正解: Parquet への形式変換を有効にした Amazon Data Firehose（宛先は S3）
Firehose がバッファリング、形式変換、S3 への書き込みを自動で行い、サーバーは不要です。

不正解: Kinesis Data Streams + Parquet に変換する自作 consumer
動作はしますが、consumer を自作して運用する必要があります。

不正解: EC2 で毎時ログをまとめるスクリプトを実行する
マシンを自分で管理する必要があり、耐障害性も低くなります。

3運用チームが、S3 にある ALB ログに対してときどき SQL を実行する必要があります。インフラは構築したくありません。

答えを見る

正解: S3 のログディレクトリを指すテーブルを使った Athena
サーバーレスで、スキャンしたデータ量に応じた課金です。データのロードも不要です。

不正解: Redshift クラスターを構築してログをロードする
たまにしか使わないのに、クラスターを常時稼働させる費用がかかります。

不正解: EMR クラスター
クラスターを作成して管理する必要があります。

4Athena の請求額が急増しました。データは大きな CSV ファイルで、クエリは日付で絞り込むことが多い。

答えを見る

正解: データを圧縮した Parquet に変換し、日付でパーティション分割する
Athena はスキャン量で課金されます。列指向形式 + 圧縮 + パーティションでスキャン量を大幅に減らせます。

不正解: 安くするために Redshift に切り替える
スキャンしすぎるという根本原因を解決せず、クラスターの費用も加わります。

5数百人のアナリストが、数十 TB の構造化された売上データに対して、多数の JOIN を含む BI レポートを実行します。

答えを見る

正解: Amazon Redshift
列指向のデータウェアハウスで、クエリを並列化でき、OLAP / BI 向けです。

不正解: RDS for PostgreSQL
OLTP データベースで、TB 規模の分析や多数の同時ユーザーには向きません。

不正解: DynamoDB
NoSQL のキーバリューストアで、JOIN をサポートしません。

6直近 3 か月のデータは Redshift に、過去 5 年分は S3 にあります。Redshift に保存するコストをかけずに、両方を合わせたレポートがときどき必要です。

答えを見る

正解: Redshift Spectrum: S3 を指す外部テーブルを作り、Redshift 内のテーブルと JOIN する
ロードせずに S3 のデータをクエリできます。

不正解: 5 年分すべてを Redshift にロードする
あまり使われないデータのために容量とコストがかかります。

7既存の Spark、Hive、HBase のジョブを実行し、バージョンやクラスター構成をカスタマイズし、コンピュートコストも下げたい。

答えを見る

正解: Amazon EMR、データは S3 に置き、task node は Spot で実行する
EMR ではフレームワークと構成を選べます。task node は HDFS データを持たないため、Spot を安全に使えます。

不正解: AWS Glue
Glue はサーバーレスの Spark / Python ETL を実行するもので、Hive / HBase は動かせず、クラスターのカスタマイズも限られます。

不正解: Athena
S3 上の SQL だけです。

8S3 上のデータレイクで、マーケティングチームには Athena でのクエリ時に、顧客テーブルの一部の列だけを見せたい。

答えを見る

正解: Lake Formation でマーケティングチームに列レベルの権限を付与する
権限を一元管理でき、Athena、Redshift Spectrum、EMR に適用されます。

不正解: プレフィックス単位でブロックするバケットポリシー
バケットポリシーで制御できるのはオブジェクト単位までで、列単位はできません。

不正解: 一部の列を除いたデータのコピーを作る
データが重複し、同期も困難になります。

9毎日 S3 に新しいデータが入り、スキーマが変わることもあります。クエリ用のテーブルは常に最新にしておきたい。

答えを見る

正解: スケジュール実行の Glue crawler で Glue Data Catalog を更新する
crawler が新しいスキーマとパーティションを自動で推定します。

不正解: 毎回テーブルの DDL を手作業で修正する
忘れやすく、間違いも起きやすくなります。

10EC サイトで、候補表示と結果のランキング付きで、キーワードによる商品検索ボックスが必要です。

答えを見る

正解: Amazon OpenSearch Service
全文検索と、関連度によるランキングができます。

不正解: Athena
S3 に対するバッチクエリ用で、低レイテンシーの対話型検索には向きません。

不正解: DynamoDB の Scan
全文検索がなく、Scan は遅くてコストもかかります。

11Kinesis Data Streams に書き込むアプリが、全体のトラフィックがシャードの合計容量より少ないのに ProvisionedThroughputExceeded になります。

答えを見る

正解: 値の種類が多いパーティションキーを選んで均等に分散させる、または on-demand モードを使う
「ホット」なパーティションキーが 1 つのシャードに集中し、他のシャードが空いていても処理しきれなくなります。

不正解: SQS に切り替える
ストリームの特性（順序、複数の consumer、リプレイ）が失われます。

早見表

データはどこへ送り、どう処理するか

やりたいこと	使うもの
リアルタイムのストリーム、複数の consumer、再読み取り可能	Kinesis Data Streams · 図を見る
consumer を書かずに S3 / Redshift / OpenSearch へストリームを投入	Amazon Data Firehose · 図を見る
すでに Apache Kafka を使っている	Amazon MSK
時間ウィンドウでのストリーム分析	Managed Service for Apache Flink · 図を見る
インフラなしで S3 に対するアドホック SQL	Athena（+ Parquet、パーティション） · 図を見る
スキーマカタログ、サーバーレス ETL	AWS Glue（Data Catalog、crawler、job） · 図を見る
大規模な構造化データの BI / OLAP	Amazon Redshift（または Redshift Serverless） · 図を見る
Redshift のデータと S3 の過去データを JOIN	Redshift Spectrum · 図を見る
カスタムの Hadoop / Spark / Hive	Amazon EMR（task node は Spot） · 図を見る
データレイクの列 / 行レベルの権限管理	Lake Formation · 図を見る
全文検索、ダッシュボード付きのログ分析	OpenSearch Service · 図を見る
ビジネスユーザー向けの BI ダッシュボード	Amazon Quick（QuickSight） · 図を見る

落とし穴

複数のカスタム consumer や再読み取りが必要なのに Firehose を選ぶ（正解は Kinesis Data Streams）。
Firehose をリアルタイムだと考える（データはバッファリングされるため、ニアリアルタイムです）。
すでに Kafka を使っているのに Kinesis を選ぶ（正解は MSK）。
値の種類が少ないパーティションキーを使う（1 つのシャードが過負荷になり、他は空いたまま）。
圧縮なし・パーティションなしの CSV を Athena にスキャンさせて、請求額が高いと嘆く。
S3 に対するたまのクエリのために Redshift を構築する（Athena の方が安価でシンプルです）。
Spectrum が S3 から直接読めるのに、過去データをすべて Redshift にロードする。
EMR の core node を Spot で動かす（core node は HDFS データを持つため、node を失うとデータも失います。Spot は task node 向きです）。
列単位の権限管理にバケットポリシーを使う（不可能で、Lake Formation が必要です）。
商品検索ボックスに Athena や DynamoDB を使う（全文検索は OpenSearch の役割です）。
大量データの分析レポートという問いに、RDS（OLTP）と Redshift（OLAP）を取り違える。

このモジュールのサービス

変わりやすい数値 (AWS ドキュメントで確認済み)

Kinesis Data Streams（provisioned）: 1 シャードあたり、書き込み最大 1 MB/s または 1,000 レコード/s、読み取り最大 2 MB/s。 2026-10-16 確認 ↗
Kinesis Data Streams のデータ保持期間は最低 24 時間で、最大 8,760 時間（365 日）まで延長できます。 2026-10-16 確認 ↗
Kinesis Data Streams on-demand: 新規ストリームの既定は書き込み 4 MB/s、読み取り 8 MB/s で、自動スケールします。 2026-10-16 確認 ↗
Firehose から S3 への書き込み: バッファは 1～128 MiB（既定 5）と 0～900 秒（既定 300）で、どちらか先に達した方で書き込みます。 2026-10-16 確認 ↗
Athena はスキャンしたデータ量で課金されます。料金ページの例は 1 TB あたり 5 USD です。圧縮と列指向形式（Parquet）でスキャン量を減らせます。 2026-10-16 確認 ↗
Athena: WHERE にパーティション列を指定すると、そのパーティションのデータだけをスキャンします。 2026-10-16 確認 ↗
Redshift Spectrum は Redshift のテーブルにロードせずに S3 のデータをクエリします。複数のクラスターが同じデータセットをクエリすることもできます。 2026-10-16 確認 ↗
Glue crawler はスキーマを推定し、テーブル（ディレクトリ単位のパーティションを含む）を Data Catalog に書き込みます。ETL job はこれらのテーブルをソースとターゲットに使います。 2026-10-19 確認 ↗
EMR Serverless はクラスター管理が不要な EMR のデプロイ方式で、worker が自動でスケールします。pre-initialized capacity を使うと、ジョブが数秒で起動します。 2026-10-19 確認 ↗
EMR on EKS は、オープンソースのビッグデータフレームワークを Amazon EKS クラスター上で実行し、他のコンテナアプリケーションとクラスターを共有できます。 2026-10-19 確認 ↗

このモジュールの問題を解く →