DEA-2.2データカタログシステムを理解する。
採点する
6問中 0問が回答されています
質問:
インフォメーション
You have already completed the テスト before. Hence you can not start it again.
問題を読み込んでいます…
You must sign in or sign up to start the テスト.
まず、次の操作を完了する必要があります:
結果
結果
正解数 0/問題数6
回答にかかった時間:
終了時間となりました
回答お疲れ様でした。
Earned Point(s): 0 of 0, (0)
0 Essay(s) Pending (Possible Point(s): 0)
カテゴリー
- DEA-2.2データカタログシステムを理解する。 0%
- 1
- 2
- 3
- 4
- 5
- 6
- 選択中
- 後で確認
- 回答済み
- 正解
- 不正解
-
質問 1 of 6
1. 質問
カテゴリ: DEA-2.2データカタログシステムを理解する。【DEA-34】大規模動画配信企業は、Kinesis Data Streams で 1 秒あたり 5 万レコードの視聴ログを取り込み、ほぼリアルタイムで S3 に Parquet 形式で保存し Athena で分析しています。
JSON ペイロードのスキーマは四半期ごとに後方互換の追加が発生します。
要求は次のとおり:
• スキーマ変更によるアプリケーション停止を避ける
• 新パーティションを 5 分以内に Glue Data Catalog に反映する
• 運用負荷とコストを最小化する
これらの要件を同時に満たすアプローチはどれか。正解不正解ヒントボタン
Kinesis Data Streams で送られてくる視聴ログに列が増えるたびにアプリを止めたくない場合は、Glue Schema Registry に JSON スキーマを登録し、バックワード互換ポリシーを設定しておくのが効果的です。Firehose は Registry からスキーマを取得して Parquet 変換を自動化でき、Avro シリアライザも管理してくれるため、四半期ごとの追加項目を意識せず連続取り込みが続けられます。
Kinesis Data Firehose には Dynamic Partitioning と S3 パスパーティション付与の機能があり、delivery stream 側で year/month/day/hour などのキーを書き分けられます。Firehose が S3 にファイルを置くたび S3 イベントで Glue クローラを増分実行し、Glue Data Catalog のパーティションを即時更新すれば、Athena からのクエリは数分後には新パーティションを発見し、手動 ALTER TABLE やフルスキャンを行わずに済みます。
Lambda や EC2 を用いたスクリプト運用を避け、Kinesis Data Firehose・Glue Crawler・Glue Data Catalog・Athena というサーバーレスサービスで統一すると、常時稼働インスタンスが不要でコストが抑えられます。スキーマエボリューション、パーティション自動更新、低運用負荷という複数要件を俯瞰した総合判断では、この連携だけが三つの条件を同時に満たしやすいと整理できます。
-
質問 2 of 6
2. 質問
カテゴリ: DEA-2.2データカタログシステムを理解する。【DEA-35】ある広告配信企業は、S3 に s3://logs/yy=YYYY/mm=MM/dd=DD/ 形式で 1 日あたり 5 GB の JSON ログを保存している。
Athena でほぼリアルタイムに分析したい。
新しいパーティションはアップロード後 10 分以内にクエリ可能である必要がある。
Glue クローラは 1 回の実行で約 30 秒、料金は 1 分単位で課金されるものとする。
運用負荷とコストを最小化しつつ Glue Data Catalog を常に最新に保つ方法として最適なのはどれか。正解不正解ヒントボタン
ログを格納した S3 プレフィックスが生成されるたびに ObjectCreated を EventBridge で捕捉し、そのパスだけを Glue クローラでスキャンすると、30 秒程度でパーティションが Glue Data Catalog に追加され、Athena は数分以内にクエリ可能になるため、10 分以内というリアルタイム性と 1 分単位課金の低コストを同時に実現できます。
一方で CloudWatch Events などで Glue クローラを定期的に走らせたり、Athena で MSCK REPAIR TABLE を流す運用では更新間隔が最長 1 時間に伸びる可能性があり、「ほぼリアルタイム」の要件を逸脱しやすく、クローラと SQL の二重実行が不要なスキャンと追加費用を招いてしまいます。
Redshift Spectrum や Lambda＋CTAS のように全データを再ロードする方式は 5 GB/日という規模には過大で、Kinesis Data Firehose や Redshift クラスターの維持費も発生しますので、S3 でのイベント駆動により Glue が必要最小限の範囲をオンデマンド処理する構成が更新速度・運用手間・コストの三要件を総合的に最もバランス良く満たします。 -
質問 3 of 6
3. 質問
カテゴリ: DEA-2.2データカタログシステムを理解する。【DEA-36】通信事業者 A 社は、Spot インスタンスを用いた一過性 Amazon EMR 6.x クラスターを 1 日 6 回起動し、Amazon S3 に保存された 300 TB の Parquet データを Hive と Spark で処理している。
各バッチは 45 分以内に完了後クラスターを削除する。
全バッチで同一のスキーマとパーティション統計を共有し、RPO 0・RTO 5 分未満でメタデータを常時利用可能にしたい。
運用負荷とコストを最小化しつつ要件を満たすメタデータ管理方法を選択せよ。正解不正解ヒントボタン
毎回使い捨ての Amazon EMR 6.x を Spot インスタンスで立ち上げる場合でも、Hive や Spark が参照するテーブル定義やパーティション統計をリージョン内で常時 3AZ 以上にレプリケートし、API で瞬時に取り出せるサーバレスメタストアがあれば、RPO 0 と RTO 数分を自然に達成できます。mysqldump などの前後処理やマスターノードでの永続化を気にせず済む点が、一過性クラスター運用のシンプルさを大きく後押しします。
Amazon RDS MySQL Multi-AZ などの専用データベースは高可用性を備えていますが、インスタンス稼働時間課金、スナップショット管理、バージョンアップ適用といった運用作業が常に発生し、クラスターが動いていない時間帯も費用がかかります。対照的に AWS Glue Data Catalog はサーバレスで API 呼び出しとメタデータ容量のみ課金されるため、1 日 6 回 45 分というバースト型ワークロードにおけるコスト最適化と運用負荷削減にフィットしやすいです。
一過性の EMR バッチ、300TB の Parquet を置く Amazon S3、RPO 0・RTO 5 分未満、マルチ AZ 冗長、サーバレス、必要最小限の IAM 制御という複数条件を同時に満たす構成を俯瞰すると、EMR 起動時に –enable-glue-datacatalog を指定して AWS Glue Data Catalog を共通メタストアとして使うアプローチが、可用性・復旧時間・費用・運用負荷のバランスを総合的に最適化できると導き出せます。
-
質問 4 of 6
4. 質問
カテゴリ: DEA-2.2データカタログシステムを理解する。【DEA-37】動画配信企業A社は、S3に保存する日次パーティション(yyyy-MM-dd)付きParquet約1,000テーブルをAmazon EMR(6.15)、Athena、Redshift Spectrumから横断検索したい。
現在のオンプレApache Hiveメタストアは6か月以内に廃止予定。
要件は
①新規パーティションを最長5分以内に自動検出、
②各サービスで単一かつ高可用なメタデータストアを共有、
③Lake Formationで列レベル権限を集中管理、
④運用負荷とコストを最小化すること。
最適なアプローチはどれか。正解不正解ヒントボタン
Amazon EMR、Athena、Redshift Spectrum の三つが同じメタデータを読みに行く場合はリージョン冗長でフルマネージドな AWS Glue Data Catalog がネイティブ連携する唯一のサービスであり、別途 Amazon RDS や ZooKeeper を維持せずとも Lake Formation と組み合わせて列レベル権限制御まで一元化でき、可用性と保守工数の双方で優位に立てます。
Parquet を日次パーティションで継続生成するワークロードでは、AWS Glue クローラを最短 5 分間隔でスケジュールするだけで S3 パス上の yyyy-MM-dd ディレクトリを自動認識して Data Catalog のパーティション情報を即時更新でき、MSCK REPAIR TABLE の cron や DistCp でメタストアを同期する方式と比べて運用自動化が段違いに進みます。
高可用な単一メタストア、5 分以内のパーティション認識、Lake Formation による列レベル統制、そしてサーバレスによるコスト最適化という四つの要件を総合的に満たす構成は Glue Data Catalog ＋ Glue クローラ ＋ Lake Formation を中心としたデータレイクアーキテクチャである、と俯瞰的に判断できます。 -
質問 5 of 6
5. 質問
カテゴリ: DEA-2.2データカタログシステムを理解する。【DEA-38】金融系スタートアップ FinX は、S3 バケット finx-raw に日次 5 GB の JSON ログを保存している。
event_date でパーティションされたこれらを Glue データベース testdb のデータカタログへ 6 時間ごとに Glue クローラで同期したい。
他部門が管理するデータベースには変更させず、対象バケットの読み取りと testdb 内でのテーブル・パーティション登録に必要最小限の権限のみを持つ IAM サービスロールを作成する。
次のポリシー案のうち要件を満たすものはどれか。正解不正解ヒントボタン
Glue Crawler が S3 からスキーマを取り込み Glue Data Catalog にメタデータを登録する際に呼ばれる API を IAM ポリシーシミュレータなどで洗い出すと、S3 側は s3:ListBucket と s3:GetObject、Glue 側は glue:GetDatabase・glue:CreateTable・glue:BatchCreatePartition の３系統だけで処理が完結します。この５アクションが揃っていれば event_date パーティションの追加も問題なく行え、PutObject や UpdateTable などの更新系や Delete 系が無くてもクロールは成功する点を押さえておきましょう。
金融のような厳格な監査環境では IAM の「最小権限」と「リソースレベル制御」が特に重視されます。S3 は arn:aws:s3:::finx-raw と arn:aws:s3:::finx-raw/* に限定し、Glue も arn:aws:glue:リージョン:アカウント:database/testdb と table/* へ絞れば他部門への影響を遮断できます。対照的に ARN=* や glue:*、AWS 管理ポリシーを付けると広範な操作権限を持ち監査リスクが高まるため、このシナリオでは避ける方が安全と判断できます。
４案を条件別に整理すると、①S3 が読み取り２アクションのみで対象バケット限定、②Glue は既存 testdb の参照と CreateTable・BatchCreatePartition が可能、③Update・Delete・glue:* といった過剰権限を含まずリソーススコープも限定――この３条件を同時に満たす案が１つだけ残ります。複数要件を整合させたうえで IAM、S3、Glue の権限設計を総合的に評価すると答えが導けます。
-
質問 6 of 6
6. 質問
カテゴリ: DEA-2.2データカタログシステムを理解する。【DEA-39】動画配信企業では、JSON 形式の視聴ログ約 5 TB/日（1 日あたり約 200 パーティション）を s3://logs/year=YYYY/month=MM/day=DD/ に保存し、Athena で分析している。
要件は次のとおりである。
① 新規オブジェクトは投入後 10 分以内にクエリ可能であること
② 列追加などのスキーマ変更は週 1 回検出できればよい
③ Glue クローラ実行時間とコストを最小化する。
これらを満たす Glue Data Catalog の運用設計として最適なのはどれか。正解不正解ヒントボタン
1 日 5 TB・200 パーティションの JSON が s3://logs/ に到着し続けても、Athena で 10 分以内に検索できるようにするには、新着ファイル発生を合図に Glue Data Catalog へ即座にパーティション登録する仕組みが重要です。Amazon S3 の PUT 通知を EventBridge で受け取り、「新しいフォルダのみをクロール」に設定した Glue クローラをその場で起動すると、最新パーティションだけを短時間で解析でき、過去フォルダを読まないため実行時間と料金が最小化できます。
列追加などのスキーマ差分は週 1 回検出できれば十分という制約があるため、毎回フルスキャンするのは無駄です。Glue Crawler には増分クロールとフルクロールを分けて運用する方法があり、通常は S3 PUT 毎の軽量クロールでパーティションだけを追加し、週末などにフルクロールを走らせてカラム追加を検知すれば要件を満たせます。こうすることで Glue の起動時間とデータ読み込み量を抑えつつ、Data Catalog のスキーマも自動で最新化できます。
15 分おきにバケット全体をフルクロールすると数十 TB を毎回読み込み Glue コストが急増しますし、MSCK REPAIR TABLE や S3 Batch Operations はパーティション追加はできても反映まで数十分かかりリアルタイム性が不足します。S3 イベント駆動の増分クロールと週 1 回のフルクロールを組み合わせる設計が、迅速なパーティション反映、低頻度スキーマ検出、Glue 実行時間削減という複数要件を俯瞰したとき最もバランスの良い総合判断となるでしょう。
改善リクエスト