Mục tiêu học tập
- Hiểu kiến trúc EMR: node types, EMRFS, cluster lifecycle
- Tối ưu chi phí EMR: Spot, instance fleets, transient cluster, auto-termination
- Nắm EMR Serverless và EMR on EKS
- So sánh Glue vs EMR — câu hỏi lựa chọn kinh điển
1. Amazon EMR (on EC2)
Kiến trúc
- EMRFS: connector S3 — dữ liệu bền ngoài cluster, cluster tắt không mất data → mô hình chuẩn hiện nay
- Transient cluster: bật cluster chạy steps rồi auto-terminate — batch rẻ; long-running cho ad-hoc/interactive
- Quản trị sâu: chọn AMI, bootstrap actions, cấu hình từng framework — mạnh nhưng nhiều vận hành
Tối ưu chi phí EMR (hay thi)
| Kỹ thuật | Chi tiết |
|---|---|
| Spot cho TASK nodes | Task node không giữ HDFS → mất node không mất data; core/primary nên On-Demand |
| Instance fleets | Trộn nhiều instance type + purchasing option, allocation strategy |
| Transient + auto-termination | Không trả tiền cluster idle |
| Managed scaling | Tự thêm/bớt node theo tải |
| Graviton instances | Rẻ hơn ~20% cùng hiệu năng |
| S3 thay HDFS | Không cần core node storage lớn |
2. EMR Serverless
- Chạy Spark/Hive job không quản cluster: khai app → submit job, AWS cấp worker theo nhu cầu, scale to zero
- Trả theo vCPU-giây + GB-giây thực dùng; pre-initialized capacity (warm) nếu cần start nhanh
- Không SSH, không chọn instance; giới hạn framework (Spark, Hive) so với EMR đầy đủ
- Exam cue: "Spark jobs, intermittent/unpredictable, không muốn quản cluster" → EMR Serverless
3. EMR on EKS
- Chạy Spark job trên cụm EKS có sẵn — tận dụng hạ tầng Kubernetes chung của tổ chức, chia sẻ capacity với service khác
- Chọn khi đề nói "standardized on Kubernetes / existing EKS cluster"
4. Glue vs EMR — bảng quyết định
| AWS Glue | EMR (EC2) | EMR Serverless | |
|---|---|---|---|
| Mô hình | Serverless ETL job | Cluster tự quản | Serverless job |
| Framework | Spark (+Python shell, Ray) | Mọi thứ: Spark, Hive, Trino, Flink, HBase... | Spark, Hive |
| Kiểm soát hạ tầng | Không | Đầy đủ (AMI, bootstrap, thư viện hệ thống) | Không |
| Tích hợp ETL (catalog, bookmark, crawler, visual) | Sâu nhất | Catalog dùng được | Catalog dùng được |
| Chi phí | DPU-hour (đơn giá cao hơn) | Rẻ nhất ở quy mô lớn (Spot/RI) | vCPU/GB-giây |
| Vận hành | Thấp nhất | Cao | Thấp |
Quy tắc chọn
- ETL pipeline chuẩn vào lake, ít vận hành → Glue
- Cần framework ngoài Spark/Hive (Trino, HBase, custom), thư viện hệ thống đặc thù, hoặc tối ưu chi phí sâu (Spot, cluster lớn chạy liên tục) → EMR
- Spark thuần, workload gián đoạn, không muốn cluster → EMR Serverless
- Migrate Hadoop/Spark on-prem giữ nguyên stack → EMR ("lift and shift")
5. Chi tiết vận hành đáng nhớ
- Steps: đơn vị submit công việc vào cluster (CLI/API/Step Functions đều submit step được)
- EMR Studio / notebooks: IDE managed cho data scientist trên EMR
- S3DistCp: copy/gộp file lớn giữa S3 ↔ HDFS (cũng là công cụ compaction cổ điển)
- Bảo mật: Kerberos, Lake Formation integration, security configuration (mã hóa at-rest/in-transit)
Câu hỏi ôn tập
-
Chạy nightly Spark batch 2 giờ trên EMR, muốn rẻ nhất mà không rủi ro mất dữ liệu khi Spot bị thu hồi. Thiết kế?
Xem đáp án
Transient cluster (auto-terminate sau steps) + primary & core: On-Demand, task nodes: Spot (instance fleets đa dạng type để giảm xác suất thu hồi đồng loạt). Task node không chứa HDFS nên mất node chỉ chậm lại, không mất data; dữ liệu vào/ra để trên S3 (EMRFS).
-
Vì sao không nên đặt core nodes toàn bộ là Spot?
Xem đáp án
Core nodes chứa HDFS — Spot bị thu hồi đồng loạt có thể mất block HDFS (dưới replication factor) làm hỏng job, thậm chí mất dữ liệu trung gian. Chuẩn: core On-Demand (số lượng tối thiểu), task nodes Spot để co giãn. Nếu mọi dữ liệu trên S3 và shuffle nhỏ, rủi ro giảm nhưng best practice thi cử vẫn là core = On-Demand.
-
Team chạy Spark job vài lần mỗi ngày, mỗi lần 20 phút, không muốn quản lý cluster. Glue hay EMR Serverless — chọn theo tiêu chí nào?
Xem đáp án
Cả hai đều serverless Spark. Chọn Glue nếu muốn hệ sinh thái ETL: bookmark, crawler, Glue Studio, DQ — pipeline data lake chuẩn. Chọn EMR Serverless nếu cần Spark thuần/tùy biến cấu hình Spark sâu hơn, hoặc chạy code Spark/Hive có sẵn từ EMR/on-prem không muốn sửa theo API Glue, hoặc tối ưu đơn giá theo vCPU/GB-giây. Đề thường phân biệt bằng cụm "existing Spark applications" (→ EMR Serverless) vs "ETL with catalog/bookmarks" (→ Glue).
-
Cụm phân tích ad-hoc bằng Trino (Presto) cho analyst — Glue có làm được không? Giải pháp?
Xem đáp án
Glue không chạy Trino — Glue chỉ Spark/Python/Ray. Lựa chọn: EMR (cài Trino/Presto) khi muốn cluster tự quản, hoặc — thường đúng hơn cho ad-hoc SQL trên S3 — Athena (bản chất engine Trino serverless). Đề nhấn "SQL ad-hoc trên S3, serverless" → Athena; "tự quản Trino với cấu hình riêng" → EMR.
-
Cluster Hadoop on-prem (Hive + Spark + HBase) cần lên AWS nhanh, giữ nguyên ứng dụng. Giải pháp?
Xem đáp án
EMR trên EC2 — hỗ trợ nguyên stack Hadoop (Hive, Spark, HBase...), migrate kiểu re-platform giữ code. HDFS → chuyển dần sang S3/EMRFS (DataSync hỗ trợ HDFS). Glue/EMR Serverless không chạy HBase và không cho mức kiểm soát tương đương.
Bài tập thực hành
- Tạo EMR Serverless application (Spark), submit 1 job PySpark đọc/ghi S3, xem billing theo vCPU-giây
- Mô phỏng quyết định: 5 workload (ETL catalog, Trino ad-hoc, HBase, Spark gián đoạn, Hadoop migrate) → chọn Glue/EMR/EMR Serverless/Athena
- Đọc cấu trúc instance fleets và allocation strategy
- Đọc EMR best practices — cost
Tài liệu tham khảo chính thức
Tiếp theo: Lambda cho ETL nhẹ