Hủy truy vấn trên Redshift Serverless vẫn bị tính tiền: FDE phải dựng chốt chặn từ trước

Tài liệu của AWS về Redshift Serverless ghi rõ: nếu bạn chạy một truy vấn rồi hủy giữa chừng, bạn vẫn bị tính tiền cho khoảng thời gian nó đã chạy.

Nút Cancel không xóa được phần đó khỏi hóa đơn. Ở chỗ khách hàng, đó có thể là khác biệt giữa một buổi khám phá dữ liệu bình thường và một cuộc gọi khó xử với bộ phận tài chính.

Ngày đầu ở chỗ khách, FDE thường được cấp quyền đọc vào kho dữ liệu rồi bắt đầu tìm hiểu: đếm bảng, xem phân phối, join thử vài bảng lớn. Snowflake, BigQuery và Redshift tính tiền cho những thao tác này theo những cách khác nhau. Muốn đặt đúng chốt chặn, bạn phải biết nền tảng đang đếm cái gì.

Mỗi nền tảng đếm một thứ khác nhau

Snowflake chia chi phí thành ba phần: compute, storage và truyền dữ liệu. Compute tính bằng credit, bị trừ dần mỗi khi warehouse chạy. Storage tính theo giá cố định cho mỗi terabyte mỗi tháng.

Snowflake không thu phí đưa dữ liệu vào tài khoản, nhưng có thu phí khi dữ liệu đi ra (egress). FDE cần nhớ rằng đẩy một bản export lớn sang hệ thống khác cũng là một khoản chi.

BigQuery có hai mô hình. Với on-demand, khách trả theo số byte được xử lý khi truy vấn. Với capacity, khách cấp sẵn năng lực xử lý dưới dạng slot cho từng workload, có thể bật tự động co giãn.

Vì thế, câu hỏi đầu tiên khi vào một dự án BigQuery là khách đang dùng mô hình nào. Nó quyết định truy vấn của bạn tốn tiền theo dung lượng quét, hay chiếm phần năng lực mà các team khác cũng đang dùng.

Với Redshift, cách tính tiền tùy vào loại triển khai. Cluster provisioned tính theo giờ. Redshift Serverless tính theo RPU-hour, đo theo từng giây, với mức tối thiểu là 60 giây. Nếu truy vấn đọc dữ liệu ngoài qua Redshift Spectrum thì khách trả thêm theo số byte Spectrum quét.

BigQuery từ chối truy vấn trước khi tốn tiền

Trong ba nền tảng, BigQuery có chốt chặn dễ hiểu nhất vì nó hoạt động trước khi truy vấn chạy. Google khuyên chạy thử (dry run, hay preview) để ước tính chi phí trước. Maximum bytes billed thì chặn hẳn: nếu số byte ước tính vượt giới hạn, truy vấn thất bại và không bị tính phí.

Thử hình dung: bạn đặt maximum bytes billed là 100 GB cho các truy vấn khám phá. Một đồng nghiệp viết truy vấn join hai bảng sự kiện, dry run báo ước tính 1,5 TB. Truy vấn bị từ chối, hóa đơn không đổi, và bạn có dịp thêm điều kiện lọc theo ngày rồi chạy lại.

Ở tầng dự án, Google khuyên đặt custom daily query quota để giới hạn lượng dữ liệu xử lý mỗi ngày. Như vậy bạn có hai lớp: maximum bytes billed chặn từng truy vấn, daily quota chặn tổng mức dùng trong ngày, kể cả khi ai đó chạy một vòng lặp gọi truy vấn hàng trăm lần.

Cần lưu ý rằng hai lớp này tính theo byte, nên chúng tác động trực tiếp lên hóa đơn chủ yếu khi khách dùng on-demand. Nếu khách dùng capacity, hãy hỏi admin xem truy vấn của bạn chạy trên phần slot nào, để không giành năng lực của các workload khác.

Snowflake chặn được, nhưng cần đúng người

Chốt chặn của Snowflake là resource monitor, giới hạn lượng credit các warehouse được dùng. Ở mức mạnh nhất, monitor có thể suspend ngay mọi warehouse standard được gán vào nó, và hủy luôn các câu lệnh đang chạy.

Chỉ ACCOUNTADMIN mới tạo được resource monitor, nên một FDE chỉ có quyền đọc sẽ không tự dựng được chốt chặn này. Việc cần làm trong tuần đầu là đặt lịch với admin phía khách, thống nhất hạn mức credit cho warehouse của dự án và cách hệ thống phản ứng khi chạm ngưỡng.

Redshift: hủy truy vấn không hoàn lại phần đã chạy

Trên Redshift Serverless, hủy một truy vấn chỉ ngăn nó chạy tiếp. AWS khuyên đặt giới hạn số RPU-hour tối đa làm chốt chặn chi phí. Usage limit có ba mức phản ứng: ghi log, gửi cảnh báo qua SNS, hoặc tắt truy vấn của người dùng và gửi thông báo.

Thứ tự hợp lý là bật cảnh báo SNS trước, rồi đặt mức tắt truy vấn cao hơn một chút. Cảnh báo cho bạn thời gian phản ứng, còn mức tắt giữ hóa đơn không vượt ngưỡng đã thống nhất.

Ba cái bẫy dễ gặp ở tuần đầu

Bẫy đầu tiên là dùng chung warehouse với pipeline sản xuất của khách. Trên Snowflake, hard stop sẽ cắt ngang cả những job đang chạy dở, nên một monitor đặt quá chặt có thể làm hỏng việc của người khác. Cách an toàn hơn là xin một warehouse riêng cho công việc của bạn rồi gán monitor vào đó.

Bẫy thứ hai là gửi cảnh báo về một kênh không ai đọc. Cảnh báo SNS chỉ có ích khi nó đến chỗ mà cả bạn lẫn người phụ trách phía khách đều theo dõi hằng ngày.

Bẫy thứ ba là coi nút Cancel như lưới an toàn. Trên Redshift Serverless, thời gian đã chạy vẫn bị tính tiền, nên bạn chỉ thật sự được bảo vệ khi đã có hạn mức đặt sẵn.

Nên học gì trước

Nếu chỉ có một tuần để chuẩn bị, hãy bắt đầu với BigQuery. Dry run và maximum bytes billed cho bạn thấy ngay chi phí ước tính và cách chốt chặn hoạt động.

Sau đó, đọc tài liệu về resource monitor của Snowflake và usage limit của Redshift Serverless để biết hạn mức được đặt ở đâu và hệ thống phản ứng ra sao khi chạm ngưỡng.

Khi JD có ghi “Snowflake/BigQuery/Redshift”, đừng chỉ viết “thành thạo SQL” vào CV. Một dòng như “thiết lập maximum bytes billed và daily quota cho dự án BigQuery của khách trước khi khám phá dữ liệu” cho người phỏng vấn thấy bạn hiểu rằng ở chỗ khách, chi phí là trách nhiệm của FDE.

Khách hàng có thể quên một dashboard đẹp, nhưng ít khi quên một tháng hóa đơn tăng vọt vì truy vấn của người ngoài.