DEAデータの取り込みと変換
あるeコマース企業は、Amazon Data Firehose を使ってクリックストリームデータをAmazon S3に保存しています。各レコードにはJSONフィールド `event_type`（例：purchase、view、add_to_cart）と `event_time` が含まれています。Amazon Athenaでのクエリコストを削減するため、S3上のデータを `s3://bucket/event_type=purchase/year=2024/month=01/day=15/` のようなパス構造で自動的にパーティション分けしたいと考えています。追加のインフラ管理を最小化した上でこの要件を実現する方法はどれですか？
AAmazon Data Firehose のダイナミックパーティショニングを有効化し、JQ式を使ってJSONフィールドからパーティションキーを抽出してS3プレフィックスを動的に構成する
✓ 正解
Amazon Data Firehose のダイナミックパーティショニングは JQ 式で JSON ペイロードの event_type をリアルタイムに抽出し、!{partitionKeyFromQuery:event_type} のような式で S3 プレフィックスを動的構成できる。追加インフラ不要で Amazon Data Firehose 単体で要件を完結でき、最小の運用負荷で実現できる。
BAmazon Data Firehose のS3送信先に静的プレフィックス `year=!{timestamp:yyyy}/month=!{timestamp:MM}/` のみを設定し、event_type によるパーティションは後続のGlueジョブで付与する
Amazon Data Firehose の静的プレフィックスは !{timestamp:yyyy} などタイムスタンプ変数のみ対応しており、JSON ペイロードの動的フィールド値を S3 プレフィックスに組み込む機能がない。event_type によるパーティション分けには後続の追加処理が必要となり要件を満たさない。
CAmazon Kinesis Data Streams にデータを送り、AWS Lambda をコンシューマーとして設定してレコードを解析しS3の適切なパスに直接書き込む
Lambda コンシューマーによる直接 S3 書き込みは技術的に可能だが、スケーリング・エラー処理・並行書き込み管理が必要で運用負荷が増大する。Kinesis Data Streams と Lambda という追加インフラの管理が発生し、最小化するという要件に合致しない。
DAmazon Data Firehose でS3に書き込んだ後、AWS Glue ETLジョブをスケジュール実行してパーティション構造を再編成する
Glue ETL ジョブによる後処理は、S3 着地後にデータを再読み込んで再パーティションするためラグが発生し、余分な読み書きコストも生じる。別途スケジューリングとジョブ管理が必要となり、追加インフラを最小化するという要件を満たさない。
解説
Amazon Data Firehose のダイナミックパーティショニング機能を使うと、JSONペイロード内のフィールドをJQ式（またはAWS Lambda）でリアルタイムに抽出し、S3プレフィックスとして動的に設定できます。`!{partitionKeyFromQuery:event_type}` のような式でevent_typeの値をパス構造に組み込めます。追加のインフラ（Lambdaコンシューマー、Glueジョブ等）を管理する必要がなく、Amazon Data Firehose単体でパーティション分けが完結するため、最小限の運用負荷で要件を満たします。
選択肢BのAmazon Data Firehoseの静的プレフィックス設定はタイムスタンプベースのパーティションのみ対応しており、JSONペイロードのフィールド値（event_type等）を動的に取得することはできません。後続のGlueジョブが必要になり複雑化します。
選択肢CのAWS Lambdaコンシューマーによる直接S3書き込みは技術的には可能ですが、スケーリング、エラー処理、S3への直接書き込みの管理が必要となり運用負荷が増大します。
選択肢DのAWS Glue ETLジョブによる後処理はデータ着地から再パーティションまでにラグが発生し、元データの読み書きによる余分なコストも発生します。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでDEAを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →