Phân tích dữ liệu
Kinesis, Firehose, Glue, Athena, EMR, Redshift, Lake Formation, OpenSearch: thu thập, xử lý và truy vấn dữ liệu lớn.
- DomainThiết kế hiệu năng cao
- DomainTối ưu chi phí
- 8 sơ đồ
- 11 tình huống
- 12 dịch vụ
5 phút phải nhớ
- Kinesis Data Streams: luồng dữ liệu thời gian thực, bạn tự viết consumer, dữ liệu giữ lại 24 giờ (tăng được tới 365 ngày) và đọc lại được.Đề có "nhiều ứng dụng cùng đọc một luồng", "đọc lại dữ liệu cũ", "giữ thứ tự theo khoá" → Kinesis Data Streams.
- Amazon Data Firehose: nạp dữ liệu luồng vào S3, Redshift, OpenSearch, Splunk… gần thời gian thực, không có shard để quản lý.Firehose gom dữ liệu theo buffer (kích thước hoặc thời gian) rồi ghi; đổi sang Parquet và gọi Lambda biến đổi được. "Đổ log vào S3 ít vận hành nhất" → Firehose.
- Shard ở chế độ provisioned: ghi tối đa 1 MB/s hoặc 1.000 bản ghi/s, đọc 2 MB/s. Chế độ on-demand tự co giãn.Lỗi ProvisionedThroughputExceeded: thêm shard, chuyển on-demand, hoặc chọn partition key phân bố đều hơn (tránh shard nóng).
- Amazon MSK là Apache Kafka được quản lý.Đề nói "đang dùng Kafka", "cần API Kafka", "chuyển cụm Kafka lên AWS" → MSK, không phải Kinesis.
- Managed Service for Apache Flink xử lý luồng có trạng thái: lọc, gộp theo cửa sổ thời gian, phát hiện bất thường ngay trên Kinesis hoặc Kafka."Tính trung bình mỗi 5 phút trên luồng dữ liệu" → Flink.
- Athena: chạy SQL thẳng trên dữ liệu trong S3, serverless, tính tiền theo lượng dữ liệu quét.Giảm chi phí và tăng tốc: lưu dạng cột (Parquet / ORC), nén, chia partition (vd. theo ngày) để mỗi câu truy vấn quét ít dữ liệu.
- AWS Glue: Data Catalog (kho metadata dùng chung), crawler tự đoán schema, và ETL serverless chạy Spark.Athena, Redshift Spectrum và EMR đều đọc bảng từ Glue Data Catalog. "Tự phát hiện schema dữ liệu mới trong S3" → Glue crawler.
- Redshift là data warehouse lưu theo cột cho phân tích (OLAP) và BI trên dữ liệu có cấu trúc lớn.Join phức tạp, nhiều người phân tích đồng thời, báo cáo định kỳ → Redshift. Tải không đều, không muốn quản cụm → Redshift Serverless.
- Redshift Spectrum truy vấn dữ liệu trong S3 mà không cần nạp vào Redshift.Dữ liệu nóng nằm trong Redshift, dữ liệu lịch sử để rẻ trên S3, vẫn join chung được trong một câu SQL.
- Amazon EMR chạy cụm Hadoop / Spark / Hive / Presto do bạn cấu hình.Cần framework big data cụ thể hoặc tùy biến cụm → EMR. Task node không giữ dữ liệu HDFS nên chạy Spot được để giảm chi phí.
- Lake Formation dựng data lake trên S3 và phân quyền tập trung tới mức cột, hàng."Nhóm A chỉ thấy vài cột của bảng" khi truy vấn qua Athena / Redshift Spectrum / EMR → Lake Formation, không phải bucket policy.
- OpenSearch Service: tìm kiếm toàn văn, phân tích log và dashboard (OpenSearch Dashboards)."Tìm kiếm theo từ khoá trong catalog sản phẩm" hoặc "phân tích log gần thời gian thực có dashboard" → OpenSearch.
- Amazon Quick (trước là QuickSight) là công cụ BI dựng dashboard từ Athena, Redshift, S3, RDS…Đề hỏi "dashboard cho người dùng nghiệp vụ, serverless" → Quick / QuickSight.
Sơ đồ
Luồng thời gian thực: Kinesis Data Streams và nhiều consumer
Từng bước
- Nguồn ghi bản ghi kèm partition key; cùng key thì vào cùng shard và giữ thứ tự.
- Ba consumer đọc cùng luồng một cách độc lập; ai lỗi thì đọc lại từ vị trí cũ trong thời gian giữ dữ liệu.
- Lambda ghi kết quả vào DynamoDB; Firehose gom buffer rồi lưu bản thô xuống S3.
Firehose: đổ log vào S3 dạng Parquet rồi truy vấn bằng Athena
Từng bước
- Ứng dụng gửi log tới Firehose.
- Firehose gọi Lambda làm sạch dữ liệu và dùng schema trong Glue Data Catalog để đổi sang Parquet.
- Đủ kích thước hoặc hết thời gian buffer thì ghi một file xuống S3.
- Athena truy vấn bằng SQL, chỉ đọc các cột cần.
Partition key quyết định shard: tránh shard nóng
Từng bước
- Key có nhiều giá trị (vd. user ID) chia đều tải ra các shard.
- Một key cố định dồn hết vào một shard: vượt 1 MB/s hoặc 1.000 bản ghi/s thì bị ProvisionedThroughputExceeded.
- Cách sửa: partition key phân tán hơn, thêm shard, hoặc chuyển sang on-demand.
Data lake trên S3: Glue Data Catalog và Lake Formation
Từng bước
- Glue job làm sạch dữ liệu thô, ghi ra Parquet chia partition.
- Crawler quét S3, tạo / cập nhật bảng và partition trong Data Catalog.
- Athena, Redshift Spectrum, EMR đọc schema từ Data Catalog; Lake Formation quyết định ai thấy bảng / cột / hàng nào.
Athena chỉ quét partition có trong WHERE
Từng bước
- Câu truy vấn lọc theo cột partition dt.
- Athena chỉ đọc thư mục dt=2026-10-16: ít dữ liệu quét, ít tiền.
- Các partition khác bị bỏ qua hoàn toàn.
Redshift + Spectrum: dữ liệu nóng trong cụm, dữ liệu cũ trên S3
Từng bước
- Dashboard gửi một câu SQL join bảng trong Redshift với bảng ngoài.
- Phần của bảng ngoài được Spectrum xử lý song song thẳng trên S3, schema lấy từ Data Catalog; dữ liệu không phải nạp vào cụm.
Cụm EMR: core node On-Demand, task node Spot
Từng bước
- Primary node chia việc cho core và task node.
- Dữ liệu chính để trên S3 (EMRFS): cụm có thể tắt khi xong việc mà không mất dữ liệu.
Phân tích log gần thời gian thực với OpenSearch
Từng bước
- Firehose gom log và nạp vào OpenSearch.
- Tìm kiếm toàn văn và dashboard trên OpenSearch Dashboards.
- Firehose sao lưu bản ghi (toàn bộ hoặc chỉ bản ghi lỗi) xuống S3.
So sánh nhanh
Kinesis Data Streams, Firehose, MSK
| Kinesis Data Streams | Amazon Data Firehose | Amazon MSK | |
|---|---|---|---|
| Độ trễ | Thời gian thực (mili giây) | Gần thời gian thực (gom buffer) | Thời gian thực |
| Ai đọc dữ liệu | Consumer bạn viết (Lambda, KCL, Flink…) | Firehose tự ghi tới đích | Consumer Kafka |
| Đọc lại dữ liệu cũ | Có, trong thời gian giữ (24 giờ – 365 ngày) | Không | Có, theo cấu hình retention của Kafka |
| Quản lý dung lượng | Shard (provisioned) hoặc on-demand | Tự co giãn | Broker / chế độ serverless |
| Hợp với | Nhiều consumer, xử lý tuỳ biến | Đổ dữ liệu vào S3 / Redshift / OpenSearch | Hệ thống đã dùng Kafka |
Chọn công cụ truy vấn và phân tích
| Athena | Redshift | EMR | OpenSearch | |
|---|---|---|---|---|
| Kiểu | SQL serverless trên S3 | Data warehouse | Cụm Hadoop / Spark | Tìm kiếm và phân tích log |
| Dữ liệu nằm ở | S3 | Bảng Redshift (+ S3 qua Spectrum) | S3 (EMRFS) hoặc HDFS | Index OpenSearch |
| Tính tiền | Theo dữ liệu quét | Theo node hoặc Redshift Serverless | Theo EC2 của cụm + phí EMR | Theo node / serverless |
| Dùng khi | Truy vấn ad-hoc, không muốn hạ tầng | BI, join lớn, nhiều người dùng đồng thời | Job big data tuỳ biến, nhiều framework | Tìm kiếm toàn văn, log, dashboard |
Làm Athena rẻ và nhanh hơn
| Cách | Vì sao |
|---|---|
| Định dạng cột Parquet / ORC | Chỉ đọc các cột câu truy vấn cần |
| Nén (Snappy, GZIP…) | Ít byte phải quét |
| Chia partition (vd. year/month/day) | WHERE theo partition thì chỉ quét đúng thư mục đó |
| Gộp file nhỏ thành file lớn | Ít request S3, đọc hiệu quả hơn |
| Workgroup giới hạn dữ liệu quét | Chặn câu truy vấn quét quá nhiều |
Glue, Lake Formation, EMR: ai làm gì
| Dịch vụ | Vai trò trong data lake |
|---|---|
| Glue Data Catalog | Danh mục bảng / schema dùng chung |
| Glue crawler | Quét S3, tự tạo / cập nhật bảng trong Data Catalog |
| Glue job | ETL serverless (Spark, Python) |
| Lake Formation | Phân quyền tập trung theo database / bảng / cột / hàng |
| EMR | Cụm big data tuỳ biến khi Glue không đủ |
Tình huống đề hay gặp
1Dữ liệu clickstream cần được 3 ứng dụng khác nhau xử lý độc lập, và phải đọc lại được dữ liệu của 7 ngày trước khi có lỗi xử lý.
Xem đáp án
Đúng: Kinesis Data Streams, tăng thời gian giữ dữ liệu lên 7 ngày, mỗi ứng dụng là một consumer
Nhiều consumer đọc cùng luồng, đọc lại theo vị trí trong thời gian giữ dữ liệu.
Sai: Amazon Data Firehose
Firehose ghi thẳng tới đích, không có consumer tuỳ biến và không đọc lại được.
Sai: Một hàng đợi SQS
Tin nhắn đọc xong là xoá; nhiều ứng dụng cùng đọc thì phải dùng nhiều hàng đợi, và không replay được.
2Cần đưa log ứng dụng vào S3 dạng Parquet để Athena truy vấn, ít vận hành nhất.
Xem đáp án
Đúng: Amazon Data Firehose với chuyển định dạng sang Parquet, đích là S3
Firehose tự gom buffer, đổi định dạng, ghi S3; không có máy chủ.
Sai: Kinesis Data Streams + consumer tự viết chuyển Parquet
Chạy được nhưng phải tự viết và vận hành consumer.
Sai: EC2 chạy script gom log mỗi giờ
Phải tự quản máy, chịu lỗi kém.
3Thỉnh thoảng nhóm vận hành cần chạy SQL trên log ALB đang nằm trong S3; không muốn dựng hạ tầng.
Xem đáp án
Đúng: Athena với bảng trỏ vào thư mục log trên S3
Serverless, trả theo dữ liệu quét, không phải nạp dữ liệu.
Sai: Dựng cụm Redshift và nạp log vào
Tốn tiền cụm chạy liên tục cho nhu cầu thỉnh thoảng.
Sai: Cụm EMR
Phải tạo và quản cụm.
4Hoá đơn Athena tăng mạnh; dữ liệu là file CSV lớn, câu truy vấn hay lọc theo ngày.
Xem đáp án
Đúng: Chuyển dữ liệu sang Parquet có nén và chia partition theo ngày
Athena tính theo dữ liệu quét: định dạng cột + nén + partition làm giảm mạnh lượng quét.
Sai: Chuyển sang Redshift cho rẻ
Không giải quyết gốc vấn đề là quét quá nhiều dữ liệu, lại thêm chi phí cụm.
5Hàng trăm nhà phân tích chạy báo cáo BI với nhiều phép join trên hàng chục TB dữ liệu bán hàng có cấu trúc.
Xem đáp án
Đúng: Amazon Redshift
Data warehouse lưu theo cột, song song hoá truy vấn, dành cho OLAP / BI.
Sai: RDS for PostgreSQL
Database OLTP, không hợp phân tích quy mô TB với nhiều người dùng đồng thời.
Sai: DynamoDB
NoSQL key-value, không hỗ trợ join.
6Dữ liệu 3 tháng gần nhất ở Redshift, 5 năm dữ liệu cũ ở S3; thỉnh thoảng cần báo cáo gộp cả hai mà không tốn chi phí lưu trên Redshift.
Xem đáp án
Đúng: Redshift Spectrum: bảng ngoài trỏ vào S3, join với bảng trong Redshift
Truy vấn dữ liệu S3 mà không phải nạp.
Sai: Nạp hết 5 năm vào Redshift
Tốn dung lượng và chi phí cho dữ liệu ít dùng.
7Cần chạy job Spark, Hive và HBase hiện có, tuỳ chỉnh phiên bản và cấu hình cụm, và giảm chi phí tính toán.
Xem đáp án
Đúng: Amazon EMR, dữ liệu trên S3, task node chạy Spot
EMR cho chọn framework và cấu hình; task node không giữ dữ liệu HDFS nên dùng Spot an toàn.
Sai: AWS Glue
Glue chạy ETL Spark / Python serverless, không chạy Hive / HBase và ít tuỳ biến cụm.
Sai: Athena
Chỉ là SQL trên S3.
8Data lake trên S3: nhóm marketing chỉ được xem một số cột của bảng khách hàng khi truy vấn bằng Athena.
Xem đáp án
Đúng: Lake Formation cấp quyền mức cột cho nhóm marketing
Phân quyền tập trung, áp dụng cho Athena, Redshift Spectrum, EMR.
Sai: Bucket policy chặn theo prefix
Bucket policy chỉ kiểm soát tới mức đối tượng, không tới cột.
Sai: Tạo bản sao dữ liệu bỏ bớt cột
Trùng lặp dữ liệu, khó đồng bộ.
9Dữ liệu mới được đổ vào S3 hằng ngày với schema có thể thay đổi; cần bảng luôn cập nhật để truy vấn.
Xem đáp án
Đúng: Glue crawler chạy theo lịch, cập nhật Glue Data Catalog
Crawler tự đoán schema và partition mới.
Sai: Sửa DDL bảng bằng tay mỗi lần
Dễ quên, dễ sai.
10Website thương mại điện tử cần ô tìm kiếm sản phẩm theo từ khoá, có gợi ý và xếp hạng kết quả.
Xem đáp án
Đúng: Amazon OpenSearch Service
Tìm kiếm toàn văn, xếp hạng theo độ liên quan.
Sai: Athena
Truy vấn batch trên S3, không dành cho tìm kiếm tương tác độ trễ thấp.
Sai: DynamoDB scan
Không có tìm kiếm toàn văn, scan chậm và tốn.
11Ứng dụng ghi vào Kinesis Data Streams gặp ProvisionedThroughputExceeded, dù tổng lưu lượng thấp hơn tổng dung lượng các shard.
Xem đáp án
Đúng: Chọn partition key có nhiều giá trị để phân bố đều, hoặc dùng chế độ on-demand
Một partition key "nóng" dồn hết vào một shard dù các shard khác còn trống.
Sai: Đổi sang SQS
Mất các đặc tính của luồng (thứ tự, nhiều consumer, replay).
Chọn nhanh
Dữ liệu của bạn cần đi đâu, xử lý thế nào?
| Khi cần | Dùng |
|---|---|
| Luồng thời gian thực, nhiều consumer, đọc lại được | Kinesis Data Streams · xem sơ đồ |
| Đổ luồng vào S3 / Redshift / OpenSearch, không viết consumer | Amazon Data Firehose · xem sơ đồ |
| Đang dùng Apache Kafka | Amazon MSK |
| Phân tích luồng theo cửa sổ thời gian | Managed Service for Apache Flink · xem sơ đồ |
| SQL ad-hoc trên S3, không hạ tầng | Athena (+ Parquet, partition) · xem sơ đồ |
| Danh mục schema, ETL serverless | AWS Glue (Data Catalog, crawler, job) · xem sơ đồ |
| BI / OLAP trên dữ liệu có cấu trúc lớn | Amazon Redshift (hoặc Redshift Serverless) · xem sơ đồ |
| Join dữ liệu Redshift với dữ liệu cũ trong S3 | Redshift Spectrum · xem sơ đồ |
| Hadoop / Spark / Hive tuỳ biến | Amazon EMR (task node Spot) · xem sơ đồ |
| Phân quyền data lake tới cột / hàng | Lake Formation · xem sơ đồ |
| Tìm kiếm toàn văn, phân tích log có dashboard | OpenSearch Service · xem sơ đồ |
| Dashboard BI cho người dùng nghiệp vụ | Amazon Quick (QuickSight) |
Bẫy hay gặp
- Chọn Firehose khi đề cần nhiều consumer tuỳ biến hoặc đọc lại dữ liệu: đó là Kinesis Data Streams.
- Coi Firehose là thời gian thực: dữ liệu được gom theo buffer nên là gần thời gian thực.
- Chọn Kinesis khi đề nói hệ thống đang dùng Kafka: đó là MSK.
- Dùng partition key có ít giá trị: một shard bị quá tải trong khi shard khác rảnh.
- Để Athena quét CSV không nén, không partition rồi than hoá đơn cao.
- Dựng Redshift cho vài câu truy vấn thỉnh thoảng trên S3: Athena rẻ và đơn giản hơn.
- Nạp toàn bộ dữ liệu lịch sử vào Redshift trong khi Spectrum đọc được thẳng từ S3.
- Chạy core node của EMR bằng Spot: core node giữ dữ liệu HDFS, mất node là mất dữ liệu; Spot hợp với task node.
- Dùng bucket policy để phân quyền theo cột: không làm được, cần Lake Formation.
- Dùng Athena hoặc DynamoDB cho ô tìm kiếm sản phẩm: tìm kiếm toàn văn là việc của OpenSearch.
- Nhầm RDS (OLTP) với Redshift (OLAP) khi đề nói báo cáo phân tích trên khối dữ liệu lớn.
Dịch vụ trong module
Kinesis Data Streamsluồng dữ liệu real-time
Data Firehosenạp stream vào kho dữ liệu
MSKApache Kafka được quản lý
Managed Flinkxử lý stream bằng Apache Flink
GlueETL serverless và data catalog
AthenaSQL trực tiếp trên S3
EMRcluster big data Spark/Hadoop
Redshiftkho dữ liệu phân tích- Redshift ServerlessRedshift không cần quản lý cluster
Lake Formationquản trị quyền data lake
OpenSearch Servicetìm kiếm và phân tích log
Quick (QuickSight)không gian làm việc AI cho doanh nghiệp
Số liệu dễ thay đổi (đã kiểm với tài liệu AWS)
- Kinesis Data Streams (provisioned): mỗi shard ghi tới 1 MB/s hoặc 1.000 bản ghi/s, đọc tới 2 MB/s. kiểm ngày 2026-10-16 ↗
- Kinesis Data Streams giữ dữ liệu tối thiểu 24 giờ, tăng được tới 8.760 giờ (365 ngày). kiểm ngày 2026-10-16 ↗
- Kinesis Data Streams on-demand: luồng mới mặc định 4 MB/s ghi và 8 MB/s đọc, tự co giãn. kiểm ngày 2026-10-16 ↗
- Firehose ghi S3: buffer 1–128 MiB (mặc định 5) và 0–900 giây (mặc định 300); điều kiện nào tới trước thì ghi. kiểm ngày 2026-10-16 ↗
- Athena tính theo dữ liệu quét; trang giá dùng ví dụ 5 USD mỗi TB. Nén và định dạng cột (Parquet) giảm lượng quét. kiểm ngày 2026-10-16 ↗
- Athena: khi WHERE có cột partition, chỉ quét dữ liệu của partition đó. kiểm ngày 2026-10-16 ↗
- Redshift Spectrum truy vấn dữ liệu trong S3 mà không cần nạp vào bảng Redshift; nhiều cụm cùng truy vấn một bộ dữ liệu được. kiểm ngày 2026-10-16 ↗