Instiq
第1章 · データの取り込みと変換·v2.1.0·更新 2026/6/14·読了目安 約9分

変更要約: in-scope サービス網羅: 取り込み・移行(AppFlow/Data Exchange/API Gateway/DataSync/Transfer Family/MGN/Discovery/Snow Family)を追加

1.2AWS Glue による ETL とデータカタログ

この節の要点

AWS Glue のクローラとデータカタログ（スキーマ推論・中央メタデータ）、サーバーレス Spark の ETL ジョブ、ETL と ELT の違いを理解します。

取り込んだ生データは、分析しやすい形へ変換（Transform）します。AWS のサーバーレス ETL の中核が AWS Glue です。

1.2.1クローラ・カタログ・ETL ジョブ

ソース（S3/RDS/ストリーム）→Glue クローラ（スキーマ推論→データカタログ＝中央メタデータ）→Glue ETL ジョブ（サーバーレス Spark で変換/クレンジング）→ターゲット（S3/Redshift）という ETL の流れを示した図。
AWS Glue の ETL パイプライン
  • クローラ：ソースを走査してスキーマを推論し、データカタログに登録する。
  • データカタログ：テーブル定義などの中央メタデータ。Athena/Redshift Spectrum/EMR から共有参照できる。
  • Glue ETL ジョブ：サーバーレス Spark で変換・クレンジングを実行する（使った分だけ課金）。
  • ETL と ELT：ETL は読み込み前に変換、ELT は格納後に（DWH 内で）変換する。
試験ポイント

「スキーマ推論＋中央メタデータ＝Glue データカタログ（クローラ）」「サーバーレスな ETL＝Glue ジョブ」「Athena は Glue カタログを参照」 は DEA で頻出です。大規模なカスタム分散処理は EMR も選択肢です。

AWS Glue はサーバーレス ETL の中核で、構成要素を押さえます。クローラ がソースを走査してスキーマを推論し、テーブル定義を データカタログ（中央メタデータ・Athena/Redshift Spectrum/EMR が共有）へ登録します。Glue ETL ジョブ は サーバーレス Spark（または Python シェル）で変換・クレンジングを実行し、コードを書かずに作れる Glue Studio、データ品質を検証する Glue Data Quality、対話分析の インタラクティブセッション も備えます。コストと性能の鍵は出力形式とレイアウトで、列指向（Parquet/ORC）へ変換し、よく絞り込む列で パーティション分割、小さなファイルは 圧縮・コンパクションしてまとめると、後段の Athena（スキャン量課金）や Redshift のコストが大きく下がります。重複実行を防ぐ ジョブブックマーク（処理済みデータの記録）も重要です。「変換してから格納＝ETL」「まず格納し DWH 内で変換＝ELT」を要件で選び分け、超大規模なカスタム分散処理が要るなら EMR を検討します。

役割Glue の機能
スキーマ推論＋中央メタデータクローラ → データカタログ
サーバーレスな変換/クレンジングETL ジョブ（Spark）
処理済みデータの重複防止ジョブブックマーク
後段のスキャン量/コスト削減Parquet＋パーティション＋圧縮
例

シナリオ：S3 の生 JSON ログを Athena で安く分析したい。 Glue クローラでスキーマを データカタログに登録 → Glue ETL ジョブで Parquet へ変換し日付で パーティション分割 → Athena が Glue カタログを参照してクエリ。スキャン量が激減しコストが下がります。増分は ジョブブックマークで二重処理を防止します。

補足

Q. スキーマ推論と中央メタデータ？ クローラ＋データカタログ。Q. サーバーレスな変換？ Glue ETL ジョブ（Spark）。Q. Athena のコストを下げる？ Parquet＋パーティション。Q. 二重処理を防ぐ？ ジョブブックマーク。Q. ETL と ELT は？ 変換が先か（ETL）格納が先か（ELT）。

注意

混同に注意：
①クローラは「メタデータ登録」、ETL ジョブは「実データ変換」——役割を取り違えない。
②行指向 CSV のままだと Athena のスキャン量（＝課金）が膨らむ——Parquet＋パーティションが定石。
③小さなファイルが大量にあると性能・コストが悪化（コンパクション）。
④Glue カタログは Athena/Redshift Spectrum/EMR で共有——重複定義を作らない。

コツ

列指向フォーマット（Parquet/ORC）へ変換し、パーティション分割しておくと、後段の Athena/Redshift のスキャン量とコストを大幅に減らせます。

1.2.2この節のまとめ

  • クローラ→データカタログ（メタデータ）→Glue ETL（Spark）
  • Parquet＋パーティションで後段のコスト削減

進捗の記録にはログインが必要です。

理解度チェック

（軽い確認用）

Q1. データソースを走査してスキーマを推論し、中央のメタデータに登録する AWS Glue の機能はどれですか？

Q2. サーバーレスでデータの変換・クレンジングを実行したい。最も適した AWS Glue の機能はどれですか？

Q3. 後段の Athena/Redshift のスキャン量とコストを減らすデータ整形として最も効果的なのはどれですか？

理解度を確認第1章「データの取り込みと変換」の問題を解く