変更データキャプチャ (CDC) と zero-ETL

(CDC) は、データベースで起きた挿入・更新・削除を、起きた順に取り出して別の場所へ伝える仕組みです。毎回テーブル全体をコピーする代わりに変更分だけを運ぶため、分析側のデータを新しく保ちつつ、ソースのデータベースへの負荷を抑えられます。統合は、この CDC のパイプラインを AWS が丸ごと管理する仕組みです。

Point

CDC = Change Data Capture (変更データキャプチャ) の略です。
zero-ETL は「ETL のパイプラインを自分で作らなくてよい」という意味で、変換が一切ないという意味ではありません。
upsert は update と insert を合わせた言葉で、「あれば更新、なければ挿入」です。
和訳
- Capture: 捕らえる、記録する
- Weblio英和辞書「capture」

概要

方式	ソース	運ぶ先	決め手
Streams	DynamoDB	など	項目の変更をすぐに Lambda で処理
for DynamoDB	DynamoDB	Kinesis Data Streams	長い保持、多数のコンシューマー、やとの連携
の	、、や上の DB など	、Kinesis、、他の DB	多様なソース、変換や移行と組み合わせる
統合	Aurora、RDS、DynamoDB、一部のなど	Amazon Redshift など	パイプラインを作らず、運用最小でほぼリアルタイム

主要技術

①DynamoDB Streams と Kinesis Data Streams for DynamoDB ⚠️ 頻出

観点	Streams	for DynamoDB
保持期間	24 時間	最大 1 年 (Kinesis の保持期間)
同時に読めるコンシューマー	あたり2つまで	シャードあたり5つ、で20まで
順序	項目ごとに変更の順序どおり	レコードのタイムスタンプで実際の順序を判断する
重複	重複レコードは出ない	まれに重複することがある
処理の方法	、DynamoDB Streams Kinesis Adapter	Lambda、、、ストリーミング
料金	読み取りの料金 (Lambda のトリガーは読み取り料金なし)	Kinesis Data Streams の料金

DynamoDB Streams のストリームレコードに含める内容 (ビューの種類) は、KEYS_ONLY (キーだけ)、NEW_IMAGE (変更後)、OLD_IMAGE (変更前)、NEW_AND_OLD_IMAGES (両方) から選びます。差分の計算や監査が目的なら NEW_AND_OLD_IMAGES です。

同じテーブルで両方を同時に有効にできます。

⚠️ 頻出: 「DynamoDB の変更を、Lambda で1件ずつすぐに処理」は DynamoDB Streams、「変更を多数の処理系で読む、24 時間を超えて保持、Firehose でへ」は Kinesis Data Streams for DynamoDB です。

②AWS DMS による CDC

は、ソースのデータベースのトランザクションログ (MySQL のバイナリログ、PostgreSQL の WAL、Oracle の REDO ログなど) を読んで変更を取り出します。テーブルへ問い合わせて差分を探すのではないため、ソースへの負荷が小さく、削除も取り出せます。

タスクの種類	内容
全ロード	既存のデータを一度に全部移す
全ロード +	全部移した後、進行中の変更を続けて反映する (最もよく使う)
CDC のみ	変更だけを流す (初期データは別の方法で用意済み)

ターゲットをにすると、変更はや CSV のファイルとして書き出され、各行に操作の種類 (I/U/D) の列が付きます。ターゲットをにすると、変更をストリームとして他の処理系へ配れます。DMS の詳細は「AWS DMS」の章で扱います。

③zero-ETL 統合 ⚠️ 頻出

統合は、ソースからへの複製を AWS が自動で作成・管理する仕組みです。最初に全データをロードし、その後は変更をほぼリアルタイムに反映します。

対応するソース (Redshift への統合)	補足
MySQL、Aurora PostgreSQL	運用 DB の分析の代表例
for MySQL、RDS for PostgreSQL、RDS for Oracle	—
	テーブルの複製。DynamoDB の読み取り容量を消費しない (エクスポートの仕組みを使う)
アプリケーション (Salesforce、SAP、ServiceNow、Zendesk など)	の zero-ETL 統合
セルフマネージドの MySQL、PostgreSQL、 Server、Oracle	—

機能	内容
複製先	Redshift のプロビジョンドクラスター、Redshift Serverless
履歴モード	変更前の行も残し、いつどう変わったかを追える ( タイプ2 のような履歴)
監視	Redshift のシステムビュー、の統合イベント
複製後の加工	Redshift のや SQL で変換 ()

zero-ETL では、ソースとターゲットの間で複雑な変換はできません。変換が必要なら、Redshift に入った後で SQL で行うか、や Glue でパイプラインを作ります。

⚠️ 頻出: 「Aurora の取引データを Redshift でほぼリアルタイムに分析したい。パイプラインの構築と運用を最小にしたい」は zero-ETL 統合です。DMS や Glue のジョブを自分で組む選択肢は、運用負荷の点で劣ります。

④CDC を適用する (MERGE と upsert)

取り出した変更を分析側のテーブルへ反映するには、挿入・更新・削除を正しく適用します。

適用先	方法
	変更をステージングテーブルへし、 (または DELETE + INSERT) で本体へ反映
上のテーブル	()、、の MERGE INTO で行単位に upsert・削除
	主キーで PutItem (上書き) し、削除は DeleteItem

同じ行に複数の変更が届いた場合は、タイムスタンプやシーケンス番号で最新の変更だけを残してから適用します。適用処理は、同じ変更を2回適用しても結果が変わらない () ように作ります。

従来の Hive 形式のテーブル (S3 上のファイルの集まり) は行単位の更新・削除ができず、ファイルを丸ごと書き直す必要があります。を S3 のに頻繁に反映するなら、Apache Iceberg などのを使います。

⑤複数のソースからデータを統合する

やバッチで集めたデータを1か所で結合すると、顧客 360 度のような横断的な分析ができます。

方法	内容	向くケース
ジョブで結合	複数のソース (、、) を読み、結合して S3 やへ書く	定期的なバッチの統合、複雑な変換
Redshift へ集約	やで複数のソースを Redshift に集め、で結合	SQL で分析する、
・	S3 や / のデータを動かさずに Redshift から結合	データの移動を減らしたい
のフェデレーテッドクエリ	コネクタで DynamoDB や RDS などを S3 のデータと結合	アドホックな横断分析

統合では、キーの名前や型、コード値 (例: 国コード) をそろえ、重複を除く処理が必要です。

試験対策

①判断マトリクス

問題文のキーワード	選ぶ方式
の変更でを起動	DynamoDB Streams
DynamoDB の変更を 24 時間超保持、多数のコンシューマー	for DynamoDB
変更前と変更後の値を両方	NEW_AND_OLD_IMAGES
の DB の変更を継続的に AWS へ	(全ロード + )
//DynamoDB をで分析、パイプライン不要	統合
Redshift で変更の履歴も残したい	zero-ETL の履歴モード
変更を Redshift のテーブルへ反映	ステージングテーブル +
変更をのに行単位で反映	+ MERGE INTO
複数のソースを結合して分析用データを作る	ジョブ、または Redshift に集めて

②よくある誤答

毎回テーブル全体をエクスポートして差分を探すこと。ソースの負荷が大きく、削除も検出しにくいため、を使います。
Streams に 24 時間を超える保持を期待すること。
で複雑な変換まで済ませられると考えること。変換はに入った後ので行います。
だけのに CDC の更新・削除をそのまま反映しようとすること。などのテーブル形式を使います。