Snowflake 6 — Quản trị chi phí & credit

Vì sao chi phí Snowflake dễ vượt tầm kiểm soát

Snowflake bán cho ta một lời hứa hấp dẫn: tách rời compute và storage, warehouse bật/tắt tức thì, mở rộng vô hạn trong vài giây. Nhưng chính sự tiện lợi đó là con dao hai lưỡi. Trong mô hình on-premise cũ (Oracle Exadata, Teradata), ngân sách hạ tầng cố định từ đầu năm — bạn mua một cụm máy, dùng bao nhiêu cũng vậy. Với Snowflake, mỗi câu query là một khoản chi tiêu, và hóa đơn chỉ hiện ra vào cuối tháng, khi đã quá muộn để phanh lại.

Với một ngân hàng như NCB, nơi hàng trăm analyst, mô hình rủi ro, pipeline ETL và dashboard cùng đâm vào một tài khoản Snowflake, câu hỏi không còn là "hệ thống có chạy không" mà là "ai đang tiêu tiền của ai, và có đáng không". Đây chính là địa hạt của FinOps — kỷ luật tài chính cho hạ tầng cloud. Bài này mổ xẻ mô hình chi phí Snowflake tới từng đơn vị nhỏ nhất, rồi trang bị cho bạn các công cụ để kiểm soát nó. Nếu chưa nắm về warehouse, hãy xem lại Snowflake — Virtual Warehouses; phần tối ưu bytes scanned kết nối chặt với Snowflake — Hiệu năng & tối ưu.

Mô hình chi phí: bốn dòng tiền

Hóa đơn Snowflake không phải một con số duy nhất. Nó là tổng của bốn nguồn phát sinh riêng biệt, và hiểu rõ từng nguồn là bước đầu tiên để tối ưu.

1. Compute credit — nguồn chi lớn nhất

Đây là chi phí cho warehouse (cụm máy tính ảo) chạy. Snowflake không tính bằng tiền trực tiếp mà bằng credit — một đơn vị trừu tượng. Cơ chế:

• Mỗi kích cỡ warehouse tiêu một số credit/giờ cố định: XS = 1 credit/giờ, S = 2, M = 4, L = 8, XL = 16... nhân đôi mỗi cấp. Multi-cluster warehouse với N cluster đang chạy thì nhân N.
• Tính tiền theo giây, nhưng có sàn tối thiểu 60 giây mỗi lần warehouse chuyển từ trạng thái nghỉ sang chạy (resume). Sau 60 giây đầu, tính chính xác từng giây.
• Warehouse ở trạng thái suspend (nghỉ) tiêu 0 credit.

Sàn 60 giây là chi tiết dễ bị bỏ qua nhưng cực kỳ quan trọng cho chiến lược auto-suspend (mục sau). Một warehouse XS bật lên chạy một query 3 giây rồi tắt vẫn bị tính đủ 60 giây.

2. Storage — rẻ nhưng âm thầm phình

Storage tính theo dung lượng đã nén (Snowflake nén dữ liệu columnar rất tốt, thường 3–5 lần), đơn vị TB/tháng, dựa trên dung lượng trung bình hàng ngày. Điểm cần nhớ: storage không chỉ gồm bảng hiện tại mà còn:

• Time Travel: bản sao dữ liệu giữ lại 0–90 ngày để khôi phục (xem Time Travel & Data Sharing).
• Fail-safe: thêm 7 ngày Snowflake giữ để phục hồi thảm họa, ta không truy cập được nhưng vẫn tính tiền.
• Staged files: file trong internal stage chưa xóa.

So với compute, storage thường chỉ chiếm 5–15% hóa đơn, nhưng một bảng lớn với DATA_RETENTION_TIME_IN_DAYS = 90 có thể nhân đôi, nhân ba storage thực tế.

3. Cloud Services — thường miễn phí

Đây là lớp điều phối: parsing SQL, tối ưu query, quản lý metadata, xác thực. Snowflake tính credit cho lớp này nhưng miễn phí phần bằng hoặc dưới 10% tổng compute credit hàng ngày. Với workload bình thường, phần này gần như luôn được miễn. Nó chỉ phát sinh chi phí khi bạn chạy quá nhiều thao tác metadata thuần (ví dụ hàng loạt SHOW, INFORMATION_SCHEMA query, hoặc DDL liên tục) mà không dùng warehouse tương xứng.

4. Serverless — compute Snowflake tự quản

Một số tính năng chạy compute do Snowflake quản lý, không gắn với warehouse của bạn, tính theo credit riêng:

• Snowpipe: nạp dữ liệu tự động (streaming/micro-batch), tính theo compute xử lý + phí per-file.
• Automatic Clustering (reclustering): sắp xếp lại micro-partition theo clustering key.
• Materialized View maintenance, Search Optimization Service, Snowpipe Streaming, serverless tasks.

Các dịch vụ serverless đôi khi có hệ số credit khác warehouse thường (thường cao hơn cho mỗi giây compute), nên đừng giả định 1 credit serverless = 1 credit warehouse khi ước tính.

Credit là gì và quy đổi ra tiền

Credit là đơn vị đo compute chuẩn hóa, tách khỏi tiền tệ để Snowflake bán được ở nhiều region và loại tiền. Số tiền cho một credit phụ thuộc ba yếu tố:

Vì đơn giá thay đổi theo hợp đồng và region, bài này không nêu con số cụ thể — đội FinOps phải lấy chính xác từ hợp đồng Snowflake và bảng giá của cloud provider tương ứng. Điều quan trọng về mặt kiến trúc: một ngân hàng thường buộc dùng Business Critical hoặc cao hơn để có PrivateLink, HIPAA/PCI-DSS compliance, customer-managed key (Tri-Secret Secure). Điều đó đẩy đơn giá credit lên cao — nên mỗi credit tiết kiệm được ở ngân hàng "đắt" hơn ở một startup dùng Standard. Chi tiết bảo mật/edition xem Bảo mật & Governance.

Resource Monitor — người gác cổng ngân sách

Đây là công cụ trung tâm để chặn chi tiêu vượt mức trước khi nó xảy ra. Resource Monitor theo dõi số credit compute tiêu thụ trong một chu kỳ (frequency) và kích hoạt hành động khi chạm ngưỡng phần trăm của một quota.

Ví dụ minh hoạ (Snowflake SQL — KHÔNG chạy được trong sandbox, chỉ để tham khảo cú pháp):

-- Ví dụ minh hoạ, KHÔNG phải SQL sandbox
CREATE OR REPLACE RESOURCE MONITOR rm_team_risk
  WITH
    CREDIT_QUOTA = 500           -- 500 credit mỗi chu kỳ
    FREQUENCY = MONTHLY          -- chu kỳ theo tháng
    START_TIMESTAMP = IMMEDIATELY
  TRIGGERS
    ON 60  PERCENT DO NOTIFY               -- 60%: gửi cảnh báo
    ON 85  PERCENT DO NOTIFY               -- 85%: cảnh báo lần 2
    ON 100 PERCENT DO SUSPEND              -- 100%: dừng nhẹ (chờ query xong)
    ON 110 PERCENT DO SUSPEND_IMMEDIATE;   -- 110%: cắt ngay, hủy query đang chạy

-- Gắn monitor vào warehouse
ALTER WAREHOUSE wh_risk_analytics SET RESOURCE_MONITOR = rm_team_risk;

Các điểm cốt lõi:

• CREDIT_QUOTA là hạn mức credit cho mỗi chu kỳ, không phải tiền — bạn phải tự quy đổi ra ngân sách VND.
• FREQUENCY có thể là DAILY, WEEKLY, MONTHLY, YEARLY, hoặc NEVER (quota không reset).
• Action gồm: NOTIFY (chỉ gửi email/thông báo, không dừng gì), SUSPEND (chờ query hiện tại xong rồi dừng warehouse), SUSPEND_IMMEDIATE (hủy query đang chạy, dừng ngay).
• Một monitor có thể gắn cho nhiều warehouse, hoặc đặt ở cấp account (giám sát toàn tài khoản). Warehouse chỉ gắn được một monitor.

Cảnh báo thực chiến: SUSPEND_IMMEDIATE sẽ giết query đang chạy giữa chừng — với một job ETL nạp sổ cái đêm khuya, điều này có thể để lại dữ liệu dở dang. Vì vậy hãy đặt ngưỡng suspend ở mức đệm an toàn (110–120%) và dựa chủ yếu vào NOTIFY để con người can thiệp sớm. Resource Monitor là phanh khẩn cấp, không phải công cụ tối ưu hằng ngày.

Auto-suspend: đòn bẩy tiết kiệm dễ nhất

Vì warehouse suspend không tốn credit, cách tiết kiệm đơn giản và hiệu quả nhất là để warehouse ngủ càng nhanh càng tốt khi không có việc. Cấu hình AUTO_SUSPEND (giây) quyết định sau bao lâu không hoạt động thì warehouse tự tắt.

Nhưng nhớ sàn 60 giây: mỗi lần resume tính tối thiểu một phút. Do đó cần cân bằng giữa hai chi phí đối nghịch:

• Auto-suspend quá dài (ví dụ 600s): warehouse chạy không tải, đốt credit vô ích.
• Auto-suspend quá ngắn (ví dụ 1s): warehouse tắt-bật liên tục, mỗi lần bật lại bị tính sàn 60s + mất cache (local disk cache biến mất khi suspend, query sau phải đọc lại từ storage → chậm và tốn hơn).

Nguyên tắc thực tế:

Snowflake cho phép đặt xuống thấp tới vài giây, nhưng dưới 60s hầu như không tiết kiệm thêm mà lại phá cache. 60s là điểm khởi đầu hợp lý cho đa số warehouse.

Tách warehouse theo team để charge-back

Đây là quyết định kiến trúc quan trọng nhất về mặt FinOps. Snowflake gộp chi phí ở cấp warehouse, nên nếu mọi người dùng chung một warehouse khổng lồ, bạn không thể biết ai tiêu bao nhiêu. Giải pháp: cấp warehouse riêng cho từng team/workload.

Lợi ích của tách warehouse:

1. Charge-back / show-back: quy chi phí về đúng phòng ban (Rủi ro, AML, Kinh doanh, Kế toán). Ngân hàng thường phải phân bổ chi phí IT về từng khối nghiệp vụ.
2. Cách ly hiệu năng: job ETL nặng không làm chậm dashboard của lãnh đạo.
3. Gắn Resource Monitor riêng: mỗi team có quota riêng, team này tiêu hết không ảnh hưởng team khác.
4. Sizing đúng nhu cầu: dashboard cần warehouse nhỏ đáp ứng đồng thời (multi-cluster); mô hình rủi ro cần warehouse to chạy ngắn.

Đặt tên có quy ước (WH_<PHÒNG>_<MỤC ĐÍCH>) để dễ đối soát. Kết hợp với query tag — mỗi query/session gán QUERY_TAG chứa mã dự án — cho phép phân bổ chi phí chi tiết hơn cả cấp warehouse.

Phân tích chi phí bằng ACCOUNT_USAGE

Snowflake phơi bày toàn bộ dữ liệu tiêu thụ qua schema SNOWFLAKE.ACCOUNT_USAGE (độ trễ tới ~45 phút–3 giờ, giữ 365 ngày) và SNOWFLAKE.ORGANIZATION_USAGE (cho nhiều account). Các view chủ lực:

Ví dụ minh hoạ săn query tốn kém (Snowflake SQL — KHÔNG chạy được trong sandbox):

-- Ví dụ minh hoạ, KHÔNG phải SQL sandbox
SELECT
    query_id,
    user_name,
    warehouse_name,
    warehouse_size,
    bytes_scanned / POWER(1024, 3)              AS gb_scanned,
    total_elapsed_time / 1000                   AS elapsed_sec,
    bytes_spilled_to_local_storage  > 0         AS spilled_local,
    bytes_spilled_to_remote_storage > 0         AS spilled_remote
FROM snowflake.account_usage.query_history
WHERE start_time >= DATEADD('day', -7, CURRENT_TIMESTAMP())
  AND warehouse_size IS NOT NULL
ORDER BY bytes_scanned DESC
LIMIT 50;

Query trên trả về 50 query đọc nhiều dữ liệu nhất tuần qua. bytes_scanned là chỉ số tài chính then chốt: bytes scanned càng nhiều thì warehouse phải chạy càng lâu → càng nhiều credit. Cột spilled_remote báo hiệu query tràn bộ nhớ ra remote storage — dấu hiệu warehouse quá nhỏ hoặc query viết tồi, cực kỳ tốn kém.

Tối ưu để giảm chi phí

Hai đòn bẩy lớn nhất, theo thứ tự ưu tiên:

1. Giảm bytes scanned. Vì tiền ~ compute time ~ dữ liệu đọc, mọi kỹ thuật giảm dữ liệu quét đều trực tiếp cắt hóa đơn:

• Pruning theo cột phân vùng: lọc trên cột tương quan với thứ tự nạp (thường là ngày) để Snowflake bỏ qua micro-partition không liên quan. Ví dụ luôn có WHERE txn_date >= ... trên bảng giao dịch lớn.
• Chọn cột cụ thể thay vì SELECT *: lưu trữ columnar chỉ đọc cột được nêu tên.
• Clustering key cho bảng cực lớn truy vấn theo cùng một cột (đánh đổi với phí reclustering serverless).
• Chi tiết kỹ thuật ở Snowflake — Hiệu năng & tối ưu.

2. Diệt warehouse chạy không tải. Auto-suspend hợp lý, gộp các job nhỏ, right-size (đừng dùng XL cho query mà M chạy vừa đủ). Nghịch lý hữu ích: warehouse to hơn không luôn đắt hơn — nếu XL chạy xong trong 2 phút còn M mất 10 phút cho cùng job, XL (16 credit/giờ × 2 phút) có thể rẻ hơn M (4 × 10 phút). Đây là nguyên tắc "chạy nhanh rồi tắt" thay vì "chạy nhỏ nhưng lâu". Hãy đo bằng QUERY_HISTORY trước khi kết luận.

3. Dọn storage. Đặt DATA_RETENTION_TIME_IN_DAYS hợp lý cho từng bảng (bảng staging tạm chỉ cần 1 ngày Time Travel), xóa stage cũ, dùng TRANSIENT table cho dữ liệu tái tạo được (không có Fail-safe).

Use case thực tế

Bối cảnh. Đội Data của NCB phát hiện hóa đơn Snowflake tháng 5 tăng 40% so với tháng 4 mà không có dự án mới. Ban lãnh đạo yêu cầu giải trình trong 3 ngày.

Bước 1 — Định vị nguồn tăng. Query METERING_DAILY_HISTORY cho thấy compute credit tăng đột biến từ ngày 12/5, tập trung vào warehouse WH_SHARED_ANALYTICS — một warehouse dùng chung cho cả AML, Rủi ro và BI. Vì dùng chung nên không rõ ai gây ra.

Bước 2 — Truy vết bằng QUERY_HISTORY. Lọc query trên warehouse đó, sắp theo bytes_scanned. Phát hiện một dashboard BI mới refresh mỗi 5 phút, mỗi lần chạy SELECT * quét toàn bộ bảng giao dịch 2 TB không có filter ngày. Con số: ~288 lần/ngày × 2 TB = ~576 TB scanned/ngày chỉ cho một dashboard.

Bước 3 — Xử lý.

• Sửa query dashboard: thêm WHERE txn_date >= DATEADD('month', -3, ...) và chọn đúng cột → bytes scanned giảm ~95%.
• Giãn tần suất refresh từ 5 phút xuống 30 phút.
• Tách warehouse: tạo WH_BI_DASHBOARD (M, multi-cluster, auto-suspend 120s) riêng cho BI, gắn Resource Monitor CREDIT_QUOTA theo ngân sách khối, trigger NOTIFY tại 75% và SUSPEND tại 100%.
• Hạ AUTO_SUSPEND của các warehouse ETL từ 300s về 60s.

Kết quả (đo sau 2 tuần). Compute credit về mức trước sự cố, và quan trọng hơn: giờ mỗi khối có warehouse riêng nên báo cáo charge-back tháng 6 quy được chính xác chi phí về từng phòng — cuộc họp giải trình lần sau chỉ mất 15 phút thay vì 3 ngày điều tra.

Ghi nhớ

• Hóa đơn Snowflake = compute credit (chủ đạo) + storage + cloud services (thường miễn) + serverless (Snowpipe, reclustering...).
• Compute tính theo giây nhưng sàn tối thiểu 60s mỗi lần resume; warehouse suspend tốn 0 credit; mỗi cấp size nhân đôi credit/giờ.
• Credit là đơn vị trừu tượng; tiền/credit phụ thuộc edition + cloud/region + mô hình mua. Ngân hàng thường ở edition cao (Business Critical) nên credit đắt — đừng bịa con số, lấy từ hợp đồng.
• Resource Monitor đặt CREDIT_QUOTA theo chu kỳ với trigger NOTIFY/SUSPEND/SUSPEND_IMMEDIATE. Là phanh khẩn cấp; ưu tiên NOTIFY, cẩn thận SUSPEND_IMMEDIATE giết query dở dang.
• Auto-suspend 60s là điểm khởi đầu tốt: đủ ngắn để tiết kiệm, đủ dài để không phá cache và không bị đánh sàn 60s liên tục.
• Tách warehouse theo team là nền tảng cho charge-back, cách ly hiệu năng và quota riêng; kết hợp QUERY_TAG để phân bổ chi tiết hơn.
• Phân tích chi phí qua ACCOUNT_USAGE: WAREHOUSE_METERING_HISTORY (charge-back), QUERY_HISTORY (săn query tốn kém, xem bytes_scanned và spill).
• Tối ưu: giảm bytes scanned (filter phân vùng, tránh SELECT *), diệt warehouse chạy không tải, cân nhắc "chạy nhanh rồi tắt", dọn Time Travel/stage.