Nén 1.000 tệp Apache Iceberg thành 6: Điều gì xảy ra với hiệu năng truy vấn?

Apache Iceberg đang trở thành lựa chọn hàng đầu cho các hệ thống lakehouse hiện đại nhờ khả năng quản lý bảng quy mô lớn. Tuy nhiên, khi dữ liệu được ghi liên tục qua nhiều batch nhỏ, số lượng tệp có thể tăng vọt và ảnh hưởng trực tiếp đến hiệu năng truy vấn. Bài thử nghiệm dưới đây tìm hiểu điều gì xảy ra khi nén 1.000 tệp nhỏ thành chỉ 6 tệp lớn hơn.

Vấn đề: quá nhiều tệp nhỏ

Trong các pipeline dữ liệu hiện đại, dữ liệu thường được ghi vào bảng Iceberg theo từng micro-batch hoặc theo luồng streaming. Mỗi lần ghi như vậy tạo ra một hoặc nhiều tệp Parquet mới. Sau một thời gian, một bảng có thể chứa hàng nghìn tệp nhỏ, gây ra nhiều hệ quả tiêu cực:

• Chi phí metadata tăng cao: mỗi tệp đều có entry trong manifest, khiến quá trình lập kế hoạch truy vấn (query planning) chậm hơn.
• Truy vấn full scan kém hiệu quả: engine phải mở nhiều tệp, tốn nhiều I/O và thời gian mở tệp.
• Áp lực lên hệ thống lưu trữ: các hệ thống object storage như S3 chịu độ trễ cao hơn khi phải liệt kê và đọc nhiều đối tượng nhỏ.

Đây chính là lý do thao tác compaction (nén tệp) trở thành một phần thiết yếu trong vận hành lakehouse.

Thử nghiệm: nén 1.000 tệp thành 6

Tác giả đã tiến hành nén một bảng Iceberg gồm 1.000 tệp Parquet nhỏ thành 6 tệp lớn hơn, sau đó chạy lại ba loại workload SQL điển hình để so sánh:

• Truy vấn quét toàn bảng (full table scan) không có bộ lọc.
• Truy vấn có bộ lọc theo cột (filtered query) sử dụng partition pruning.
• Truy vấn tổng hợp (aggregation) với GROUP BY trên nhiều cột.

Kết quả được đo trên cùng một cụm engine, cùng cấu hình tài nguyên, để đảm bảo tính công bằng.

Kết quả đạt được

Việc giảm số lượng tệp mang lại cải thiện rõ rệt nhất ở các truy vấn quét toàn bảng.

• Full table scan: thời gian truy vấn giảm mạnh, đôi khi chỉ còn một phần nhỏ so với trước. Việc mở ít tệp hơn giúp giảm overhead I/O đáng kể.
• Truy vấn có bộ lọc: mức cải thiện khiêm tốn hơn, vì partition pruning vốn đã giúp bỏ qua phần lớn dữ liệu không cần thiết.
• Truy vấn tổng hợp: kết quả phụ thuộc vào khả năng đọc song song. Tệp quá lớn có thể làm giảm mức độ song song hóa nếu không được chia đúng cách.

Điều đáng chú ý là không phải cứ ít tệp hơn là luôn tốt hơn. Việc nén quá mức có thể tạo ra các tệp khổng lồ, khiến engine khó đọc song song và làm tăng độ trễ cho các truy vấn chỉ chạm vào một phần nhỏ dữ liệu.

Bài học cho người vận hành lakehouse

Từ thử nghiệm này, có thể rút ra một vài nguyên tắc thực tiễn cho các đội ngũ dữ liệu tại Việt Nam đang xây dựng hệ thống lakehouse:

• Đặt mục tiêu kích thước tệp hợp lý, thường từ 128 MB đến 512 MB cho mỗi tệp Parquet, tùy theo engine và workload.
• Chạy compaction định kỳ thay vì để tệp nhỏ tích tụ quá lâu.
• Theo dõi số lượng tệp trung bình trên mỗi partition như một chỉ số sức khỏe của bảng.
• Cân nhắc rewrite manifests để giảm chi phí query planning khi bảng có nhiều snapshot.

Các công cụ như Spark, Flink hay những tính năng compaction gốc của Iceberg đều có thể hỗ trợ quá trình này.

Kết luận

Nén tệp trong Apache Iceberg là một thao tác bảo trì đơn giản nhưng mang lại lợi ích lớn về hiệu năng truy vấn, đặc biệt với các workload quét dữ liệu lớn. Tuy nhiên, đây không phải là giải pháp "một lần là xong" — cần được thiết kế như một phần trong chiến lược vận hành dữ liệu dài hạn, với các ngưỡng kích thước tệp được điều chỉnh phù hợp cho từng hệ thống cụ thể.