Định dạng file Apache Parquet đang rơi vào tình thế tiến thoái lưỡng nan. Trong khi Version 2 đã được hoàn thiện từ nhiều năm trước và mang lại những cải thiện hiệu suất rõ rệt, cộng đồng kỹ sư dữ liệu vẫn chủ yếu bám víu vào Version 1 do lo ngại về tính tương thích và sự phân mảnh hệ sinh thái.
Lợi Ích Hiệu Suất Là Có Thật Nhưng Khiêm Tốn
Thử nghiệm trên hai bộ dữ liệu lớn cho thấy Parquet Version 2 mang lại những cải thiện nhất quán so với phiên bản tiền nhiệm. Kích thước file giảm từ 2-37% tùy thuộc vào phương pháp nén, với các file không nén thấy được lợi ích lớn nhất. Hiệu suất ghi cải thiện 4-27%, trong khi các thao tác đọc nhanh hơn 1-19%. Những cải thiện này rõ rệt nhất với các bộ dữ liệu chứa nhiều giá trị số, nơi mà các phương pháp mã hóa mới có thể hoạt động hiệu quả hơn.
Những cải thiện này đến từ việc mã hóa dữ liệu tốt hơn trước khi thực hiện nén. Version 2 bao gồm các phương pháp mã hóa mới như RLE_DICTIONARY và DELTA_BYTE_ARRAY giúp nén dữ liệu hiệu quả hơn. Điều này giảm bớt công việc cho các thuật toán nén truyền thống, giải thích tại sao các file không nén lại thấy được cải thiện tương đối lớn nhất.
Cải thiện hiệu suất Parquet Version 2
Giảm kích thước tệp (Bộ dữ liệu Chính phủ Ý):
- UNCOMPRESSED: nhỏ hơn 37%
- SNAPPY: nhỏ hơn 10%
- GZIP: nhỏ hơn 5%
- ZSTD: nhỏ hơn 2%
- LZ4_RAW: nhỏ hơn 8%
- LZO: nhỏ hơn 9%
Cải thiện hiệu suất ghi (Bộ dữ liệu New York Taxi):
- UNCOMPRESSED: nhanh hơn 13%
- SNAPPY: nhanh hơn 10%
- GZIP: nhanh hơn 27%
- ZSTD: nhanh hơn 11%
- LZ4_RAW: nhanh hơn 11%
- LZO: nhanh hơn 9%
Cải thiện hiệu suất đọc (Bộ dữ liệu New York Taxi):
- UNCOMPRESSED: nhanh hơn 12%
- SNAPPY: nhanh hơn 15%
- GZIP: nhanh hơn 16%
- ZSTD: nhanh hơn 18%
- LZ4_RAW: nhanh hơn 19%
- LZO: nhanh hơn 18%
Độ Phức Tạp Triển Khai Gây Lo Ngại Cho Nhà Phát Triển
Triển khai tham chiếu Java đã nhận được sự chỉ trích từ các nhà phát triển làm việc với định dạng này. Chỉ riêng việc triển khai bit-packing đã tạo ra 74,000 dòng mã Java để xử lý mọi kết hợp của độ rộng bit, endianness và độ dài giá trị. Cách tiếp cận này ưu tiên hiệu suất hơn khả năng bảo trì và tạo ra thách thức cho các nhà phát triển cố gắng triển khai hỗ trợ Parquet trong các ngôn ngữ khác hoặc trên phần cứng khác như GPU.
Độ phức tạp không chỉ dừng lại ở mã nguồn. Những khoảng trống trong tài liệu khiến các nhà triển khai mới khó hiểu đúng cách bố trí file. Ngay cả những chi tiết cơ bản như cách page header được bao gồm trong tính toán kích thước nén cũng đòi hỏi phải đào sâu qua hex dump thay vì các tài liệu đặc tả rõ ràng.
Cuộc Tranh Luận Tiêu Chuẩn Kéo Dài Bốn Năm Cản Trở Tiến Bộ
Có lẽ đáng lo ngại nhất là sự bất đồng kéo dài về việc gì cấu thành chức năng Version 2 cốt lõi. Một pull request thảo luận vấn đề này đã mở trong bốn năm mà không có giải pháp. Cuộc tranh luận tập trung vào việc liệu các cải thiện mã hóa và thay đổi cấu trúc page có nên được coi là các tính năng riêng biệt, phát triển độc lập thay vì một bản nâng cấp phiên bản nguyên khối.
Sự tê liệt tiêu chuẩn này tạo ra vấn đề con gà và quả trứng. Các query engine như những engine trong các nền tảng dữ liệu lớn sẽ không hỗ trợ đầy đủ Version 2 mà không có yêu cầu tương thích rõ ràng. Trong khi đó, các nhà phát triển công cụ tránh áp dụng các tính năng Version 2 vì họ không thể đảm bảo tương thích với các hệ thống downstream vẫn mong đợi file Version 1.
Sự Thận Trọng Của Doanh Nghiệp Củng Cố Hiện Trạng
Những thách thức tương thích củng cố lý do tại sao các doanh nghiệp thường bám víu vào các giải pháp thương mại đã được thiết lập bất chấp những hạn chế kỹ thuật. Trong các ngành mà việc dữ liệu không khả dụng có thể kết thúc sự nghiệp, những cải thiện hiệu suất khiêm tốn từ Version 2 không đủ để biện minh cho rủi ro lỗi tích hợp với các hệ thống bên thứ ba vẫn mong đợi file Version 1.
Những vấn đề như thế này là lý do tại sao chính phủ và doanh nghiệp vẫn chạy trên Oracle và SQL Server... Email CYA đó, và cổ họng để bóp, là lý do Oracle thực hiện các thỏa thuận cấp phép 7 và 8 con số với các doanh nghiệp bán giải pháp phần mềm kém hơn so với các lựa chọn mã nguồn mở.
Cách tiếp cận bảo thủ này có nghĩa là ngay cả khi các thành phần riêng lẻ của hệ sinh thái dữ liệu thêm hỗ trợ Version 2, việc áp dụng vẫn bị hạn chế bởi khâu yếu nhất trong toolchain của mỗi tổ chức.
Con Đường Phía Trước Đòi Hỏi Sự Phối Hợp
Đối với các tổ chức có toàn quyền kiểm soát pipeline dữ liệu của họ, việc áp dụng Version 2 có ý nghĩa ngay hôm nay. Những cải thiện hiệu suất, dù không ấn tượng, nhưng nhất quán và không có nhược điểm khi tính tương thích không phải là mối quan tâm. Tuy nhiên, việc áp dụng rộng rãi hơn trong hệ sinh thái sẽ đòi hỏi sự phối hợp giữa các query engine lớn, các định dạng data lake như Iceberg và Delta Lake, và các thư viện phổ biến như Pandas.
Trải nghiệm của cộng đồng Parquet phản ánh những thách thức mà các tiêu chuẩn đang phát triển khác phải đối mặt. Những câu chuyện thành công như Linux cho thấy rằng sự lãnh đạo kỹ thuật mạnh mẽ có thể ngăn chặn loại do dự kéo dài đã làm chậm việc áp dụng Parquet Version 2. Cho đến khi sự rõ ràng tương tự xuất hiện xung quanh sự phát triển của Parquet, định dạng này sẽ tiếp tục phục vụ cộng đồng kỹ sư dữ liệu tốt, ngay cả khi chưa phát huy hết tiềm năng.
Tham khảo: The two versions of Parquet