DEAデータの取り込みと変換
あるEコマース企業は、Webサイトのクリックストリームデータ（JSON形式）をAmazon Data Firehoseで直接Amazon S3に配信しています。各レコードには customer_id と event_date のフィールドが含まれます。データアナリストはAmazon Athenaでクエリする際、スキャン量を削減するため、これらのフィールド値でデータをパーティション分割したいと考えています。カスタムコードの作成を避け、運用負荷を最小にしながら配信時にパーティション分割を実現する方法はどれですか。
AFirehoseで動的パーティショニングを有効化し、インラインJSON解析（jq式）でcustomer_idとevent_dateを抽出してS3プレフィックスにパーティションキーを指定する
✓ 正解
動的パーティショニングのインラインJSON解析（jq式）はカスタムコードなしでレコード内のcustomer_idとevent_dateを抽出しS3プレフィックスに割り当てられる。配信時にパーティション化でき、Athenaのスキャン量削減と運用負荷最小の両要件を同時に満たす唯一の構成。
BFirehoseの動的パーティショニングは使わず、S3プレフィックスに !{timestamp:yyyy/MM/dd} を指定してレコード到着時刻ベースでパーティション分割する
!{timestamp:yyyy/MM/dd} はFirehoseへのレコード到着時刻でプレフィックスを生成するもので、レコード本文のcustomer_idやevent_dateの値ではパーティション分割できない。アナリストが求めるフィールド値ベースの分割要件を満たせないため誤り。
CFirehoseの動的パーティショニングを有効化し、Lambda変換関数でレコードを解析してパーティションキーをメタデータとして付与する
Lambda変換でもパーティションキー付与は可能だが、関数の開発・保守というカスタムコードと追加実行コストが発生する。ソースがJSONならインライン解析だけで抽出でき、コード不要・運用負荷最小の要件に反するため最適ではない。
DFirehoseはそのまま配信し、配信後にAWS GlueクローラーとGlue ETLジョブを定期実行してデータをパーティション再構成する
配信後にGlueクローラーとETLジョブで再パーティションする構成は、別サービスの定期実行で運用負荷・コスト・遅延が増える。Firehoseの配信時パーティション分割で完結できる要件に対し過剰で、運用負荷最小に反するため誤り。
解説
Amazon Data Firehoseの動的パーティショニングは、配信時にレコード内容に基づいてS3プレフィックスを動的に生成する機能である。ソースがJSONの場合、インラインJSON解析（jq式）を使えばコードを書かずに customer_id や event_date といったフィールドを抽出し、パーティションキーとしてプレフィックスに割り当てられる。これによりAthenaのパーティションプルーニングが効きスキャン量を削減でき、追加サービスもカスタムコードも不要で運用負荷が最小となる。
選択肢Bの !{timestamp} はレコード到着時刻でのパーティション分割であり、レコード内容のcustomer_idやevent_dateでは分割できないため要件を満たさない。
選択肢CのLambda変換関数は動的パーティショニングでも利用可能だが、関数の実装・保守というカスタムコードと追加コストが発生し、JSONならインライン解析で足りるため運用負荷最小に反する。
選択肢DのGlueクローラー＋ETLの後処理は、配信後に別途ジョブを動かす構成で運用負荷とコスト・処理遅延が増え、配信時パーティション分割という要件にも合致しない。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでDEAを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →