あるデータエンジニアリングチームは、Amazon Data Firehose を使用してJSONストリームデータをApache Parquet形式に変換し、Amazon S3に配信するパイプラインを運用しています。 ある日、Amazon CloudWatch のモニタリングで Firehose の変換エラーが増加していることを検出し、一部のレコードのJSONからParquetへの形式変換が失敗していることが判明しました。 変換に失敗したレコードを特定して再処理するために、最も適切な対処方法はどれですか？
Amazon Data Firehose でデータ形式変換（例：JSON→Parquet/ORC）に失敗したレコードは、配信ストリームに設定された処理失敗S3プレフィックス（Processing Error Prefix）に自動的に保存されます。FirehoseはAWS Glue Data Catalogを参照してスキーマ変換を行い、変換失敗レコードをこのプレフィックスに書き出すため、データを失うことなく内容を確認・再処理できます。 選択肢AのAmazon Data Firehose の配信ストリームの処理失敗S3プレフィックスは、Firehoseの組み込み機能により変換失敗レコードが自動保存されるため、最も確実かつ運用負荷の低い方法です。 選択肢BのAmazon CloudWatch Logs にはエラーのメタデータは記録されますが、失敗レコードのデータ内容そのものは保存されません。 選択肢CのKinesis Data Streamsの保持期間内であれば元データの取得は技術的に可能ですが、変換失敗レコードのみを特定する仕組みがなく精度・効率が低くなります。Firehoseの組み込み機能を活用する方が適切です。 選択肢DのAWS Glue ETLジョブで差分を特定する方法は実装が複雑で時間がかかり、Firehoseの自動機能を活用していない非効率なアプローチです。