Amazon Data Firehose

は、ストリーミングデータを受け取り、一定量または一定時間ためてから (バッファリング)、、、、テーブルなどへ配信するフルマネージドのサービスです。コンシューマーのコードを書かずに「ストリームを保存先へ届ける」部分を任せられます。旧称は Data Firehose です。

Point

Firehose は「消防ホース」です。大量の水 (データ) を目的地へ流し込むイメージです。
旧称の Kinesis Data Firehose で問題文や選択肢に出ることがあります。同じサービスです。
和訳
- Firehose: 消火ホース
- Weblio英和辞書「firehose」

概要

はサーバーの管理もの管理も不要で、流量に合わせて自動で拡張します。受け取ったデータはバッファにため、サイズか時間のどちらかの条件を満たした時点で配信します。そのため、結果が届くまでに数秒〜数分の遅れがあり、ニアリアルタイムの配信サービスと位置づけます。

試験では、配信先、バッファの設定、変換と形式変換、、失敗したレコードの扱いを判断します。

主要技術

①ソースと配信先

ソース	内容
Direct PUT	アプリケーションや AWS サービス ( Logs、、IoT など) が直接書き込む
	既存のストリームを読み、配信する
	のトピックを読み、配信する

配信先	特徴
	最も基本の配信先。形式変換とが使える
	いったん S3 へ書き、がでロードする
/ OpenSearch Serverless	ログ検索や可視化
テーブル	S3 上の Iceberg テーブル ( を含む) へ書き込む。レコードの内容で書き込むテーブルを振り分けられる
、Splunk、Snowflake など	サードパーティやカスタムの配信先

⚠️ 頻出: 「ストリーミングデータを、コードを書かず、運用負荷を最小にして S3 (または Redshift) へ保存」は Data Firehose です。

②バッファリング ⚠️ 頻出

バッファサイズ (MB) とバッファ間隔 (秒) を設定し、先に満たした方で配信します。

配信先	バッファサイズ (既定)	バッファ間隔 (既定)
	1〜128 MB (5)	0〜900 秒 (300)
テーブル	1〜128 MB (5)	0〜900 秒 (300)
	1〜128 MB (5)	0〜900 秒 (300)
	1〜100 MB (5)	0〜900 秒 (300)
	1〜64 MB (5)	0〜900 秒 (60)

調整	効果	代わりに起きること
間隔を短くする (0 秒はゼロバッファリング)	配信までの遅れが小さくなる	が増え、S3 の PUT の料金と後段のクエリの負荷が増える
サイズと間隔を大きくする	大きなファイルになり、などのクエリが効率的になる	配信までの遅れが大きくなる

ゼロバッファリングは、S3 のバックアップ先とでは使えません。間隔を 60 秒未満にすると、S3 へのマルチパートアップロードになり、PUT の料金が増えます。

③Lambda によるデータ変換

はバッファしたレコードを関数へ渡し、変換した結果を受け取って配信できます。関数は各レコードに recordId と結果 (Ok、Dropped、ProcessingFailed) を付けて返します。

使いどころ	例
形式の変換	CSV や独自形式のログをにする (形式変換の前処理)
項目の加工	のマスキング、不要な項目の削除、項目の追加
フィルター	条件に合わないレコードを Dropped にして捨てる

ProcessingFailed になったレコードは、のエラー出力プレフィックスへ書き出されます。

④形式変換 (JSON → Parquet / ORC) ⚠️ 頻出

は、の入力をまたは (列指向の形式) に変換してへ書き込めます。

必要な要素	内容
デシリアライザー	入力の JSON を読む。OpenX JSON SerDe か Apache Hive JSON SerDe
スキーマ	Data Catalog のテーブル定義を参照する
シリアライザー	Parquet SerDe か ORC SerDe

入力が CSV など JSON 以外なら、先に変換で JSON にしてから形式変換を使います。スキーマに定義していない項目は、変換後のデータに含まれません。

⚠️ 頻出: 「ストリーミングの JSON をで安く速く問い合わせたい」は、Firehose の形式変換で Parquet にし、Glue Data Catalog のスキーマを使う構成です。CSV が入力なら Lambda 変換を前に挟みます。

⑤動的パーティショニング ⚠️ 頻出

は、レコードの中の値 (例: customer_id、event_date) をキーにして、のプレフィックスを分けて配信する機能です。やでパーティションを絞り込めるため、スキャン量とコストが下がります。

キーの取り出し方	内容
インライン解析	のレコードから jq の式でキーを取り出す
	JSON 以外の形式や複雑な計算が必要なときに、関数でキーを作る

S3 のプレフィックスには !{partitionKeyFromQuery:customer_id} のような式を書きます。

制約	内容
アクティブなパーティション数	ストリームあたり 500 まで (申請で 2,500 まで)。超えたレコードはエラー出力プレフィックスへ
遅れ	多段のバッファリングのため、設定したバッファ時間の 1.5 倍程度かかることがある
ゼロバッファリング	使えない

パーティション数が多すぎる (例: ユーザー ID ごと) と上限に達し、も増えます。カーディナリティ (値の種類の数) が適度なキー (日付、地域、テナント) を選びます。

⑥失敗したレコードとバックアップ

機能	内容
ソースレコードのバックアップ	/ が配信先のとき、変換前の元データを S3 へ保存できる
失敗データのみ/全データのバックアップ	やが配信先のとき、失敗分だけか全部を S3 へ保存
エラー出力プレフィックス	変換の失敗、の失敗、パーティション数の超過などのレコードを書き出す
再試行期間	配信先が一時的に使えないとき、設定した期間は再試行する

Redshift への配信では、S3 への書き込みは成功したがが失敗した場合、S3 に残ったファイルの一覧 (マニフェスト) から後で手動でロードできます。

⑦圧縮と暗号化

項目	選択肢
への圧縮	GZIP、Snappy、Zip、Hadoop 互換 Snappy、なし ( が配信先のときは GZIP のみ)
	ストリームのサーバー側暗号化 ()、S3 の

形式変換でにする場合は、Parquet の中で列ごとに圧縮されます。

試験対策

①判断マトリクス

問題文のキーワード	選ぶ機能・サービス
ストリームを // へ、コード不要・運用最小
ミリ秒〜1秒の遅れで処理	Firehose ではなく + /
が多すぎる	バッファサイズと間隔を大きくする
配信の遅れを小さく	バッファ間隔を短く (0 秒はゼロバッファリング)
をにして S3 へ	形式変換 + Data Catalog のスキーマ
CSV を Parquet にして S3 へ	Lambda で JSON に変換 → 形式変換
レコードの値ごとに S3 のプレフィックスを分ける
を除いてから保存	Lambda によるデータ変換
配信に失敗したデータを失いたくない	S3 のバックアップ、エラー出力プレフィックス
ストリームをテーブルへ直接書く	Firehose の Iceberg 配信先

②よくある誤答

にリプレイや複数コンシューマーの読み取りを期待すること。それはの役割です。
Firehose をミリ秒単位のリアルタイム処理に使うこと。バッファリングのため遅れが出ます。
形式変換が CSV を直接読めると考えること。入力はで、CSV はで前処理します。
のキーにユーザー ID のような値の種類が非常に多い項目を使うこと。パーティション数の上限に達します。