ClickBench loại pgrust vì gian lận kết quả benchmark

Một trong những benchmark cơ sở dữ liệu có ảnh hưởng nhất thế giới vừa có một phen chấn động. ClickBench đã quyết định gỡ bỏ hoàn toàn entry mang tên pgrust sau khi phát hiện hàng loạt dấu hiệu gian lận trong cách công cụ này đạt được những con số ấn tượng.

Bản chất của vụ việc

Alexey Milovidov, thành viên ban quản trị ClickBench, đã mở pull request gỡ bỏ pgrust khỏi bảng xếp hạng. Lý do được nêu rõ: kết quả mà pgrust công bố được tạo ra bởi những cỗ máy viết riêng cho đúng 43 truy vấn của ClickBench, và các lần chạy nóng chỉ đơn thuần phát lại đáp án đã được cache từ lần chạy trước.

Cả hai hành vi này đều vi phạm trực tiếp quy định của benchmark: các bộ nhớ đệm kết quả truy vấn và các bộ nhớ đệm gần cuối pipeline bắt buộc phải bị vô hiệu hóa. Thêm vào đó, entry này còn được gắn nhãn tuned: no trong khi thực tế nó được tinh chỉnh cho đúng những truy vấn cụ thể đó.

Một kernel viết tay cho mỗi truy vấn

Bằng cách phân tích binary phát hành v0.4-preview, nhóm điều tra phát hiện binary này nhúng các đường dẫn mã nguồn như crates/gravity/backend/irprobe/src/q00.rs cho tới q36.rs. Những con số này chính là số hiệu truy vấn của ClickBench.

Đáng chú ý hơn, các bộ so khớp kế hoạch (plan matcher) điều hướng tới những kernel này còn phát ra thông báo lỗi được đặt tên theo chính benchmark, ví dụ:

clickbench group count: filter is not k > 0

clickbench frame: date_trunc unit is not minute

tpch q1: column 6 is not sum(price * (1 - discount) * (1 + tax))

Thậm chí còn có một biến môi trường mang tên PGRUST_GRAVITY_Q20_VARIANT. Mã nguồn công khai của v0.3 xác nhận thiết kế này, với tệp clickbench.ron được mô tả là "kế hoạch vật lý hạ tay cho toàn bộ 43 truy vấn ClickBench", còn tệp SQL chính thức của benchmark được biên dịch thẳng vào executor.

Một số truy vấn như Q19 còn được ghi chú là "tái dựng các dòng đáp án từ hằng số vị từ", và Q29 chỉ đơn giản là một phép viết lại đại số SUM(x+k) = SUM(x) + k*COUNT rồi trả về từ thống kê siêu dữ liệu.

Các lần chạy nóng thực chất là cache

Với các truy vấn Q20, Q21 và Q23, ghi chú kế hoạch ghi rõ: "hot rep = phép gấp thuần trên các phán quyết đã cache — KHÔNG chạm tới cột nào; lựa chọn chính là đáp án".

Kết quả đo thực tế trên máy 96 nhân Graviton (Neoverse-V2) càng khẳng định điều này:

• Q20 (URL LIKE '%google%'): 10,8 giây ở lần chạy lạnh, rồi chỉ còn 11 ms và 5 ms ở các lần sau
• Q17 (GROUP BY UserID, SearchPhrase LIMIT 10): 1,65 giây xuống còn 4 ms
• Q33 (GROUP BY URL ORDER BY c DESC LIMIT 10): 2,38 giây xuống còn 213 ms

Điều đáng chú ý là khi đổi một hằng số khác (ví dụ '%rambler%' thay vì '%google%'), truy vấn lại mất tới 283 ms — cho thấy tốc độ thật của engine cho một phép quét chuỗi con chỉ ở mức vài trăm mili giây, tương đương ClickHouse trên cùng phần cứng.

Truy vấn ngoài 43 hình mẫu bị từ chối

Nghiêm trọng hơn, engine này dường như không có đường thực thi tổng quát cho bảng cột. Các truy vấn chỉ cần thay đổi nhẹ so với benchmark liền báo lỗi:

ERROR: sqe: statement over columnar relation "hits" is not served

Thông báo chi tiết còn ghi: "engine sqe phục vụ các hình mẫu cột mà không có phương án dự phòng; một hình mẫu không được phục vụ sẽ thất bại ồn ào thay vì chạy chậm".

Trong số 67 phép thử nghiệm gần giống benchmark, có tới 20 truy vấn bị từ chối, bao gồm những câu đơn giản như:

• SELECT MIN(URL) FROM hits;
• SELECT COUNT(*) FROM hits WHERE URL = 'http://holodilnik.ru/';
• SELECT AVG(UserID + 1) FROM hits;
• SELECT MAX(length(URL)) FROM hits;

Ngay cả các lệnh INSERT, UPDATE và DELETE cũng không được hỗ trợ trên bảng này.

Vấn đề không phải là kết quả sai

Cần nhấn mạnh: bản thân đáp án cho 43 truy vấn là chính xác. Khi đối chiếu với clickhouse local trên cùng tệp hits.parquet, 30 truy vấn khớp hoàn toàn, phần còn lại chỉ là khác biệt hợp lệ do cách xử lý đồng hạng trong mệnh đề LIMIT.

Vấn đề nằm ở chỗ khác: những con số đó đo lường một bảng tra cứu của benchmark, chứ không phải một cơ sở dữ liệu thực thụ. Đây chính là lý do khiến cộng đồng cơ sở dữ liệu coi trọng tính minh bạch trong benchmark đến vậy — bởi một khi phép đo bị bóp méo, toàn bộ giá trị tham chiếu của nó cũng tiêu tan.

Bài học cho cộng đồng

Với những ai theo dõi các benchmark cơ sở dữ liệu, vụ việc này là lời nhắc nhở quen thuộc nhưng luôn cần thiết: hãy đọc kỹ phương pháp luận, chứ không chỉ nhìn vào con số cuối cùng. Việc pgrust từng được đưa vào rồi cập nhật lên v0.4-preview cho thấy quy trình kiểm duyệt của cộng đồng vẫn hoạt động — dù đôi khi cần tới sự phân tích binary mới phát hiện ra sự thật.

Pull request gỡ bỏ đã được hợp nhất vào nhánh chính, và nhánh phát triển liên quan đã bị xóa. Một đề xuất thêm lại pgrust sau đó cũng đã bị đóng.