3.1標準
S3の生データから、Parquetの集計テーブルを毎日作成する。
元データを残し、集計失敗時は公開テーブルを壊さずにしたい。
最も適切な自動化方法はどれか。
× 不正解
CTAS/INSERT INTOでステージング出力を作り、件数・品質検証後にCatalogやビューを更新する。
詳細解説
正しいCTAS/INSERT INTOをステージング場所へ実行し、成功後に公開する
SQLで形式変換・パーティション化を行い、成功した出力だけをカタログへ公開できる。
SQLで形式変換・パーティション化を行い、成功した出力だけをカタログへ公開できる。
誤り生データを毎回削除してから作成する
失敗時に復旧できず、原データの再処理もできない。
失敗時に復旧できず、原データの再処理もできない。
誤りS3 LifecycleだけでParquetへ変換する
Lifecycleはストレージクラス移行で、形式変換を行わない。
Lifecycleはストレージクラス移行で、形式変換を行わない。
誤りCloudTrailのログを集計テーブルとして読む
監査イベントは業務データの集計結果ではない。
監査イベントは業務データの集計結果ではない。
実際に確かめる
一時的な検証環境で実行できる例です。
Amazon Athena CTAS、INSERT INTO、partitioning、Glue Data Catalogの公式説明を確認する。期待される結果
形式変換SQLとS3 Lifecycle・監査ログの役割を区別できる。理解のポイント
- Athena CTAS
- Parquet
- ステージング
- 公開
確認時の注意
- 確認環境: AWS公式DEA-C01試験ガイドと各サービスの公式ドキュメントの確認
- AWS公式DEA-C01 Domain 3・Task 3.1と各サービスの公式ドキュメントを確認する。
基礎のおさらい
原子性
新しい出力を別場所へ作成してから参照を切り替え、部分ファイルを見せない。
再処理
処理日・入力版・出力版を命名し、同じ範囲を安全に作り直せるようにする。
問題IDAWS-DEA-195
確認環境AWS公式DEA-C01試験ガイドと各サービスの公式ドキュメントの確認
最終技術確認2026-08-20
誤り・権利侵害を報告