Snowflake 2 — Virtual Warehouse: compute co giãn

Virtual warehouse là gì

Trong bài tổng quan kiến trúc ta đã thấy Snowflake tách rời storage và compute. Bài này đi sâu vào lớp compute đó: virtual warehouse (thường gọi tắt là warehouse, viết tắt WH).

Một virtual warehouse là một cụm các node compute (server) do Snowflake cấp phát và quản lý toàn bộ để thực thi truy vấn: quét dữ liệu từ storage, join, aggregate, sort, và các thao tác DML (INSERT/UPDATE/MERGE), cũng như load/unload dữ liệu. Cần khắc sâu ngay vài điểm dễ hiểu sai:

• Warehouse không lưu dữ liệu lâu dài. Dữ liệu bảng nằm ở storage (micro-partition trên object storage như S3/GCS/Azure Blob). Warehouse chỉ mượn dữ liệu về RAM/SSD cục bộ trong lúc chạy query rồi thôi.
• Từ "warehouse" ở đây không phải "data warehouse" theo nghĩa kho dữ liệu. Nó thuần tuý là cụm compute. Đây là điểm gây nhầm lẫn kinh điển cho người mới.
• Một warehouse chỉ tồn tại về mặt tài nguyên khi nó ở trạng thái running. Khi suspend, Snowflake trả toàn bộ node về pool, bạn không mất tiền compute nữa (chỉ còn tiền storage cho dữ liệu, tính riêng).

Nhiều warehouse có thể cùng đọc cùng một bảng đồng thời mà không xung đột, vì storage là lớp chung bất biến. Đây chính là nền tảng cho việc tách workload mà ta bàn ở cuối bài.

Kích cỡ T-shirt và quy luật credit gấp đôi

Snowflake không bắt bạn chọn số CPU/RAM. Bạn chọn size theo hệ "cỡ áo T-shirt". Mỗi bậc lớn hơn thì số node (và do đó khả năng xử lý) gấp đôi, và credit tiêu thụ mỗi giờ cũng gấp đôi:

Hai hệ quả quan trọng của quy luật gấp đôi:

1. Giá không giảm khi to hơn — mà cũng không đắt lên nếu query scale tuyến tính. Một query nặng chạy trên M mất 8 phút, chạy trên L (gấp đôi tài nguyên) lý tưởng mất 4 phút. M: 4 credit/giờ × 8 phút; L: 8 credit/giờ × 4 phút — tổng credit bằng nhau nhưng L trả kết quả nhanh gấp đôi. Đây là lý do "scale up" nghe có vẻ đắt nhưng thường không tốn thêm tiền cho query scale tốt, mà chỉ đổi lấy tốc độ.
2. Nhưng chỉ khi query thực sự tận dụng được thêm node. Query nhỏ, hoặc bị nghẽn ở khâu không song song hoá được, chạy trên L sẽ không nhanh gấp đôi → khi đó L lãng phí tiền.

Credit là đơn vị tính compute của Snowflake. Bạn không trả tiền theo giờ node mà theo credit tiêu thụ, tính theo giây (billing per-second, tối thiểu 60 giây cho mỗi lần resume). Giá 1 credit bằng bao nhiêu USD tuỳ edition (Standard/Enterprise/Business Critical) và region/cloud — con số cụ thể xem hợp đồng, ta không nêu số ở đây để tránh sai lệch. Chi tiết tối ưu chi phí xem bài cost management.

Auto-suspend và auto-resume

Đây là tính năng tiết kiệm tiền lớn nhất và phải bật cho gần như mọi warehouse.

• Auto-suspend: nếu warehouse không có query nào trong AUTO_SUSPEND giây, Snowflake tự tắt cụm compute → ngừng tính credit. Đơn vị là giây.
• Auto-resume: khi có query mới gửi tới một warehouse đang suspended, Snowflake tự bật lại trong vài giây, người dùng không phải làm gì.

Ý nghĩa thực tế: bạn có thể để warehouse "luôn sẵn sàng" về mặt logic mà chỉ trả tiền cho thời gian thực sự có query chạy. Một warehouse phục vụ dashboard BI có thể chỉ chạy vài phút mỗi giờ (khi có người mở báo cáo) và suspend suốt phần còn lại.

Cân nhắc khi đặt AUTO_SUSPEND:

• Đặt quá thấp (ví dụ 10–30 giây): warehouse suspend rồi resume liên tục. Mỗi lần resume có billing tối thiểu 60 giây và cache cục bộ bị xoá (mất "warm cache") → query kế tiếp chậm hơn vì phải quét lại từ storage.
• Đặt quá cao (ví dụ vài phút): warehouse chạy không tải lâu → tốn credit vô ích.
• Thực tế thường dùng: 60 giây cho warehouse tương tác (BI, ad-hoc) để giữ cache ấm giữa các lần bấm; ngắn hơn cho ETL chạy theo batch rời rạc; hoặc thậm chí cân nhắc không suspend với warehouse có tải gần như liên tục cả ngày.

Scaling UP vs Scaling OUT

Đây là phân biệt cốt lõi và hay bị lẫn.

Scaling UP — đổi size (giải quyết query nặng)

Scaling up nghĩa là tăng kích cỡ warehouse (ví dụ M → L). Mục tiêu: làm một query đơn lẻ nặng chạy nhanh hơn, vì có nhiều node hơn để song song hoá quét/join/sort.

Khi nào dùng: query mất quá lâu, hoặc bị spill to disk/remote (khi dữ liệu trung gian vượt RAM, Snowflake tràn ra SSD cục bộ rồi ra remote storage — dấu hiệu warehouse quá nhỏ so với query, xem bài performance).

Scaling up không giúp giải quyết vấn đề nhiều query cùng lúc xếp hàng chờ.

Scaling OUT — multi-cluster warehouse (giải quyết concurrency)

Scaling out nghĩa là cho warehouse nhiều cụm (cluster) cùng size chạy song song, gọi là multi-cluster warehouse. Mục tiêu: phục vụ nhiều query đồng thời khi số người dùng tăng, tránh xếp hàng (queuing).

Cơ chế: bạn đặt MIN_CLUSTER_COUNT và MAX_CLUSTER_COUNT. Snowflake tự thêm cluster khi query bắt đầu xếp hàng và tự bớt cluster khi tải giảm. Ví dụ MIN=1, MAX=3 trên warehouse size M: bình thường 1 cluster (4 credit/giờ), giờ cao điểm có thể bung lên 3 cluster (tối đa 12 credit/giờ).

Lưu ý: multi-cluster là tính năng của edition Enterprise trở lên.

Hai thứ kết hợp được: một warehouse có thể vừa size L vừa multi-cluster 1–4 — mỗi query nặng chạy nhanh (L), và nhiều query cùng lúc không phải chờ (nhiều cluster).

Scaling policy: Standard vs Economy

Với multi-cluster ở chế độ tự động (SCALING_POLICY), Snowflake cho hai chính sách quyết định khi nào bung thêm và khi nào thu bớt cluster:

• Standard (mặc định): ưu tiên hiệu năng/độ trễ. Bung cluster mới ngay khi phát hiện query sắp phải xếp hàng (gần như tức thì). Thu cluster sau khi cluster đó rảnh liên tục vài lần kiểm tra. Phù hợp workload tương tác cần phản hồi nhanh — BI dashboard, truy vấn phục vụ nghiệp vụ.
• Economy: ưu tiên tiết kiệm credit. Chỉ bung cluster mới khi Snowflake ước tính có đủ tải để giữ cluster đó bận ít nhất vài phút → cluster mới lên chậm hơn, có thể để query chờ lâu hơn một chút, đổi lại ít bị "bung rồi tắt" lãng phí. Phù hợp workload batch/không nhạy độ trễ.

Nguyên tắc chọn: Standard cho trải nghiệm người dùng; Economy cho tối ưu chi phí batch. Nếu người dùng phàn nàn dashboard chậm giờ cao điểm mà đang để Economy → chuyển Standard.

Tách warehouse theo workload

Đây là best practice quan trọng nhất về vận hành warehouse. Vì storage là lớp chung, ta có thể tạo nhiều warehouse độc lập cùng đọc một dữ liệu mà không tranh chấp compute với nhau.

Vấn đề nếu dùng chung 1 warehouse: job ETL nặng ban đêm và query ad-hoc của analyst cùng đổ vào một warehouse → chúng giành node của nhau, ETL làm dashboard giật, hoặc một analyst chạy query "quét cả bảng" làm chậm pipeline. Còn về chi phí, gộp chung khiến bạn không quy được credit về từng đội/mục đích để tính toán và tối ưu.

Mẫu tách thường dùng ở một đội dữ liệu ngân hàng:

Lợi ích:

• Cô lập hiệu năng: đội này không làm chậm đội kia.
• Right-sizing từng loại: ETL cần size to; ad-hoc để nhỏ + auto-suspend gắt; BI cần multi-cluster để chịu concurrency.
• Chi phí minh bạch: mỗi warehouse là một "trung tâm chi phí" — dễ gán về đội, dễ đặt resource monitor và hạn mức riêng.
• Kết hợp với RBAC (bài security): cấp quyền USAGE warehouse theo role, kiểm soát ai được dùng warehouse to.

Cân nhắc chọn size

Không có công thức tuyệt đối, nhưng khung tư duy thực chiến:

1. Bắt đầu nhỏ, đo, rồi tăng. Chạy query đại diện trên XS/S, xem thời gian và có spill to disk không. Nếu chậm và có spill → tăng một bậc, đo lại. Nhớ quy luật credit gấp đôi: nếu tăng size làm query nhanh gấp đôi thì tổng credit không đổi mà nhanh hơn → đáng.
2. Ngừng tăng khi hết lợi. Đến lúc tăng size không làm query nhanh thêm tương xứng (do query không song song hoá tốt, hoặc dữ liệu quá nhỏ) → size to hơn chỉ đốt credit.
3. Query nhỏ, ngắn, nhiều người → đừng tăng size, hãy scale out (multi-cluster). Tăng size cho workload concurrency là sai công cụ.
4. Batch load lớn → size to, chạy nhanh, suspend ngay. Vì tính theo giây, chạy nhanh trên warehouse to rồi tắt thường rẻ hơn chạy lê thê trên warehouse nhỏ.
5. Tách warehouse theo độ nặng công việc, đừng nhét mọi thứ vào một size.

Ví dụ lệnh (minh hoạ, cú pháp Snowflake)

Các lệnh dưới đây dùng cú pháp Snowflake — chỉ để minh hoạ, không chạy được trong sandbox PostgreSQL read-only của trang này.

Tạo warehouse cho ETL, size L, tự tắt sau 60 giây và không tự bật khi mở console:

-- Minh hoạ Snowflake — KHÔNG chạy trong sandbox
CREATE WAREHOUSE WH_ETL
  WAREHOUSE_SIZE = 'LARGE'
  AUTO_SUSPEND = 60          -- giây
  AUTO_RESUME = TRUE
  INITIALLY_SUSPENDED = TRUE;

Tạo warehouse BI multi-cluster, ưu tiên độ trễ (Standard):

-- Minh hoạ Snowflake — KHÔNG chạy trong sandbox
CREATE WAREHOUSE WH_BI
  WAREHOUSE_SIZE = 'MEDIUM'
  MIN_CLUSTER_COUNT = 1
  MAX_CLUSTER_COUNT = 4
  SCALING_POLICY = 'STANDARD'
  AUTO_SUSPEND = 60
  AUTO_RESUME = TRUE;

Scaling UP tạm thời cho một job nặng rồi trả lại:

-- Minh hoạ Snowflake — KHÔNG chạy trong sandbox
ALTER WAREHOUSE WH_ETL SET WAREHOUSE_SIZE = 'XLARGE';
-- ... chạy job nặng ...
ALTER WAREHOUSE WH_ETL SET WAREHOUSE_SIZE = 'LARGE';

Đổi scaling policy sang Economy cho một warehouse batch:

-- Minh hoạ Snowflake — KHÔNG chạy trong sandbox
ALTER WAREHOUSE WH_BATCH SET SCALING_POLICY = 'ECONOMY';

Use case thực tế

Bối cảnh (NCB): Đội dữ liệu ban đầu dùng một warehouse duy nhất size XL (16 credit/giờ) cho tất cả: ETL đêm, dashboard giám sát giao dịch, và analyst chạy query rủi ro tín dụng. Ba vấn đề:

• Giờ cao điểm sáng (8–10h), 30 analyst và ~50 phiên dashboard cùng chạy → query xếp hàng, dashboard mất 20–40 giây mới hiện.
• Một analyst chạy query quét toàn bộ bảng transactions 3 năm làm pipeline ETL trong ngày chậm theo.
• Kế toán không tách được credit đội nào tiêu bao nhiêu.

Giải pháp — tách thành 3 warehouse:

Kết quả (số minh hoạ theo cách tính credit):

• Dashboard hết queue: WH_BI bung 1→3 cluster lúc cao điểm, mỗi query < 5 giây. Cao điểm ~2 giờ/ngày × trung bình 2 cluster × 4 credit = ~16 credit; ngoài giờ 1 cluster và phần lớn thời gian suspended.
• ETL không còn bị analyst làm chậm vì đã cô lập compute; job đêm chạy trên L, xong là suspend.
• WH_ADHOC để size S + Economy → query nặng của analyst chậm hơn chút nhưng không đội chi phí và không ảnh hưởng ai; đặt kèm resource monitor giới hạn credit/tháng.
• Kế toán giờ đọc được credit theo từng warehouse trong WAREHOUSE_METERING_HISTORY → quy về từng đội.

Bài học: vấn đề "dashboard chậm" không giải bằng tăng XL lên 2XL (scale up — sai công cụ, tốn gấp đôi credit mà vẫn queue), mà bằng tách workload + scale out đúng chỗ.

Ghi nhớ

• Virtual warehouse = cụm compute, không lưu dữ liệu; dữ liệu ở storage chung. "Warehouse" ở đây không phải "data warehouse".
• Size theo cỡ áo XS→6XL: mỗi bậc lớn hơn gấp đôi node và gấp đôi credit/giờ. Query scale tốt thì to hơn = nhanh hơn với tổng credit gần như không đổi.
• Auto-suspend + auto-resume là chìa khoá tiết kiệm: chỉ trả tiền khi có query. Đặt AUTO_SUSPEND khoảng 60s cho warehouse tương tác để giữ cache ấm; đừng đặt quá thấp (thrash) hay quá cao (chạy không tải).
• Scaling UP (đổi size) cho 1 query nặng; scaling OUT (multi-cluster) cho nhiều query đồng thời. Đừng lẫn công cụ.
• Scaling policy Standard ưu tiên độ trễ (BI); Economy ưu tiên tiết kiệm (batch).
• Tách warehouse theo workload (ETL/BI/ad-hoc/ML) để cô lập hiệu năng, right-size, và minh bạch chi phí.
• Billing tính theo giây (tối thiểu 60s mỗi lần resume); credit → USD tuỳ edition và region.