Published khoảng 1 giờ trước 16 min read

Google BigQuery - Bài học 6: Cơ chế tính phí (Pricing Model) – Phân biệt On-Demand (tính theo TB quét) và Editions/Slots (Autoscaling Compute) – Tránh "đốt tiền" oan

Chào anh em! Ở Bài học 5, chúng ta đã biết cách quy hoạch "đất đai" chuẩn doanh nghiệp với cấu trúc đa Project (tách riêng Storage Project và Compute Project) cùng mô hình 3 tầng dữ liệu Bronze - Silver - Gold.

Khi hệ thống đã vào guồng, có một cơn ác mộng có thật mà hầu như công ty nào dùng Cloud Data Warehouse cũng từng trải qua ít nhất một lần: Sáng thứ Hai đầu tuần, sếp mở email thông báo Billing của Google Cloud và hét lên khi thấy hóa đơn BigQuery vọt lên $5,000 chỉ sau một đêm cuối tuần! Thủ phạm? Một bạn thực tập sinh (hoặc một cronjob bị lỗi vòng lặp) đã chạy câu lệnh SELECT * quét đi quét lại trên bảng Log nặng 50 Terabyte mà không có điều kiện lọc Partition.

Với MySQL hay PostgreSQL truyền thống, bạn thuê một con VPS giá $100/tháng thì dù bạn có viết câu lệnh SQL ngu ngốc đến mấy, hậu quả tệ nhất chỉ là... treo server, chứ cuối tháng bạn vẫn chỉ trả đúng $100. Nhưng trên một hệ thống Serverless có khả năng huy động hàng ngàn CPU trong chớp mắt như BigQuery, viết SQL dở đồng nghĩa với việc đốt tiền tươi thóc thật theo từng giây!

Bài học hôm nay sẽ giúp anh em nắm rõ từng đồng xu cắc bạc trong bảng giá của Google BigQuery, phân biệt rạch ròi hai trường phái tính phí tính toán (On-Demand vs Editions/Slots) và thiết lập những "chốt chặn sinh tử" để bảo vệ ví tiền của công ty.

1. Công thức tổng quát: Hóa đơn BigQuery gồm những gì?

Nhờ kiến trúc tách biệt hoàn toàn giữa Lưu trữ (Colossus) và Tính toán (Dremel) mà chúng ta đã mổ xẻ ở Bài 2, hóa đơn hàng tháng của BigQuery được chia làm 2 phần hoàn toàn độc lập:

$\text{Tổng chi phí BigQuery} = \text{Chi phí Lưu trữ (Storage)} + \text{Chi phí Tính toán (Compute / Analysis)}$

(Ngoài ra còn một phần nhỏ là phí Streaming Insert / Storage Write API nếu bạn bơm dữ liệu thời gian thực liên tục, chúng ta sẽ bàn kỹ ở Phần 5).

Hãy đi từ phần dễ thở nhất trước: Chi phí Lưu trữ (Storage Cost).

2. Chi phí Lưu trữ (Storage Pricing): Rẻ như cho và có tới 2 cách tính!

Google cung cấp cho bạn 10 GB lưu trữ miễn phí mỗi tháng. Vượt qua mức này, dữ liệu nằm trên Colossus được chia làm 2 trạng thái tự động:

Active Storage (Lưu trữ hoạt động - ~$0.02 / GB / tháng): Áp dụng cho các bảng hoặc các phân vùng (Partitions) có phát sinh chỉnh sửa (INSERT, UPDATE, DELETE, LOAD) trong vòng 90 ngày qua.
Long-Term Storage (Lưu trữ dài hạn - ~$0.01 / GB / tháng): Nếu một bảng hoặc một Partition không hề bị chỉnh sửa trong 90 ngày liên tiếp, Google tự động giảm 50% giá lưu trữ xuống còn $0.01/GB!
- Điểm ăn tiền: Việc giảm giá này diễn ra hoàn toàn tự động. Dữ liệu vẫn nằm trên Colossus, tốc độ truy vấn, độ an toàn, mọi thứ giữ nguyên 100%, bạn không cần phải viết script đẩy sang Cold Storage hay Glacier như bên AWS! (Đó là lý do ở Phần 4 chúng ta sẽ học cách chia bảng theo ngày – Partition by Date – để dữ liệu các tháng cũ tự động được giảm giá 50%).

Bí mật ít người biết: Logical Billing vs Physical Billing (Tính theo dung lượng Logic hay Vật lý?)

Khi cấu hình một Dataset, BigQuery cho phép bạn chọn 1 trong 2 mô hình tính tiền ổ cứng:

Logical Storage (Mặc định): Tính tiền dựa trên dung lượng chưa nén của kiểu dữ liệu (ví dụ INT64 luôn tính là 8 bytes, STRING tính theo số byte ký tự thực tế).
Physical Storage (Lưu trữ vật lý): Tính tiền dựa trên dung lượng sau khi đã được Capacitor nén trên ổ đĩa vật lý (nhưng cộng thêm phần dung lượng lưu lịch sử Time Travel 7 ngày và Fail-safe 7 ngày).

Mẹo tối ưu triệu đô: Như đã học ở Bài 3, định dạng Capacitor nén dữ liệu dạng cột cực kỳ khủng khiếp (tỷ lệ nén thường từ 5:1 đến 10:1, tức là 100 GB Logical nén xuống chỉ còn 10 - 20 GB Physical!). Nếu bảng của bạn chỉ chuyên nối thêm dữ liệu mới (Append-only như bảng Log, bảng sự kiện, đơn hàng) mà ít khi UPDATE/DELETE (không làm phình dung lượng Time Travel), việc chuyển Dataset từ Logical sang Physical Storage Billing có thể giúp công ty bạn cắt giảm ngay lập tức 50% - 70% hóa đơn tiền lưu trữ!

3. Chi phí Tính toán (Compute Pricing): Cuộc chiến giữa On-Demand và Editions (Slots)

Đây mới là nơi chiếm 80% - 90% tổng hóa đơn BigQuery và là nơi dễ xảy ra thảm họa nhất. Khi bạn bấm nút Run Query, Google cho bạn 2 lựa chọn để trả tiền cho đội quân Dremel:

Plaintext

                        [ CHI PHÍ TÍNH TOÁN (COMPUTE) ]
                               /               \
                              /                 \
        1. ON-DEMAND (Theo dung lượng quét)     2. EDITIONS / CAPACITY (Thuê CPU Slots)
        - Trả tiền theo số Terabyte (TB)        - Trả tiền theo số lượng Slots (CPU+RAM)
          dữ liệu thực tế bị đọc từ đĩa.          mà bạn sử dụng theo từng giây (Slot-hours).
        - ~$6.25 / 1 TB dữ liệu quét.           - Tự động co giãn (Autoscaling) theo tải.
        - Miễn phí 1 TB đầu tiên mỗi tháng.     - Không giới hạn bạn quét bao nhiêu TB!

Hãy mổ xẻ xem từng mô hình hoạt động ra sao!

Mô hình 1: On-Demand Pricing (Trả tiền theo số Byte dữ liệu quét)

Đây là chế độ mặc định khi bạn mới tạo Project.

Cách tính: Bạn trả khoảng $6.25 cho mỗi Terabyte (TB) dữ liệu mà câu lệnh SQL của bạn quét qua (Tại vùng Singapore asia-southeast1 giá có thể nhỉnh hơn một chút khoảng ~$6.75 - $7.00/TB tùy biểu giá vùng). 1 TB đầu tiên mỗi tháng được miễn phí hoàn toàn!
Nguyên tắc sống còn: Google tính tiền dựa trên tổng dung lượng của các cột (Columns) có mặt trong câu truy vấn (sau khi đã cắt tỉa Partition/Cluster), bất kể câu lệnh của bạn đơn giản hay phức tạp, chạy mất 1 giây hay 10 phút!
- Ví dụ 1: Bảng orders nặng 10 TB gồm 50 cột. Bạn gõ SELECT * FROM orders LIMIT 1. Dù chỉ trả về đúng 1 dòng trên màn hình, nhưng nếu nó quét hết 10 TB, bạn mất ngay $62.5 (hơn 1,5 triệu VNĐ) cho 1 cú click chuột!
- Ví dụ 2: Bạn chỉ chọn đúng 1 cột SELECT total_amount FROM orders (cột này nặng 100 GB), nhưng bên trong bạn viết 20 vòng JOIN, WINDOW FUNCTION, tính toán cực kỳ nặng nề tốn rất nhiều CPU. Bạn vẫn chỉ trả tiền cho đúng 100 GB (~$0.62)!
Những thao tác được MIỄN PHÍ trong On-Demand:
- Nạp dữ liệu theo lô (Batch Load) từ file Parquet/CSV trên GCS vào BigQuery: 0 đồng!
- Xuất dữ liệu (Export) từ bảng BigQuery ra GCS: 0 đồng!
- Xóa bảng (DROP TABLE), xóa toàn bộ phân vùng, hoặc xem dữ liệu qua tab Preview: 0 đồng!
- Câu lệnh bị lỗi cú pháp (Syntax Error) hoặc đọc từ bộ nhớ đệm (Cached Results): 0 đồng!

Mô hình 2: Capacity Pricing – BigQuery Editions (Trả tiền theo năng lực CPU/Slots)

Khi công ty của bạn lớn lên, mỗi ngày có hàng trăm nhân sự kéo Dashboard Looker/Tableau và hàng ngàn job ETL chạy liên tục, tiền quét dữ liệu theo TB (On-Demand) sẽ tăng vọt không kiểm soát. Lúc này, bạn chuyển sang mô hình BigQuery Editions (Standard, Enterprise, Enterprise Plus).

Khái niệm "Slot": Như đã nhắc ở Bài 2, 1 Slot là một đơn vị tính toán ảo của Dremel (tương đương khoảng 0.5 vCPU và một lượng RAM nhất định). Câu lệnh càng nặng, cần chạy càng nhanh thì càng ngốn nhiều Slots.
Cách tính tiền (Autoscaling Slots): Thay vì tính tiền theo số GB dữ liệu đọc từ ổ cứng, Google tính tiền dựa trên Số lượng Slots thực tế bạn dùng nhân với Thời gian chạy (tính bằng giây - Slot-hours)!
- Bạn cấu hình một mức sàn (Baseline Slots – ví dụ: 0 hoặc 100 Slots) và một mức trần (Max Reservation Slots – ví dụ: 500 Slots).
- Lúc 2h đêm không có ai chạy query, hệ thống hạ về 0 Slot $\rightarrow$ Bạn tốn 0 đồng!
- Lúc 9h sáng có 20 câu lệnh chạy cùng lúc, bộ điều phối Borg tự động nâng (Autoscale) lên 300 Slots trong 2 phút để giải quyết gọn lẹ, rồi lại hạ về 0. Bạn chỉ trả tiền cho đúng 2 phút thuê 300 Slots đó (Giá khoảng từ $0.04 đến $0.06 / 1 Slot-hour tùy gói Edition và cam kết 1-3 năm).
- Đặc quyền: Một khi đã thuê Slots, bạn có quét 100 TB hay 1.000 TB dữ liệu cũng không bị tính thêm tiền quét! Nó chỉ làm các Slots của bạn bận rộn lâu hơn một chút mà thôi.

4. Bảng so sánh thực chiến: Khi nào chọn On-Demand, khi nào chọn Editions (Slots)?

Tiêu chí	On-Demand (Tính theo TB quét)	BigQuery Editions (Tính theo CPU Slots)
Cách tính tiền	Theo dung lượng dữ liệu đọc vào (Bytes Processed)	Theo tài nguyên CPU/RAM tiêu thụ (Slot-hours)
Hiệu năng (Tốc độ)	Bùng nổ tối đa! Google cho phép bạn mượn tới 2.000 Slots dùng chung ngay lập tức.	Bị giới hạn trong mức Max Slots bạn đã cấu hình (ví dụ đặt trần 200 Slots thì câu lệnh cực nặng sẽ chạy chậm hơn một chút).
Khả năng dự đoán chi phí	Thấp (Rủi ro cao): Một câu lệnh viết sai quên `WHERE` có thể tốn hàng trăm đô la ngay lập tức.	Tuyệt đối (An toàn 100%): Bạn đặt trần Max Slots = 100, thì dù cả công ty có chạy query điên cuồng 24/24 bạn cũng biết chính xác số tiền tối đa phải trả!
Truy vấn nào có lợi?	Truy vấn đọc ít dữ liệu (nhờ Partition/Cluster tốt) nhưng tính toán cực kỳ phức tạp (CPU-heavy: Regex, JSON, ML, Cross Join).	Truy vấn quét dữ liệu khổng lồ lặp đi lặp lại (I/O-heavy: Dashboard làm mới mỗi 5 phút, ETL quét bảng lớn) nhưng phép tính đơn giản.
Phù hợp với ai?	Startup, dự án mới, khối lượng truy vấn thất thường hoặc tổng chi phí dưới $1,000 - $2,000/tháng.	Doanh nghiệp vừa và lớn, có đội BI/Data chạy job đều đặn hàng ngày, cần khóa cứng ngân sách.

Tuyệt chiêu Hybrid (Kết hợp cả hai trong 1 công ty):

Nhờ kiến trúc tách biệt Compute Project mà chúng ta đã thiết kế ở Bài học 5, bạn không cần phải chọn 1 trong 2 cho toàn công ty!

Bạn có thể tạo project-compute-bi gắn vào gói Editions (Autoscaling tối đa 200 Slots) cho đội BI và thực tập sinh tha hồ vọc vạch, kéo Dashboard mà không sợ "nổ" hóa đơn.

Đồng thời giữ project-compute-adhoc ở chế độ On-Demand dành riêng cho các Senior Data Engineer khi cần chạy những câu lệnh cần huy động tức thời 2.000 Slots để xử lý tác vụ khẩn cấp!

5. Năm "Chốt chặn sinh tử" để không bao giờ bị đốt tiền oan trên BigQuery

Dù bạn dùng On-Demand hay Editions, với tư cách là một kỹ sư phụ trách hệ thống, hãy áp dụng ngay 5 quy tắc phòng vệ sau đây ngay khi khởi tạo dự án:

Chốt chặn 1: Luôn nhìn góc trên bên phải màn hình (Query Validator / Dry Run)

Trước khi bạn bấm nút Run trên giao diện BigQuery Studio, bộ phân tích của Google luôn chạy ngầm một lệnh Dry Run (Chạy thử miễn phí) và hiển thị dòng chữ màu xanh lá cây ở góc trên bên phải:

This query will process 45.2 GB when run.

Hãy tập phản xạ có điều kiện: Mắt nhìn số GB trước, tay bấm nút Run sau! Nếu thấy nó hiện 1.2 TB trong khi bạn chỉ định tìm 1 đơn hàng, hãy dừng lại ngay lập tức vì bạn vừa quên điều kiện lọc Partition rồi đấy! (Nếu gọi từ code Backend bằng Golang/Node.js, luôn bật cờ dryRun: true để kiểm tra số byte trước khi thực thi).

Chốt chặn 2: Bật cờ `Require Partition Filter` ngay khi tạo bảng lớn

Khi tạo các bảng lịch sử lớn (như orders, user_logs), hãy bật tùy chọn bắt buộc phải có điều kiện WHERE trên cột phân vùng:

SQL

CREATE TABLE `my-project.core_dwh.fact_orders` (
  order_id INT64,
  total_amount NUMERIC,
  created_at TIMESTAMP
)
PARTITION BY DATE(created_at)
OPTIONS (
  require_partition_filter = TRUE -- CHỐT CHẶN SINH TỬ!
);

Khi có dòng này, nếu bất kỳ ai trong công ty (hoặc công cụ BI nào) gõ SELECT * FROM fact_orders mà quên truyền WHERE created_at >= ..., BigQuery sẽ từ chối chạy ngay lập tức và báo lỗi bắt người dùng phải thêm điều kiện ngày tháng vào!

Chốt chặn 3: Thiết lập `Maximum Bytes Billed` cho từng câu lệnh (hoặc toàn Project)

Trong phần More $\rightarrow$ Query settings trên giao diện (hoặc trong cấu hình SDK của Backend), bạn có thể đặt thông số Maximum bytes billed (Ví dụ: Giới hạn tối đa 10 GB cho 1 câu lệnh).

Nếu một câu truy vấn ước tính sẽ quét vượt quá 10 GB, BigQuery sẽ tự động chặn đứng trước khi chạy và bạn tốn 0 đồng!

Chốt chặn 4: Cài đặt Custom Quotas (Hạn ngạch ngày cho từng User / Project)

Trong trang quản trị IAM & Admin $\rightarrow$ Quotas của Google Cloud, hãy tìm thông số:

Query usage per day (Giới hạn tổng số TB được phép quét của cả Project trong 1 ngày – ví dụ: Tối đa 5 TB/ngày).
Query usage per day per user (Giới hạn mỗi nhân viên chỉ được quét tối đa 500 GB/ngày).

Nếu một tài khoản bị lộ key hoặc viết vòng lặp vô tận, khi chạm mốc 500 GB hệ thống sẽ tự khóa quyền chạy query của user đó trong ngày hôm đó, cứu toàn bộ ngân sách còn lại của công ty!

Chốt chặn 5: Tận dụng tối đa Bộ nhớ đệm (Query Cache - Miễn phí 100%)

Mặc định, khi bạn chạy một câu lệnh SQL, BigQuery sẽ lưu kết quả trả về vào một bảng tạm ẩn trong vòng 24 giờ.

Nếu bạn (hoặc người dùng khác dùng cùng câu lệnh y hệt) chạy lại câu lệnh đó và bảng gốc bên dưới chưa có dữ liệu mới thay đổi, BigQuery sẽ lấy thẳng từ Cache trả về trong 0.1 giây với chi phí 0 byte (0 đồng)!

Lưu ý nhỏ: Nếu trong câu lệnh bạn dùng hàm thời gian thực biến đổi liên tục theo từng giây như WHERE created_at <= CURRENT_TIMESTAMP(), câu lệnh mỗi giây sẽ khác nhau nên Cache sẽ bị vô hiệu hóa. Hãy đổi thành CURRENT_DATE() nếu chỉ cần lọc theo ngày để tận dụng Cache!

Tổng kết Bài học 6

Hiểu rõ cơ chế tính tiền của BigQuery chính là ranh giới phân biệt giữa một "Thợ viết SQL" và một "Data Architect" thực thụ:

Storage: Cực rẻ ($0.02/GB), tự giảm một nửa ($0.01/GB) sau 90 ngày không đụng tới. Hãy cân nhắc bật Physical Storage Billing cho các bảng nén tốt và ít UPDATE/DELETE để tiết kiệm tới 70% tiền ổ cứng.
Compute: Bắt đầu với On-Demand ($6.25/TB) khi mới làm quen và tận dụng 1 TB miễn phí mỗi tháng. Khi hệ thống lớn và ổn định, chuyển các luồng BI/ETL nặng sang BigQuery Editions (Autoscaling Slots) để khóa chặt trần chi phí.
Phòng vệ chủ động: Luôn bật require_partition_filter = TRUE, giới hạn maximum_bytes_billed và cài đặt Custom Quotas theo ngày.

Vậy là chúng ta đã nắm trọn cả Kiến trúc, Tổ chức tài nguyên lẫn Bài toán kinh tế của BigQuery! Ở bài học tiếp theo, chúng ta sẽ chính thức xắn tay áo lên, mở Terminal và trình duyệt để thiết lập môi trường làm việc chuyên nghiệp như một kỹ sư thực thụ!

Hẹn gặp lại anh em ở Bài học 7: Khởi tạo môi trường làm việc – Sử dụng BigQuery Studio, bq CLI trên Terminal và cấu hình Google Cloud SDK!

bigquery