Mục tiêu học tập
- Hiểu Firehose là delivery service: nguồn, đích, buffering
- Nắm transformation bằng Lambda và record format conversion sang Parquet
- Biết dynamic partitioning, error handling (S3 backup)
- Phân biệt rõ Firehose vs Kinesis Data Streams
1. Tổng quan
Amazon Data Firehose (tên cũ: Kinesis Data Firehose, đổi 2/2024) là dịch vụ fully managed nhận streaming data và deliver vào đích lưu trữ/analytics. Không quản shard, không viết consumer, tự scale.
Đặc điểm cốt lõi
- Near real-time: dữ liệu được buffer rồi flush theo buffer size hoặc buffer interval, cái nào đạt trước
- Buffer interval từ 0 giây (zero buffering — deliver trong vài giây) đến 900 giây; mặc định phổ biến 300s/5MB
- Tự scale, không shard, không capacity planning — "least operational overhead" cho delivery
- Không lưu trữ dữ liệu để replay (nếu cần replay → đặt Kinesis Data Streams phía trước)
- Billing theo GB ingested (+ phí format conversion, dynamic partitioning nếu bật)
2. Transformation và format conversion
Lambda transformation
Firehose gọi Lambda xử lý batch record trước khi ghi đích: parse, làm giàu, lọc, chuẩn hóa.
- Lambda trả về record với status:
Ok/Dropped/ProcessingFailed - Record lỗi được ghi vào S3 error prefix (processing-failed) — không mất dữ liệu
Record format conversion (built-in)
Convert JSON → Parquet hoặc ORC ngay trong Firehose:
- Yêu cầu schema định nghĩa trong Glue Data Catalog
- Nguồn không phải JSON (vd CSV)? → dùng Lambda transform chuyển thành JSON trước, rồi format conversion
- Đây là đáp án chuẩn cho "streaming JSON vào S3 dạng Parquet, ít vận hành nhất"
Dynamic partitioning
Tự ghi vào prefix S3 theo giá trị trong record (jq expression hoặc metadata từ Lambda):
s3://lake/events/customer_id=1234/year=2026/month=07/...
- Thay thế việc phải chạy job re-partition sau này; có phí thêm per GB
- Kết hợp key
year/month/daytừ timestamp của record
3. Delivery vào từng đích — chi tiết đáng thi
| Đích | Cơ chế | Lỗi xử lý thế nào |
|---|---|---|
| S3 | Ghi object theo buffer, prefix tùy chỉnh + error prefix | Retry rồi ghi error prefix |
| Redshift | Ghi S3 trung gian rồi phát COPY | Manifest lỗi vào S3 |
| OpenSearch | Index trực tiếp | Failed docs → S3 backup |
| HTTP endpoint / Splunk... | POST batch | Retry + S3 backup |
- S3 backup: có thể bật backup toàn bộ source records (trước transform) vào bucket riêng — phục vụ reprocess/audit
- Nén output: GZIP/Snappy/ZSTD; mã hóa KMS
4. Firehose vs Kinesis Data Streams (bảng phải thuộc)
| Kinesis Data Streams | Amazon Data Firehose | |
|---|---|---|
| Bản chất | Stream storage — producer/consumer tùy ý | Delivery service — điểm đến cố định |
| Latency | Real-time (~ms-s) | Near real-time (buffer; 0s-900s) |
| Replay | Có (retention 24h-365d) | Không |
| Consumer tùy ý | Có (Lambda, KCL, Flink, nhiều app) | Không (chỉ các destination hỗ trợ) |
| Quản lý capacity | Shard (hoặc on-demand) | Hoàn toàn tự động |
| Custom processing | Tự viết consumer | Chỉ Lambda transform trong luồng |
| Use case | Realtime analytics, nhiều consumer, ordering, replay | Đổ data vào S3/Redshift/OpenSearch ít vận hành |
Pattern kết hợp phổ biến: KDS (nhiều consumer realtime + replay) → một consumer là Firehose để archive vào S3 Parquet.
5. Tình huống điển hình
| Đề bài | Đáp án |
|---|---|
| Clickstream JSON → S3 Parquet, partition theo ngày, least ops | Firehose + format conversion + dynamic partitioning |
| Log ứng dụng → OpenSearch để search, gần realtime | Firehose destination OpenSearch |
| Cần cả realtime alerting lẫn archive S3 | KDS → (Lambda alert) + (Firehose → S3) |
| "Deliver trong vài giây, không muốn chờ 60s buffer" | Zero buffering (buffer interval 0) |
| Record cần làm giàu thêm trường trước khi lưu | Lambda transformation trong Firehose |
Câu hỏi ôn tập
-
Firehose có thay được Kinesis Data Streams khi cần nhiều consumer xử lý cùng dữ liệu không?
Xem đáp án
Không. Firehose là delivery service một chiều tới destination cấu hình sẵn, không lưu dữ liệu, không cho consumer tùy ý đọc/replay. Nhiều consumer độc lập (realtime app + analytics + archive) → Kinesis Data Streams (mỗi consumer tự đọc, có thể thêm enhanced fan-out), trong đó một consumer có thể chính là Firehose để archive.
-
Streaming JSON events cần lưu vào S3 dạng Parquet để Athena query rẻ. Giải pháp ít vận hành nhất?
Xem đáp án
Firehose record format conversion: khai báo schema trong Glue Data Catalog, bật convert JSON → Parquet (kèm Snappy), buffer đầy là ghi thẳng Parquet vào S3 — không cần Glue job convert riêng. Nếu source không phải JSON, thêm Lambda transform chuyển về JSON trước bước conversion.
-
Buffer hint hoạt động thế nào? Muốn dữ liệu tới S3 nhanh nhất có thể thì làm gì?
Xem đáp án
Firehose flush khi đạt buffer size (vd 5MB) hoặc buffer interval (vd 300s) — điều kiện nào đến trước. Muốn nhanh nhất: đặt buffer interval nhỏ, thấp nhất là 0 giây (zero buffering) — deliver trong vài giây, đổi lại nhiều file nhỏ hơn trên S3 (trade-off small files với Athena — có thể cần compaction sau).
-
Lambda transform trả lỗi cho một số record. Dữ liệu đó có mất không?
Xem đáp án
Không. Record
ProcessingFailedđược Firehose ghi vào S3 error output prefix (kèm metadata lỗi) để xử lý lại sau. Ngoài ra có thể bật source record backup lưu toàn bộ bản gốc trước transform vào bucket backup. Delivery thất bại tới destination (vd OpenSearch down) cũng retry rồi rơi vào S3 backup — Firehose thiết kế để không âm thầm mất dữ liệu. -
Firehose ghi vào Redshift bằng cách nào?
Xem đáp án
Không ghi trực tiếp: Firehose ghi vào S3 trung gian trước, rồi tự phát lệnh COPY vào Redshift (cần cấu hình cluster, table, IAM role). Vì vậy độ trễ = buffer + COPY. Đây cũng là lý do khi thi thấy "Firehose → Redshift" phải nhớ nó đi qua S3 (và hỗ trợ cả Redshift Serverless).
-
Chi phí Athena tăng vì Firehose sinh quá nhiều file nhỏ. Cách khắc phục?
Xem đáp án
(1) Tăng buffer size/interval để mỗi object lớn hơn; (2) bật format conversion sang Parquet (nén + columnar); (3) dynamic partitioning đúng khóa query; (4) chạy compaction định kỳ (Glue job hoặc Athena CTAS/OPTIMIZE với Iceberg). Small files làm tăng cả chi phí S3 request lẫn thời gian query.
Bài tập thực hành
- Tạo Firehose stream Direct PUT → S3, buffer 60s, gửi vài record bằng CLI
aws firehose put-record - Bật dynamic partitioning theo trường
event_type(jq) và kiểm tra cấu trúc prefix trên S3 - Thêm Lambda transform đơn giản (thêm trường
processed_at) và xem output - Đọc Firehose record format conversion
Tài liệu tham khảo chính thức
Tiếp theo: Amazon MSK và MSK Serverless