eコマース企業は、Amazon Data Firehoseを使って注文イベントをリアルタイムにAmazon S3へ配信しています。各イベントのJSONペイロードには `region`（例："US", "JP"）と `or

Question

eコマース企業は、Amazon Data Firehoseを使って注文イベントをリアルタイムにAmazon S3へ配信しています。各イベントのJSONペイロードには `region`（例："US", "JP"）と `order_type`（例："B2B", "B2C"）フィールドが含まれます。Amazon Athenaでのクエリパフォーマンス向上のため、S3上のデータを `orders/region=US/order_type=B2B/` のようにレコード内容に基づいて動的にパーティション分割して書き込みたいと考えています。最も適切な設定はどれですか？

Accepted Answer

正解: Amazon Data Firehoseの動的パーティショニング機能を有効にし、JQ式（JSON処理クエリ言語）でregionとorder_typeを抽出してS3プレフィックステンプレートに設定する。Amazon Data Firehoseの動的パーティショニング機能を使うと、レコードのJSONフィールドをJQ式で抽出し、S3プレフィックステンプレート（例：`orders/region=!{partitionKeyFromQuery:region}/order_type=!{partitionKeyFromQuery:order_type}/`）に動的に組み込めます。これにより、追加インフラ不要でリアルタイムにパーティション分割されたデータをS3に保存できます。

選択肢BのFirehoseのS3プレフィックス設定にLambda ARNを指定してS3書き込み先をLambdaが動的に決定するという機能は存在しません。

選択肢CのFirehoseのLambdaデータ変換機能はレコードのデータ内容（フォーマット変換・フィールド追加削除など）を変換するためのものです。

選択肢Dの後処理での再パーティショニングは機能しますが、日次バッチ処理の遅延・Glueジョブの追加コスト・データの二重保存によるS3コスト増加が発生します。

Answer

Amazon Data Firehoseの「S3バケットプレフィックス」設定にAWS Lambda関数のARNを指定し、Lambdaが各レコードの書き込み先パスをリアルタイムで返すよう構成する — FirehoseのS3プレフィックス設定にLambda ARNを指定してS3書き込み先をLambdaが動的に決定するという機能は存在しません。

Answer

Amazon Data FirehoseのLambdaデータ変換機能で各レコードを処理し、書き込み先パス情報をレコードに付与してFirehoseが振り分けを行うよう設定する — FirehoseのLambdaデータ変換機能はレコードのデータ内容（フォーマット変換・フィールド追加削除など）を変換するためのものです。

Answer

Amazon Data Firehoseからすべてのデータをフラットなパスに一旦書き込み、毎日深夜のAWS Glue ETLジョブでパーティション分割して再保存する — 後処理での再パーティショニングは機能しますが、日次バッチ処理の遅延・Glueジョブの追加コスト・データの二重保存によるS3コスト増加が発生します。

解説

解説