Tuần 5 - Ngày 2: Redshift Serverless, Spectrum và WLM

Mục tiêu học tập

• Hiểu Redshift Serverless: RPU, workgroup/namespace, khi nào chọn
• Nắm Redshift Spectrum: external table, chi phí, tối ưu
• Hiểu WLM, Concurrency Scaling, materialized views
• Biết data sharing và các tính năng chia sẻ dữ liệu

1. Redshift Serverless

• Không quản cluster: khai báo base RPU (Redshift Processing Units), Redshift tự scale; trả theo RPU-giây khi có query chạy — idle không tính compute (storage tính riêng)
• Namespace (database, users, KMS — phần dữ liệu) + Workgroup (compute, endpoint, RPU — phần tính toán)
• Tương thích SQL/tính năng với provisioned (Spectrum, Data API, streaming ingestion...)

2. Redshift Spectrum

Cơ chế

• Query dữ liệu S3 không cần load; JOIN được với bảng local
• Cần: external schema trỏ Glue Catalog + IAM role
• Chi phí: $5/TB scanned (ngoài chi phí cluster) → tối ưu giống Athena: Parquet, partition, nén, chọn cột
• So với load vào Redshift: Spectrum hợp dữ liệu lạnh/khối lượng lớn/truy vấn thưa; dữ liệu nóng truy vấn dày → load vào local (RA3) nhanh hơn

3. Workload Management (WLM) và Concurrency Scaling

WLM

• Điều phối queue query: memory, concurrency, ưu tiên theo user group/query group
• Auto WLM (khuyến nghị): Redshift tự quyết concurrency + memory, kèm query priority (LOWEST→HIGHEST)
• SQA (Short Query Acceleration): query ngắn được lối đi riêng, không chờ sau query dài
• QMR (Query Monitoring Rules): rule như "query scan > 1TB hoặc chạy > 30 phút → log/abort/đổi priority" — chặn runaway query

Concurrency Scaling

• Khi queue đầy (giờ cao điểm BI), Redshift tự thêm cluster tạm xử lý query đọc (và một số ghi) — user không thấy khác biệt
• Tích lũy ~1 giờ miễn phí/ngày; sau đó tính phí theo giây
• Exam cue: "dashboard chậm vào giờ cao điểm, hàng trăm analyst đồng thời" → Concurrency Scaling (không phải resize cluster vĩnh viễn)

4. Materialized Views và tăng tốc query

• Materialized view (MV): lưu sẵn kết quả (join/aggregate) — refresh incremental (auto refresh được); auto query rewrite dùng MV ngay cả khi query gốc không gọi tên MV
• Pattern: dashboard lặp lại cùng aggregate nặng → MV giảm cả latency lẫn tải
• Result caching: leader cache kết quả — query lặp y hệt trả ngay (miễn phí, mặc định)

5. Data Sharing và hệ sinh thái

• Data sharing: chia sẻ live data giữa cluster/workgroup Redshift (cùng/khác account, cross-region) không copy — producer/consumer; nền tảng cho kiến trúc multi-warehouse (ETL cluster ghi, BI cluster đọc)
• Zero-ETL từ Aurora/RDS/DynamoDB → Redshift (đã học tuần 2)
• Query Iceberg/lake: qua Spectrum/Glue Catalog
• Backup: automated snapshots vào managed storage; cross-region snapshot copy cho DR

Câu hỏi ôn tập

1. Đội analytics chỉ chạy query vài giờ mỗi ngày, còn lại idle; không có DBA. Redshift dạng nào và vì sao?

   Xem đáp án

   Redshift Serverless — tính RPU-giây chỉ khi query chạy, idle không mất tiền compute; không quản cluster/WLM. Provisioned chạy 24/7 sẽ trả tiền cả lúc idle; pause/resume thủ công là vận hành thêm. Đây là đáp án "intermittent workload + least operational overhead".

2. 90% dữ liệu là lịch sử 5 năm hiếm khi query, 10% dữ liệu nóng query hằng ngày. Kiến trúc chi phí tốt nhất?

   Xem đáp án

   Dữ liệu nóng giữ trong Redshift local (RA3); dữ liệu lịch sử để trên S3 (Parquet, partitioned) query qua Spectrum khi cần — vẫn JOIN được với bảng local. Trả $5/TB scan thưa thớt rẻ hơn nhiều so với giữ 5 năm dữ liệu trong warehouse. Đây là pattern "hot in cluster, cold in lake".

3. Dashboard giờ cao điểm bị chậm vì hàng trăm query xếp hàng; ngoài giờ thì cluster rảnh. Giải pháp không resize?

   Xem đáp án

   Bật Concurrency Scaling — Redshift tự thêm transient cluster phục vụ query lúc queue đầy, tự thu hồi khi hết cao điểm; có ~1 giờ credit miễn phí mỗi ngày. Kèm Auto WLM + query priority để dashboard được ưu tiên và SQA cho query ngắn. Resize vĩnh viễn lãng phí vì ngoài giờ idle.

4. Một analyst hay chạy query quét cả bảng làm nghẽn cluster. Cách kiểm soát tự động?

   Xem đáp án

   Query Monitoring Rules (QMR) trong WLM: định nghĩa ngưỡng (rows scanned, execution time, nested loop join...) và hành động (log / change priority / hop / abort). Ví dụ: "scan > 100M rows và runtime > 10 phút → abort". Kết hợp query priority thấp cho nhóm ad-hoc.

5. Nhóm BI ở account khác cần đọc live data từ warehouse trung tâm, không được tạo bản copy. Tính năng nào?

   Xem đáp án

   Redshift data sharing: producer tạo datashare (schema/table), consumer (cluster/workgroup ở account khác — qua authorize + association) query live, không copy, không ETL. Compute của consumer tự trả — cô lập tải giữa các đội. UNLOAD/copy S3 tạo bản sao — sai yêu cầu "live, no copy".

6. Cùng một aggregate nặng được dashboard gọi mỗi 5 phút. Giảm chi phí/latency thế nào?

   Xem đáp án

   Tạo materialized view cho aggregate đó với auto refresh — query dashboard được auto query rewrite trỏ vào MV, chạy trong mili-giây thay vì scan lại bảng gốc. Result cache cũng giúp nếu query lặp y hệt và dữ liệu không đổi giữa các lần.

Bài tập thực hành

• Tạo Redshift Serverless workgroup (8 RPU), load bảng mẫu bằng COPY, query thử
• Tạo external schema trỏ Glue Catalog và query bảng S3 tuần trước qua Spectrum
• Tạo materialized view cho một aggregate, chạy query gốc và xem plan có rewrite không
• Đọc Redshift Serverless billing

Tài liệu tham khảo chính thức

• Amazon Redshift Serverless
• Redshift Spectrum
• Workload management
• Data sharing in Redshift

---

Tiếp theo: Amazon Athena