Why Adaptive Warehouses Are up to 13.7x Faster for DML Operations

Snowflake · 2026 · 3. Quy mô lớn · Độ khó: Trung bình — bài gốc

Bài quảng bá sản phẩm của nhà cung cấp. Bài tự thừa nhận phần tăng tốc còn đến từ phần cứng nhanh hơn, và một số cơ chế không được đo riêng. Mọi nhận định là theo Snowflake.

Bối cảnh

• Bảng Snowflake chia thành micro-partition lưu trong file cột nén, bất biến (theo thiết kế trong paper SIGMOD 2016): không sửa tại chỗ, mọi thay đổi phải thành file và metadata mới.
• Với copy-on-write, sửa vài dòng nghĩa là chép cả các dòng không đổi sang file thay thế: write amplification. Update nhỏ, rải rác (CDC MERGE, DELETE có chọn lọc) là trường hợp tệ nhất.
• Snowflake còn giữ thống kê cột chính xác cho dữ liệu còn sống để query sau chọn đường tốt; chi phí tính lại thống kê lúc DML có khi lớn hơn chính thay đổi.

Thay đổi chính: bốn nút thắt, lần lượt

1. Ghi delta: với thay đổi thưa, ghi file delta nhỏ kèm bitmap thay vì viết lại cả partition.
2. Dùng lại thống kê cột trên các đường DML đủ điều kiện thay vì tính lại. Giữ một số thống kê chính chính xác; lưu thêm chút metadata để biết khi nào chỉ cần chỉnh nhẹ, khi nào phải tính lại hết.
3. Giảm CPU thì thời gian chờ I/O lộ ra. Hai cách: thread nền tải và parse dữ liệu trong khi thread chính xử lý partition đã sẵn; cache metadata đã parse trong RAM (một file thống kê phục vụ nhiều partition). Cache bỏ được việc gom lô partition trước khi tải metadata, vốn gây bùng CPU và để partition cuối chờ.
4. Bố trí file theo workload: dùng lịch sử query để xếp các cột hay được đọc cùng nhau cạnh nhau trong file mới ghi. Chỉ áp cho file mới, không đo riêng trong benchmark.

• Mỗi bước gỡ một nút thắt và làm lộ nút tiếp theo: bớt ghi → metadata thành chi phí chính → bớt tính → chờ I/O lộ ra.

Kết quả (theo Snowflake)

• Một MERGE tổng hợp (update 1,83 triệu dòng, chèn 420.000 dòng, quét khoảng 439 GB): 6 phút 28 giây xuống 28 giây (13,7 lần). Dữ liệu ghi lại giảm 545 lần (431,8 GB → 0,79 GB). Ở bản cũ ghi chiếm 67% thời gian; ở bản mới quét bảng đích chiếm 48%. I/O từ xa chiếm 90% thời gian nhưng thời gian chờ tuyệt đối giảm từ 1 phút 17 giây xuống 14 giây nhờ prefetch.
• Một UPDATE production của khách (đánh dấu file đã xử lý): quét như nhau 1,59 TB, ghi 5,35 GB → 12,98 MB (412 lần), 7,33 → 1,72 giây.

Vì sao

• Storage bất biến trên object storage đơn giản hoá đồng thời và snapshot, nhưng biến mọi thay đổi nhỏ thành ghi lớn; phải có lớp delta để chi phí ghi tỉ lệ với thay đổi thay vì với kích thước partition (Tách compute khỏi storage).
• Pipeline ELT/CDC chạy MERGE lặp lại nên trả write amplification nhiều lần (Pipeline dữ liệu và analytics).

Bài học cho SWE

• Đo "byte ghi ra / byte thay đổi". Tỉ lệ hàng trăm lần là dấu hiệu copy-on-write đang ăn tiền.
• Tối ưu theo chuỗi: sau mỗi lần gỡ nút thắt, đo lại xem thời gian chuyển sang đâu (CPU → I/O).
• Khi storage ở xa, chồng I/O với CPU (prefetch, pipeline) quan trọng ngang giảm khối lượng việc.
• Tỉ lệ thời gian chạy không phải ước tính chi phí; bài tự nhắc phải đo cả consumption.

Liên quan

• DuckDB Labs 2026 · Alibaba 2026 · Allegro 2024
• Pipeline dữ liệu và analytics · Tách compute khỏi storage