DEAデータの取り込みと変換
あるeコマース企業は、ウェブサイトのクリックストリームイベントを Amazon Data Firehose で受信し、Amazon S3 に配信しています。各 JSON レコードには "eventType"(例: "click", "purchase", "view")と "timestamp" フィールドが含まれています。データエンジニアリングチームは、下流の Amazon Athena クエリのパフォーマンスを最大化するため、S3 への配信時点から "eventType" と日付(年/月/日)でデータを分割して格納したいと考えています。追加のインフラ管理を最小限に抑えながら、この要件を実現する最適な方法はどれですか?
AAWS Lambda 変換関数を Data Firehose に設定し、各レコードの "eventType" を解析して S3 配信先プレフィックスを動的に変更するロジックを実装する
「AWS Lambda 変換関数を Data Firehose に設定し」は誤りです。Data Firehose の Lambda 変換関数はレコードのデータ内容(ペイロード本文)を変換・フィルタリングする機能であり、S3 配信先のプレフィックスを動的に制御する機能は持ちません。プレフィックスの動的変更には「動的パーティショニング」機能の有効化が別途必要です。
BData Firehose の動的パーティショニングを有効化し、JQ 式でレコードから "eventType" を抽出してパーティションキーとし、S3 プレフィックスを !{partitionKeyFromQuery:eventType}/!{timestamp:yyyy/MM/dd}/ に設定する
✓ 正解
Data Firehose の動的パーティショニング(Dynamic Partitioning)は、ストリームの各レコード内のフィールド値に基づいてリアルタイムに S3 プレフィックスを振り分ける組み込み機能です。JQ 式(インライン解析)または Lambda 関数でレコードからキーを抽出し、S3 プレフィックステンプレートに組み込むことで、追加インフラなしに要件を満たせます。
CData Firehose の後段に Amazon Kinesis Data Streams を追加し、AWS Lambda コンシューマーが "eventType" ごとに異なる S3 パスにデータを書き込む構成に変更する
「Data Firehose の後段に Amazon Kinesis Data Streams を追加し」は誤りです。Kinesis Data Streams の追加と Lambda コンシューマーの実装はアーキテクチャの大幅な変更と管理コストの増大を招きます。Data Firehose に動的パーティショニングが内蔵されている以上、過剰設計です。
DData Firehose で S3 へ配信した後、AWS Glue ETL ジョブを定期実行して "eventType" と日付でデータを再パーティショニングし、元のデータを上書きする
「Data Firehose で S3 へ配信した後、AWS Glue ETL ジョブを定期実行して」は誤りです。配信後に Glue ETL で再パーティショニングする方式は二重処理コストが発生し、データが正しいパーティションへ格納されるまでタイムラグが生じるため、リアルタイムなクエリ最適化には適しません。
解説
Data Firehose の動的パーティショニング(Dynamic Partitioning)は、ストリームの各レコード内のフィールド値に基づいてリアルタイムに S3 プレフィックスを振り分ける組み込み機能です。JQ 式(インライン解析)または Lambda 関数でレコードからキーを抽出し、S3 プレフィックステンプレートに組み込むことで、追加インフラなしに要件を満たせます。
選択肢Aの「AWS Lambda 変換関数を Data Firehose に設定し」は誤りです。Data Firehose の Lambda 変換関数はレコードのデータ内容(ペイロード本文)を変換・フィルタリングする機能であり、S3 配信先のプレフィックスを動的に制御する機能は持ちません。プレフィックスの動的変更には「動的パーティショニング」機能の有効化が別途必要です。
選択肢Cの「Data Firehose の後段に Amazon Kinesis Data Streams を追加し」は誤りです。Kinesis Data Streams の追加と Lambda コンシューマーの実装はアーキテクチャの大幅な変更と管理コストの増大を招きます。Data Firehose に動的パーティショニングが内蔵されている以上、過剰設計です。
選択肢Dの「Data Firehose で S3 へ配信した後、AWS Glue ETL ジョブを定期実行して」は誤りです。配信後に Glue ETL で再パーティショニングする方式は二重処理コストが発生し、データが正しいパーティションへ格納されるまでタイムラグが生じるため、リアルタイムなクエリ最適化には適しません。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでDEAを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →