あるIoT企業は、数千台のセンサーデバイスからJSON形式のテレメトリデータを収集し、Amazon Data Firehoseを通じてAmazon S3に配信しています。現在はすべてのデータが単一のS3プレフィックスに格納されており、Amazon Athenaでクエリを実行する際に全データをスキャンするためコストと処理時間が増大しています。 各レコードにはdevice_typeとregionフィールドが含まれており、Athenaでは主に特定のdevice_typeとregionを組み合わせたクエリが実行されます。 Amazon Data Firehoseの設定変更のみで、device_typeとregionに基づくS3パーティション分割を実現する最も適切な方法はどれですか？
Amazon Data Firehoseのダイナミックパーティショニング機能を使うと、受信JSON内の任意フィールドをJQ式で抽出し、S3プレフィックスに動的に組み込めます。プレフィックスパターンを「data/device_type=!{partitionKeyFromQuery:device_type}/region=!{partitionKeyFromQuery:region}/」のように設定するだけで、追加のコンピューティングリソースなしにHive互換のパーティション構造でS3に書き込めます。AthenaはこのパーティションキーでクエリのスキャンS3範囲を絞り込めるため、コストと実行時間を大幅に削減できます。 選択肢AのLambdaトランスフォーメーションはレコードの内容変換・フィルタリングに使用しますが、FirehoseのS3宛先プレフィックスをレコードごとに変える機能はダイナミックパーティショニングの役割であり、Lambdaトランスフォーメーションでは直接制御できません。 選択肢BのGlueクローラーはS3上の既存データをスキャンしてData Catalogにパーティション情報を登録しますが、データの書き込み先パス自体を変更する機能はありません。 選択肢DのバッファリングサイズとBuffer Intervalの調整はファイルサイズと書き出し頻度に影響しますが、S3プレフィックスのパーティション構造とは無関係です。