Amazon Redshift

は、大量の構造化・半をで高速に集計するです。列指向の格納と、複数のノードで分担して処理する (超並列処理) で、数十億行の集計を短時間で返します。DEA-C01 では、プロビジョンドクラスターと Redshift Serverless の選び方、・・圧縮によるテーブル設計、とによるワークロード管理、と ANALYZE による保守が問われます。

Point

MPP = Massively Parallel Processing (超並列処理) です。データをノードとスライスに分けて置き、各スライスが同時に処理します。
WLM = Workload Management (ワークロード管理) です。クエリをキューに分け、メモリと同時実行数を配分します。
RMS = Redshift Managed Storage (マネージドストレージ) です。RA3・RG ノードと Serverless が使うストレージで、コンピューティングと別に伸縮・課金されます。

概要

は、クライアントやツールからの問い合わせをリーダーノードが受け、実行計画を作ってコンピューティングノードに配ります。

提供形態	容量の単位	課金	向くワークロード
プロビジョンドクラスター (RA3・RG)	ノードの種類と数	ノード時間 (一時停止中はストレージのみ)、リザーブドノードで割引	負荷が予測でき、常に動く定型の処理
Redshift Serverless	(1 RPU = メモリ 16 GB)	使った RPU 時間 (秒単位) + ストレージ	負荷が不定期・急増する、容量管理をしたくない

試験では、「容量管理をしたくない」「負荷が読めない」なら Serverless、「常時高負荷で予測できる」ならプロビジョンド (リザーブドノード) を選びます。

主要技術

①ノードタイプと Redshift Serverless ⚠️ 頻出

プロビジョンドクラスターでは、RG または RA3 ノードが推奨です。どちらもマネージドストレージを使い、コンピューティングとストレージを別々に伸ばせます。RG は Graviton ベースのノードで、への問い合わせを自分のクラスターのコンピューティングで処理するエンジンを持ちます (RA3 はを使います)。ローカルだけで保管する DC2 は、圧縮後 1 TB 未満の小さなデータ向けです。

Serverless は、名前空間 (データベース、ユーザー、権限などの保管側) とワークグループ (コンピューティング側) で構成します。

設定	内容
ベース容量	クエリに使う基本の。既定は128 RPU で、4 RPU から設定できる (最大は512、一部のでは1024)
最大容量	自動で伸びる RPU の上限。コストの上限として使う
使用量の上限 (RPU 時間)	日・週・月の使用量の上限。超えたらアラートやユーザークエリの停止を選べる
価格性能の目標 (AI 駆動のスケーリングと最適化)	「コスト重視」から「性能重視」までの目標を選ぶと、ワークロードを学習して RPU を自動で調整する。新しいワークグループは「バランス」が既定

ベース容量を大きくすると、複雑なクエリや列の多いテーブル、結合の多いクエリが速くなりますが、費用も増えます。

②分散スタイル ⚠️ 頻出

テーブルの行をどのノード (スライス) に置くかを決めます。結合や集計のときにノード間でデータを移す (再分散する) 量を減らすのが目的です。

	置き方	向くテーブル
AUTO (推奨の既定)	がテーブルの大きさと使われ方を見て選び、変える	迷ったらこれ
KEY	指定した列の値が同じ行を同じスライスに置く	大きなファクトテーブルと、よく結合する大きなディメンション。結合キーを分散キーにする
ALL	全ノードに全行のコピーを置く	小さく更新の少ないディメンションテーブル
EVEN	行を順番に均等に置く	結合に使わず、KEY の候補もないテーブル

分散キーに値の偏った列 (ほとんどの行が同じ値) を選ぶと、一部のスライスに行が集中し ()、そのスライスの処理が全体を遅らせます。カーディナリティが高く、均等に分かれる結合キーを選びます。

③ソートキーと圧縮エンコーディング

は、ディスク上の行の並び順です。はブロックごとに列の最小値と最大値 (ゾーンマップ) を持つため、ソート順に沿った範囲の絞り込みでは、関係のないブロックを読み飛ばせます。

種類	内容	向くケース
AUTO	Redshift が使われ方から選ぶ (自動テーブル最適化)	迷ったらこれ
複合ソートキー (COMPOUND)	列を指定した順に優先して並べる	先頭の列 (日付など) で絞り込むクエリが多い
インターリーブソートキー (INTERLEAVED)	複数の列を同じ重みで扱う	複数の列のどれでも同じくらい絞り込む。ロードとが重い

時系列のデータは、日付やタイムスタンプを複合ソートキーの先頭にするのが定石です。

圧縮エンコーディングは列ごとに設定し、ディスク I/O を減らします。CREATE TABLE で ENCODE AUTO (既定) にすると、Redshift が適切なエンコーディングを選びます。数値と日付には AZ64、文字列には ZSTD や LZO がよく選ばれます。

自動化の機能	内容
自動テーブル最適化 (ATO)	とソートキーを、クエリの履歴から自動で選び直す
ENCODE AUTO	圧縮エンコーディングを自動で選ぶ
自動 VACUUM DELETE / 自動 ANALYZE	負荷の低い時間に背景で実行する

④ワークロード管理 (WLM) と同時実行スケーリング ⚠️ 頻出

のロード、ダッシュボードの短いクエリ、アナリストの重いクエリが同時に走ると、互いに待たされます。で優先度と資源を分けます。

機能	内容	使いどころ
自動 WLM (推奨)	メモリと数をが自動で配分する。キューごとに優先度 (HIGHEST〜LOWEST) を付けられる	ダッシュボードを優先し、バッチを低くする
手動 WLM	キューごとのメモリと同時実行数を自分で決める	細かく固定したい特別な場合
ショートクエリアクセラレーション (SQA)	短いと予測したクエリを専用の領域で先に実行する	長いクエリの後ろで短いクエリが待たされる
クエリルール (QMR)	実行時間やスキャン行数などのしきい値で、ログ・別キューへの移動・中止を行う	暴走クエリから他の処理を守る
	同時実行のクエリが増えたとき、一時的なクラスターを自動で足して読み取りなどを処理する	月末や朝のダッシュボードで同時実行が急増する

同時実行スケーリングは、稼働しているクラスターごとに1日あたり1時間分の無料のクレジットがたまり、超えた分は秒単位で課金されます。急増が一時的なら、クラスターを大きくし続けるより安く済みます。

Point

SQA = Short Query Acceleration (ショートクエリアクセラレーション) です。
QMR = Query Monitoring Rules (クエリモニタリングルール) です。
「同時に実行するクエリが多くて待たされる」→ 同時実行スケーリング、「1本のクエリが遅い」→ テーブル設計 (分散・ソート) やノードの追加、と原因で分けて覚えます。

⑤VACUUM と ANALYZE

は、UPDATE と DELETE で行をすぐには消さず、削除の印を付けるだけです。また、新しくロードした行はソート済みの領域の後ろに追加されます。放っておくと、不要な行のスキャンとソートの崩れでクエリが遅くなります。

コマンド	内容
FULL (既定)	削除済みの行の領域を回収し、行を並べ直す
VACUUM DELETE ONLY	領域の回収だけ行う (ソートしない)
VACUUM SORT ONLY	並べ直しだけ行う
VACUUM REINDEX	インターリーブのテーブルを並べ直す
ANALYZE	列の統計を更新し、オプティマイザーがよい実行計画を作れるようにする

自動 VACUUM DELETE と自動 ANALYZE が背景で動きますが、大量のロードや削除の直後は、手動で VACUUM と ANALYZE を実行すると性能がすぐ戻ります。毎回全件を入れ替えるテーブルは、DELETE ではなく TRUNCATE を使うと VACUUM が要りません。

⑥半構造化データとその他の機能

機能	内容
による変換 ()	ロードした後に INSERT INTO … SELECT、、で変換する。手順はストアドプロシージャにまとめる
処理の自動化	クエリエディタ v2 のスケジュール ( Scheduler で定期実行)、やから Data で実行する
SUPER 型	などの半を1列に入れ、PartiQL でネストした値を問い合わせる
	集計結果を保存し、自動更新や増分更新で新しく保つ (「・・マテリアライズドビュー」の章)
Data API	接続を管理せずにで SQL を非同期に実行する。Lambda や Step Functions から呼び出しやすい
データ共有	データをコピーせず、他のクラスター・ワークグループ・アカウントへ読み取りを共有する (「Redshift のアクセス制御とデータ共有」の章)
Redshift ML	SQL からのモデルを作り、予測を行う
ユーザー定義関数 (UDF)	SQL UDF や Lambda UDF を使う。Python UDF は2026年6月30日でサポートが終わる

Redshift のロードとアンロードは「Redshift へのロードとアンロード」の章、ロックと同時書き込みは「ロックとの制御」の章、ユーザーやロールの権限、、は「Redshift のアクセス制御とデータ共有」の章で扱います。

試験対策

①判断マトリクス

問題文のキーワード	選ぶもの
負荷が不定期、容量管理をしたくない	Serverless
常時高負荷で予測できる、コストを下げたい	プロビジョンド (RA3・RG) + リザーブドノード
Serverless の費用が想定を超えないようにしたい	最大容量 () と使用量の上限
大きなテーブル同士の結合が遅い	結合キーを両方の (KEY) にする
小さなディメンションとの結合で再分散が起きる	ディメンションを ALL にする
一部のスライスだけ処理が長い	分散キーの偏り () を直す
日付の範囲で絞り込むクエリが遅い	日付を複合の先頭にする
朝のの急増で待たされる
短いクエリが長いクエリに待たされる	ショートクエリアクセラレーション、自動の優先度
暴走クエリを自動で止めたい	クエリルール
大量の DELETE の後に遅くなった	と ANALYZE
をそのまま入れて問い合わせたい	SUPER 型と PartiQL

②よくある誤答

の不足に、ノードを恒常的に増やして対応すること。急増が一時的ならの方が安くなります。
に、値の種類が少ない列や偏った列を選ぶこと。で遅くなります。
インターリーブを、先頭の列で絞り込むだけのテーブルに使うこと。複合ソートキーで足ります。
を、1行ずつ頻繁に更新する業務データベースとして使うこと。には / / を選びます。
毎回全件入れ替えるテーブルを DELETE で空にすること。TRUNCATE を使えばが要りません。