Amazon Data Firehoseの動的パーティショニングを有効化し、JQ式でペイロードからevent_typeとevent_dateを抽出してS3プレフィックスキーとして指定する
✓ 正解
Amazon Data Firehoseの動的パーティショニングはJQ式でペイロードからフィールドを抽出し、そのままS3プレフィックスに反映する機能です。追加サービスなしにevent_typeとevent_dateによるリアルタイムパーティショニングを実現でき、Athenaのクエリパフォーマンスを最大化できます。
C
Amazon Kinesis Data StreamsにAWS Lambda関数をコンシューマーとして設定し、Lambdaがevent_typeとevent_dateに応じたS3パスに直接書き込む
Kinesis Data Streams＋Lambdaでも動的なS3書き込みは可能ですが、Kinesis Data Streamsの管理・Lambda関数のコード実装・スケーリング設定が別途必要となり、Amazon Data Firehoseの動的パーティショニングと比べて運用コストが増大します。
D
Amazon EventBridge Pipesを使ってイベントタイプごとに独立したAmazon Data Firehoseストリームにルーティングし、それぞれS3の別プレフィックスに配信する
EventBridge Pipesで複数Amazon Data Firehoseにルーティングするアプローチはevent_typeの分割はできますが、event_dateのような高カーディナリティなフィールドへの対応でFirehoseストリーム数が爆発的に増え、現実的な管理が困難になります。
解説
選択肢BのAmazon Data Firehoseの動的パーティショニング機能を使うと、届いたレコードのJSONペイロードをJQ式でパースし、抽出したフィールド値をS3プレフィックスに埋め込んでリアルタイムにパーティション分割できます。たとえば `!{partitionKeyFromQuery:event_type}/!{partitionKeyFromQuery:event_date}/` のようなプレフィックス設定で、追加サービスなしにAthenaで効率的に使えるパーティション構造を自動構築できます。
選択肢AはGlue ETLジョブによる後処理で目的は達成できますが、rawデータとパーティション済みデータの二重保管によるコスト増、Glueジョブ実行の遅延が発生し、追加コンポーネントも必要になります。
選択肢CのKinesis Data Streams＋Lambda構成でも動的なS3パーティショニングは可能ですが、Kinesis Data Streams・Lambda・カスタムコードの管理が別途必要となり、Amazon Data Firehoseの動的パーティショニングと比べて運用コストが大きくなります。
選択肢DのEventBridge PipesでイベントタイプごとにAmazon Data Firehoseをルーティングする方式はevent_typeによる分割はできますが、event_dateのような値が多様なフィールドへの対応でFirehoseストリーム数が爆発的に増大し、現実的な運用が困難です。