AWS Glue
サーバーレスでスケーラブルな ETL サービスで、データカタログによるメタデータ管理と Apache Spark ベースのジョブ実行基盤を統合的に提供する。
概要
AWS Glue は、データの抽出・変換・ロード (ETL) をサーバーレスで実行するフルマネージドサービスです。Glue Data Catalog がデータレイクやデータウェアハウスのメタデータを一元管理し、Athena、Redshift Spectrum、EMR などのクエリエンジンから共通のスキーマ定義として参照されます。Crawler がデータソースを自動スキャンしてスキーマを推論・登録するため、手動でのテーブル定義が不要になります。ジョブ実行基盤は Apache Spark と Python Shell の 2 種類を備え、大規模な分散処理から軽量なスクリプト実行まで幅広いワークロードに対応します。
Data Catalog と Crawler が変えるメタデータ管理
Glue の中核は Data Catalog です。S3 上の Parquet ファイル、RDS のテーブル、Redshift のスキーマなど、散在するデータソースのメタデータを一箇所に集約し、Hive Metastore 互換のインターフェースで公開します。Athena でクエリを書くとき、FROM 句に指定するテーブル定義は実質的に Data Catalog のエントリです。Crawler はデータソースを定期的にスキャンし、カラム名・データ型・パーティション構造を自動推論して Catalog に登録します。ただし推論精度は万能ではなく、CSV の先頭行がヘッダーかデータかを誤判定するケースや、数値と文字列が混在するカラムで型が揺れるケースがあります。実務では Crawler の初回実行後に推論結果を目視確認し、必要に応じて手動で型を修正するのが定石です。Classifier をカスタム定義すれば、独自フォーマットのファイルにも対応できます。Azure の対応サービスである Azure Data Factory も同様にメタデータ管理機能を持ちますが、Glue Data Catalog のように Athena や Redshift Spectrum から直接参照できる統合度の高さは AWS 固有の強みです。
Spark ジョブと Python Shell - DPU 設計の勘所
Glue ジョブには Apache Spark ベースの ETL ジョブと、単一ノードで動く Python Shell ジョブの 2 種類があります。Spark ジョブは数百 GB から TB 級のデータを分散処理する場面に適しており、DPU (Data Processing Unit) の割り当て数でクラスタ規模を制御します。1 DPU は 4 vCPU + 16 GB メモリに相当し、Standard Worker で最小 2 DPU から起動します。DPU を増やせば処理は速くなりますが、課金は DPU 数 × 実行時間なので、過剰な割り当ては無駄なコストに直結します。実務では最初に 2 DPU で実行し、CloudWatch メトリクスの Executor メモリ使用率とシャッフルスピルを確認しながら段階的にスケールアップするのが効率的です。一方、Python Shell ジョブは 1 DPU または 0.0625 DPU で動作し、API 呼び出しや軽量なファイル変換など Spark のオーバーヘッドが不要な処理に向いています。ETL 設計の関連書籍 (Amazon) では、こうした処理規模に応じたジョブ選定の考え方が体系的に解説されています。
Job Bookmark とデータパイプラインの冪等性
ETL パイプラインで最も厄介な問題の一つが「同じデータを二重に処理してしまう」重複処理です。Glue の Job Bookmark はこの課題を解決する仕組みで、前回のジョブ実行がどこまでデータを処理したかを記録し、次回実行時に未処理分だけを対象にします。S3 ソースの場合はファイルパスとタイムスタンプ、JDBC ソースの場合は主キーの最大値を記録することで差分処理を実現します。ただし Job Bookmark が有効に機能するのは、データが追記 (append) される場合に限られます。既存ファイルの上書き更新やパーティション単位の洗い替えが発生するケースでは、Bookmark だけでは整合性を担保できません。そのような場合は、処理済みファイルを別の S3 プレフィックスに移動する方式や、DynamoDB に処理済みキーを記録して冪等性を自前で管理する方式を組み合わせます。Glue Workflow を使えば複数のクローラーとジョブを依存関係付きで連結でき、Step Functions と組み合わせることでエラーハンドリングや条件分岐を含む複雑なデータパイプラインを構築できます。