</>Học Dev
Bài học

Tuần 5 - Ngày 1: Redshift — Kiến trúc, Distribution và Sort Keys

Tuần 5 – Ngày 1

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

  • Hiểu kiến trúc MPP của Redshift: leader node, compute nodes, slices
  • Chọn đúng distribution style: AUTO, EVEN, KEY, ALL
  • Chọn sort key và hiểu zone maps
  • Biết compression encoding, VACUUM, ANALYZE

1. Kiến trúc MPP

SQLclients/BI(JDBC/ODBC,DataAPI)│┌────────▼────────┐│LEADERNODE│parse,plan,tổnghợpkếtquả└────────┬────────┘┌─────────────────┼─────────────────┐▼▼▼┌────────────┐┌────────────┐┌────────────┐│COMPUTE1││COMPUTE2││COMPUTE3│(RA3nodes)│slice|slice││slice|slice││slice|slice│└─────┬──────┘└─────┬──────┘└─────┬──────┘└──────────RedshiftManagedStorage(S3-backed,RA3)─────────
  • Leader node: nhận query, build plan, phân phối cho compute, tổng hợp — không tính phí riêng
  • Compute node chia thành slices; mỗi slice giữ một phần dữ liệu và xử lý song song
  • RA3 nodes: tách compute/storage (Redshift Managed Storage trên S3) — scale độc lập; thế hệ khuyến nghị
  • Columnar storage + compression + zone maps (min/max per block) → analytics nhanh

2. Distribution styles — dữ liệu nằm ở đâu

StyleCách phân phốiKhi dùng
AUTORedshift tự chọn (mặc định, đổi theo size)Không chắc chắn — cứ để AUTO
EVENRound-robin đều các sliceBảng lớn không join thường xuyên
KEYHash theo cột DISTKEY — cùng giá trị cùng sliceBảng fact join theo cột đó — join local, không shuffle
ALLCopy toàn bộ bảng lên mọi nodeBảng dimension nhỏ, ít thay đổi

Nguyên tắc thiết kế join

fact_salesDISTKEY(customer_id)──join──dim_customerDISTKEY(customer_id)→joinco-located,khôngtruyềndữliệugiữanode(DS_DIST_NONE)dim_date(nhỏ,vàinghìndòng)→DISTSTYLEALL→joinlocalvớimọibảng
  • Data skew: DISTKEY cardinality thấp/lệch (vd country khi 90% là VN) → 1 slice ôm hết → query chậm. Kiểm tra bằng svv_table_info (skew_rows)
  • Trong EXPLAIN: DS_BCAST_INNER/DS_DIST_BOTH = đang broadcast/shuffle → cân nhắc lại distkey

3. Sort keys — dữ liệu xếp thế nào trong block

  • Compound sort key (mặc định): sắp theo thứ tự các cột — mạnh khi filter theo prefix (cột đầu); chuẩn cho cột thời gian: SORTKEY(event_date)
  • Interleaved: cân bằng nhiều cột filter độc lập — ít khuyến nghị hiện nay (chi phí VACUUM REINDEX cao); AUTO sort key là mặc định tốt
  • Zone maps: Redshift lưu min/max mỗi block 1MB; sort key làm dữ liệu liền mạch → skip block hiệu quả khi WHERE theo cột sort

Exam cue: "queries filter by date range chậm" → sort key theo cột date; "join lớn chậm, thấy DS_BCAST" → distkey theo cột join.

4. Compression, VACUUM, ANALYZE

  • Compression encoding per column (AZ64, LZO, ZSTD...): giảm I/O; COPY với COMPUPDATE tự chọn; mặc định AUTO cho bảng mới
  • VACUUM: dọn row đã delete/update (ghi mới + đánh dấu xóa) và sắp lại theo sort key — Redshift hiện auto vacuum/auto sort nền, nhưng sau delete lớn vẫn có thể chạy tay
  • ANALYZE: cập nhật statistics cho planner — auto analyze có sẵn

5. Nạp và xuất dữ liệu

  • COPY từ S3: chuẩn nạp batch (song song theo slice — tuần 2); hỗ trợ Parquet/ORC/CSV/JSON/Avro
  • UNLOAD ra S3: xuất kết quả query thành file (Parquet được) — pattern đẩy data mart ra lake
  • Redshift Data API: gọi SQL qua HTTPS/SDK không cần driver/connection — hợp Lambda/Step Functions
  • Streaming ingestion: materialized view trên Kinesis/MSK — đọc stream trực tiếp vào MV (near real-time, không qua S3)

Câu hỏi ôn tập

  1. Bảng fact 2 tỷ dòng join chủ yếu với dim_customer theo customer_id; dim_date chỉ 10 nghìn dòng. Thiết kế distribution?

    Xem đáp án

    fact và dim_customer cùng DISTKEY(customer_id) → join co-located không shuffle. dim_date DISTSTYLE ALL — bảng nhỏ copy lên mọi node, join local với bất kỳ bảng nào. Đây là pattern thiết kế warehouse kinh điển của đề Redshift.

  2. Query lọc WHERE event_date BETWEEN ... trên bảng 500GB rất chậm. Cải thiện bằng gì?

    Xem đáp án

    Đặt SORTKEY(event_date) (compound): dữ liệu xếp theo ngày làm zone maps (min/max per block) loại bỏ hầu hết block ngoài dải ngày — I/O giảm mạnh. Distribution key không giúp cho filter đơn bảng; nó phục vụ join/aggregate phân tán.

  3. Sau khi chọn DISTKEY là cột status (5 giá trị), một số query chậm hơn hẳn. Vì sao?

    Xem đáp án

    Data skew: 5 giá trị hash về tối đa 5 slice — các slice khác không có dữ liệu, và giá trị phổ biến nhất dồn cực nhiều dòng vào 1 slice, làm slice đó thành bottleneck của mọi query song song. DISTKEY cần cột cardinality cao, phân bố đều và được dùng trong join — không phải cột trạng thái. Kiểm tra svv_table_info.skew_rows.

  4. UPDATE/DELETE nhiều trên bảng Redshift để lại hệ quả gì và xử lý thế nào?

    Xem đáp án

    Redshift là columnar MVCC kiểu append: UPDATE = insert bản mới + đánh dấu xóa bản cũ → dead rows chiếm chỗ, bảng "phình", sort order vỡ. VACUUM thu hồi chỗ và re-sort (auto vacuum chạy nền; sau batch delete lớn có thể VACUUM thủ công), ANALYZE cập nhật thống kê. Thiết kế tốt hơn: tránh update dàn trải, dùng pattern staging + swap hoặc materialized view.

  5. Lambda cần chạy SQL trên Redshift mà không quản lý connection/driver trong VPC. Cách gọi?

    Xem đáp án

    Redshift Data API — gọi qua HTTPS (SDK/CLI), async, IAM auth (hoặc Secrets Manager), không cần JDBC connection pool hay Lambda trong VPC. Nhận kết quả bằng GetStatementResult hoặc event khi xong. Chuẩn cho serverless orchestration (Step Functions cũng tích hợp trực tiếp).

  6. Cần đưa dữ liệu Kinesis vào Redshift near real-time không qua S3. Tính năng nào?

    Xem đáp án

    Redshift streaming ingestion: tạo materialized view trên Kinesis Data Streams (hoặc MSK) — Redshift đọc stream trực tiếp, refresh MV (tự động được) với độ trễ giây. So với Firehose→S3→COPY: ít bước hơn, latency thấp hơn.

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

  • Vẽ lại kiến trúc leader/compute/slice/RA3 từ trí nhớ
  • Viết DDL: bảng fact (DISTKEY + SORTKEY) và 2 dimension (KEY + ALL) cho schema bán hàng
  • Đọc EXPLAIN một join và xác định DS_DIST_NONE vs DS_BCAST_INNER
  • Đọc Amazon Redshift best practices for designing tables

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

Tiếp theo: Redshift Serverless, Spectrum và WLM