バッチ取り込みの設定

バッチ取り込みは、ある期間にたまったデータをまとめて読み取り、やへ入れる処理です。ストリーミングより仕組みは単純ですが、「前回の続きから読む (増分)」「どれくらいの頻度で読むか」「どの大きさのファイルにするか」の設定を誤ると、二重取り込みや取りこぼし、遅いクエリの原因になります。

Point

増分 (incremental) 取り込みは、前回から増えた・変わった分だけを読むことです。毎回全部を読むのは全量 (full) 取り込みです。
ブックマーク (bookmark) は、本のしおりのように「どこまで読んだか」を覚える仕組みです。
和訳
- Incremental: 増分の
- Weblio英和辞書「incremental」

概要

ソース	主な読み取り方法
	ジョブ、、 ()、 (小さなファイル)、の
/ などの	Glue ジョブ ()、の全ロード、RDS のの S3 エクスポート
Amazon Redshift	で S3 へ書き出す、Glue の Redshift コネクタ、Redshift Data
(Salesforce など)	、Glue の SaaS コネクタ
ファイル転送	(SFTP)、

試験では、どのサービスで読むかに加え、増分の方法、実行の頻度、ファイルサイズを判断します。

主要技術

①ソースごとの読み取り方法 ⚠️ 頻出

要件	選ぶ方法
の CSV/ を整形してで書き直す	ジョブ ()
数 TB 規模を既存の Spark/Hive のコードで処理	(EMR Serverless)
小さなファイルが届くたびに軽く処理	(S3 イベントで起動)
S3 のデータをで変換して別のテーブルに	の / INSERT INTO
のテーブルを定期的に読む	Glue ジョブ ( 接続)
RDB を一度に全部移す	の全ロード
のデータを S3 へ出してと共有	(Parquet、パーティション指定)
のデータをノーコードで定期取得

Glue の JDBC 読み取りは、既定では1本の接続で読むため、大きなテーブルでは遅くなります。hashfield / hashpartitions のオプションで列の値ごとに分割し、並列に読むと速くなります。ソースの DB に負荷をかけたくない場合は、から読みます。

②増分取り込み ⚠️ 頻出

方法	仕組み	注意点
の	前回の実行でどこまで処理したかを Glue が記録する。はオブジェクトの最終更新時刻、はブックマークキー (既定は主キー) で判断	スクリプトの transformation_ctx と job.commit() が必要。JDBC のキーは単調に増える (または減る) 列にする
最終更新日時の列で絞る	`WHERE updated_at > 前回の実行時刻` で読む	削除は検出できない。時刻の記録を自分で管理する
パーティションで絞る	`dt=2026-10-17` のように日付のパーティションだけを読む ()	パーティション設計が前提
	トランザクションログから変更を取り出す ()	削除も検出できる。ストリーミングに近い

ジョブブックマークは、有効 (Enable)、無効 (Disable、既定)、一時停止 (Pause) を選べます。過去の実行の時点まで巻き戻す (rewind) か、リセットすると再処理できます。ただし、巻き戻してもターゲットに書いたファイルは消えないため、二重書き込みにならないよう出力先を分けるか、上書きの書き込みにします。

S3 の入力では、既に処理したファイルを書き換えると最終更新時刻が変わり、再び処理されます。

⚠️ 頻出: 「毎日のジョブで、前日までに処理した S3 のファイルを再処理したくない。コードの変更は最小」は Glue のジョブブックマークです。

③取り込みの頻度とバッチ間隔

判断材料	考え方
必要な鮮度	レポートが朝に必要なら夜間に1回。1時間ごとの更新が必要なら毎時
ソースの負荷	業務時間を避ける。やのエクスポートから読む
データの到着	ファイルが届いたら処理するなら ( イベント、)
コスト	頻度を上げるほど起動の回数とオーバーヘッドが増える。も増える

時刻で動かすスケジュールは EventBridge Scheduler、のトリガー、ので設定します。ファイルの到着で動かすなら S3 のイベント通知や EventBridge のルールを使います (「Amazon EventBridge (スケジュールとイベント駆動)」の章)。

④ファイルサイズと小さいファイル問題 ⚠️ 頻出

上の数 KB のファイルが大量にあると、、、はファイルを開くたびにオーバーヘッドがかかり、クエリやジョブが遅くなります。S3 へのリクエストの料金も増えます。

原因	対処
ストリーミングで短い間隔ごとに書き出す	のバッファを大きくする
の出力のパーティション数が多すぎる	coalesce / repartition で出力ファイル数を減らす
入力に小さなファイルが大量にある	Glue の groupFiles / groupSize で読み取りをまとめる
既にできた	定期的な (結合) のジョブ。やの自動コンパクション

Athena のチューニングの指針では、多数の小さいファイルより少数の大きいファイルの方が速く、特に列指向の形式では小さいファイルだと形式のオーバーヘッドが利点を上回るとされています。ファイルが極端に多いと、S3 のプレフィックスあたりのリクエストの上限 (GET は毎秒 5,500 件) に達し、SlowDown エラーになることもあります。いちばんよいのは、書き込む段階で大きなファイルにすることです。

⑤S3 へのアップロードの設定

設定	内容
マルチパートアップロード	大きなファイルを分割して並列に送る。1回の PUT は最大 5 GB までなので、それを超えるオブジェクトでは必須。100 MB 程度を超えたら使うことが推奨されている
Transfer Acceleration	遠く離れた拠点からのアップロードを、経由で速くする
受け口のプレフィックス設計	`landing/source=crm/dt=2026-10-17/` のように、ソースと日付で分ける
完了の目印	全ファイルを置いた後に `_SUCCESS` などのファイルを置き、それをきっかけに処理を始める

マルチパートアップロードが途中で止まると、未完了のパーツが残って料金がかかります。ライフサイクルルールで未完了のマルチパートアップロードを削除します。

試験対策

①判断マトリクス

問題文のキーワード	選ぶ設定・方法
前回処理したファイルを再処理しない、コード変更最小	の
の新しい行だけを毎日読む	ブックマーク (単調増加のキー) または更新日時で絞る
削除も含めて取り込みたい	()
大きなテーブルの読み取りが遅い	hashfield / hashpartitions で並列読み取り、
が大量でクエリが遅い	ファイルの結合 ()、groupFiles、バッファを大きく
5 GB を超えるファイルをへ	マルチパートアップロード
海外の拠点から S3 へのアップロードが遅い	S3 Transfer Acceleration
のデータを S3 のへ	()
のデータをノーコードで定期取得
ファイルが届いたら処理を始める	S3 イベント通知 /

②よくある誤答

毎回全量を読み直して重複を後で消すこと。増分の仕組みを使います。
ブックマークを有効にしたのに transformation_ctx を付けず、増分にならないこと。
頻度を上げれば鮮度もコストも良くなると考えること。とオーバーヘッドが増えます。
ブックマークを巻き戻せばターゲットの古い出力も消えると考えること。出力は自分で管理します。