DEAデータストアの管理
あるデータプラットフォームチームが、複数の取り込みジョブが同一の Glue Data Catalog テーブルにデータを書き込む構成を運用しています。あるジョブが上流の仕様変更で列を追加・型変更した結果、後続の Athena クエリが既存の他ジョブのデータでスキーマ不整合エラーを起こしました。スキーマの変更履歴を追跡し、互換性のない変更を検知・防止する最小運用負荷の仕組みはどれですか。
AAWS Glue Schema Registry を使い、スキーマをバージョン管理して互換性ルール(後方/前方互換)を強制する
✓ 正解
スキーマを中央でバージョン管理し、登録時に後方/前方互換などのルールで非互換な列・型変更を取り込み段階で拒否できる。変更履歴の追跡と不整合の未然防止を低運用負荷で実現するため要件に最適で正解です。
BGlue クローラーの実行頻度を上げ、スキーマ変更検出時に既存テーブル定義を最新で上書きする
クローラーは互換性を評価せずスキーマ変更を検出して定義を上書きするだけで、既存データとの不整合をむしろ表面化させ、互換性のない変更を防止する仕組みにならないため要件を満たせません。
CAthena 側で各クエリに CAST を多用し、型不整合を実行時に吸収する
クエリ側のCASTは型不整合を実行時に吸収する対症療法に過ぎず、スキーマの変更履歴追跡も互換性の事前検知・防止もできないため、根本的なスキーマ管理の要件には応えられず不適切です。
DS3 のバージョニングを有効化し、変更前のオブジェクトバージョンを参照してロールバックする
S3バージョニングはオブジェクト単位の世代管理機能であり、スキーマのバージョン管理や互換性ルールの強制という機能を持たないため、スキーマ不整合の検知・防止という要件には対応できません。
解説
AWS Glue Schema Registry はスキーマを中央でバージョン管理し、登録時に後方・前方・完全などの互換性ルールを評価して、互換性のない変更(列削除・非互換な型変更など)を取り込み段階で拒否できます。これによりスキーマ進化を制御し、後続クエリの不整合を未然に防げて運用負荷も小さくなります。
選択肢Bのクローラーで最新上書きは、互換性チェックなしに定義を変えるだけで、既存データとの不整合をむしろ顕在化させ防止になりません。
選択肢Cの CAST 多用は実行時の対症療法で、変更履歴の追跡も互換性検知もできず根本解決になりません。
選択肢Dの S3 バージョニングはオブジェクトの世代管理であり、スキーマのバージョン管理や互換性強制の機能を持ちません。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでDEAを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →