F3 - Định dạng tệp dữ liệu mã nguồn mở cho tương lai
(github.com/future-file-format)- F3 là một định dạng tệp dữ liệu được thiết kế với hiệu quả, khả năng tương tác và khả năng mở rộng trong tâm trí
- Nó cung cấp một cách tổ chức dữ liệu khắc phục các giới hạn về bố cục của các định dạng thế hệ trước như Parquet, đồng thời duy trì khả năng tương tác và mở rộng thông qua bộ giải mã Wasm tích hợp
- Tệp F3 tự mô tả có cấu trúc chứa không chỉ dữ liệu và siêu dữ liệu mà còn cả nhị phân WebAssembly dùng để giải mã dữ liệu
- Cách nhúng bộ giải mã vào tệp chỉ yêu cầu không gian lưu trữ tối thiểu ở mức kilobyte, và là thiết kế nhằm đảm bảo khả năng tương thích trên mọi nền tảng ngay cả khi không có bộ giải mã native
- Đây là dự án Future-proof File Format cung cấp cấu trúc tổ chức dữ liệu và API tổng quát để nhà phát triển có thể dễ dàng bổ sung các phương thức mã hóa mới
- Trạng thái hiện tại là nguyên mẫu nghiên cứu nhằm kiểm chứng ý tưởng trong bài báo, và không được dùng cho production
- Việc build hiện mới chỉ được kiểm thử trên Debian 12 chạy trên máy Intel, và cách chạy build gói PoC cùng unit test là
cargo build -p fff-poc,cargo test -p fff-poc - Định nghĩa định dạng tệp dựa trên FlatBuffer, đồng thời cung cấp mã nguồn chính, phần triển khai giải mã Wasm, cùng benchmark và script phục vụ thí nghiệm trong bài báo
- Giấy phép là MIT License
1 bình luận
Ý kiến Hacker News
Không rõ vì sao lại được đề xuất nhiều như vậy, và trang đích cũng không mấy ấn tượng nên có vẻ đọc bài báo sẽ tốt hơn: https://dl.acm.org/doi/epdf/10.1145/3749163
Trông giống một định dạng lưu trữ hướng cột nhằm khắc phục một phần nhược điểm của Parquet, nhưng yếu tố quyết định thật sự của các định dạng kiểu này là khả năng tương thích, và định dạng mới ngay từ lúc xuất hiện đã bất lợi ở điểm đó
Parquet quá mạnh chỉ riêng nhờ việc đã phổ biến trước, và theo bài báo thì ngay cả phiên bản Parquet được dùng nhiều nhất cũng là phiên bản cổ nhất từ năm 2013, nghĩa là ngay cả Parquet cũng chưa thể thay thế Parquet
Có vẻ F3 sẽ cần kết quả rất mạnh mới vượt qua được điều này, nhưng hiện chưa thấy như vậy
Cá nhân thấy điểm khó chịu lớn nhất của Parquet là vấn đề một bảng cho mỗi tệp cũng không được xử lý, nên cái tên nghe hơi phóng đại, và việc nhúng nhị phân Wasm để giải mã nhưng lại cần FlatBuffers để phân tích khối đó cũng làm mục tiêu trở nên thiếu rõ ràng
Thành quả chính có vẻ là cải thiện truy cập ngẫu nhiên, nhưng lưu trữ hướng cột vốn sinh ra để từ bỏ truy cập ngẫu nhiên nhằm đổi lấy phân tích nhanh, còn F3 dường như lại hy sinh phân tích nhanh vì bộ giải mã Wasm nên khá khó hiểu
Spark, DataFusion và DuckDB dù nhận tệp nhiều bảng cũng sẽ không biết rõ phải làm gì
Đúng là Parquet làm tốt nhiều việc, nhưng điều đó không có nghĩa chỉ vì ra đời trước mà nó phải mãi là định dạng tệp phân tích duy nhất
Phân tích nhanh và các tải công việc máy học hiện đại về bản chất đều là sự pha trộn giữa quét hàng loạt và truy cập ngẫu nhiên
Một số tác giả của F3 trước đây cũng từng viết một bài báo phân tích chi tiết nhược điểm của Parquet: https://www.vldb.org/pvldb/vol17/p148-zeng.pdf
Các định dạng gần đây như Vortex, Lance và F3 đều đang cố giải quyết các vấn đề được tổng hợp trong bài báo đó
Lance có vài ý tưởng thú vị, còn Vortex thay bộ mã hóa kiểu hộp đen của Parquet bằng mã hóa minh bạch để tập trung vào khả năng mở rộng và hiệu năng
Nhờ vậy có thể giảm sự đánh đổi giữa giải mã khối lượng lớn và giải mã theo từng phần tử, để vừa quét toàn bộ hiệu quả vừa có truy cập ngẫu nhiên rất nhanh
Ví dụ, LangChain cho biết họ đã xây dựng lại hệ thống dựa trên tệp Parquet bằng Vortex và thấy tốc độ cải thiện lớn: https://www.langchain.com/blog/introducing-smithdb
Nhân tiện, tôi đang phát triển Vortex nên cũng đã suy nghĩ rất nhiều trực tiếp về câu hỏi “tại sao phải tạo định dạng mới”
Nếu cần nhiều bảng thì chỉ việc gói nhiều tệp Parquet bằng tar, và với tar cùng thư viện Parquet thì ngôn ngữ nào cũng dễ đọc, đơn giản một cách đẹp đẽ
.parquetzNếu đó là một tệp zip chứa nhiều tệp Parquet không nén thì có thể chuyển nhiều bảng trong một tệp duy nhất, đồng thời vẫn truy cập được bằng range request
Ý tưởng không phụ thuộc vào SDK hay thư viện theo từng ngôn ngữ, và nếu không có thì có thể fallback sang phương thức Wasm tích hợp sẵn, là khá sáng tạo
“Mỗi tệp F3 tự mô tả đều chứa không chỉ dữ liệu và siêu dữ liệu mà còn cả nhị phân WebAssembly (Wasm) để giải mã dữ liệu. Dung lượng lưu trữ cần để nhúng bộ giải mã vào mỗi tệp là nhỏ, chỉ ở mức kilobyte, và vẫn đảm bảo khả năng tương thích trên mọi nền tảng ngay cả khi không có bộ giải mã native”
Bộ giải mã nhúng cho PDF sẽ trông ra sao?
Vì nó gắn chặt với byte của tệp nên người tạo tệp có thể chọn kiểu định dạng nào là hợp lý, nhưng không phải mọi định dạng đều có một “bước giải mã đúng” duy nhất
Bộ giải mã sẽ giải mã thành cái gì?
Điều đó sẽ hoàn toàn phụ thuộc vào loại dữ liệu: có định dạng là luồng byte, có định dạng là mặt phẳng pixel 2 chiều, có định dạng lại cần đỉnh, mặt phẳng pixel 2 chiều và UV map, còn có trường hợp đồ thị đối tượng là cách biểu diễn tự nhiên hơn
Tôi không hiểu mọi người đang nhìn vào đâu để bàn luận
README hầu như không có thông tin về việc đây là gì hay giải quyết vấn đề gì, chỉ thấy giải thích về FlatBuffers và liên kết tới thư mục mã nguồn
Có phải tôi đã bỏ lỡ bối cảnh nào không?
Có vẻ cần thêm một chút “tại sao”
Họ nói là sẽ khắc phục các nhược điểm của Parquet, nhưng tôi muốn biết cụ thể là những nhược điểm nào
Chắc chắn không phải là hỗ trợ công cụ rộng rãi hơn
Vì sao phải rời Parquet hay ORC để dùng cấu trúc này?
Có lẽ nên đọc bài báo trước: https://doi.org/10.1145/3749163
Bài này khá thú vị: https://medium.com/@reliabledataengineering/f3-the-future-pr...
Có người gọi đây là thiên tài, nhưng nếu đóng vai một kẻ hoài nghi phiền toái kiểu HN thì nó trông hơi ngớ ngẩn
Định dạng nén dữ liệu là chuyện thứ yếu so với việc bạn sẽ làm gì với dữ liệu đó sau khi giải mã
Tệp âm thanh và ảnh SVG là hai thứ hoàn toàn khác nhau, và việc có một VM nhúng để giải nén video thành pixel thô cũng không có nghĩa là bạn có thể phát video đó trong trình soạn thảo văn bản, nên về cơ bản không tạo ra khả năng tương tác mới nào
Mỗi định dạng mới vẫn cần xử lý riêng theo từng định dạng
Ví dụ, nếu bạn tạo ra một phương pháp nén video tốt hơn H.265 nhưng không phải nền tảng nào cũng hỗ trợ, thì có thể hữu ích khi nhúng decoder để phát trên phần cứng cũ
Nhưng chính điều đó cũng bộc lộ điểm yếu. Phần cứng cũ khó có khả năng xử lý tốt các định dạng video tương lai bằng giải mã phần mềm, và kể cả ý tưởng này có xuất hiện từ thập niên 1990 thì cũng không giúp i386 xem được Netflix
Tương tự, tôi cũng nghi ngờ việc nó có thể giúp mở tệp Word 2021 bằng Word 97, vì không có ánh xạ 1:1 giữa các cấu trúc dữ liệu
Nếu kiểu tương thích này không phải là một chiến thắng rõ ràng, thì tôi không biết mục tiêu là gì
Nhược điểm thì rất rõ. Nếu decoder có lỗi cần vá, bạn sẽ vá thế nào với tất cả các tệp đã nhúng sẵn decoder đó?
Còn có cả phần overhead về kích thước và rủi ro bảo mật, vì điều này bổ sung một bề mặt tấn công đáng kể cho mọi trình phân tích định dạng, làm tăng cơ hội xảy ra thực thi mã từ xa, tấn công làm cạn kiệt tài nguyên, v.v.
Không phải lúc nào đây cũng là cách tiếp cận sai, nhưng điều quan trọng là lợi ích mang lại là gì
Nếu tìm về định dạng lưu trữ hướng cột, thì hiện nay ưu nhược điểm của chúng đã được tổng hợp khá rõ
Tất nhiên không phải để giải mã video
Một lợi thế của một số định dạng hiện đại là các công cụ có thể đọc chúng với tốc độ cảm nhận rất cao
Ví dụ, DuckDB có thể áp dụng đủ loại tối ưu hóa khi đọc định dạng native của chính nó hoặc Parquet
Nhưng tôi không rõ liệu có thể áp dụng hiệu quả những tối ưu hóa đó cho một định dạng mà để hiểu được lại phải chạy một khối Wasm hay không
Dù có SIMD hay được tối ưu SIMD đi nữa, nếu trong một lượt quét dữ liệu mà bước đó không hiểu truy vấn thì có thể bạn đã thua ngay từ đầu
Tôi mới chỉ lướt phần đầu bài báo, nên có thể định dạng thực tế ít tổng quát hơn vẻ ngoài của nó
Tôi có thể phần nào hình dung nó thay thế được các EXE tự giải nén, nhưng một phần lớn lý do để chọn một định dạng tệp cụ thể là vì những tính năng cụ thể mà định dạng đó cung cấp
Hệ thống tự mô tả cũng có thể rơi vào tình trạng giống các định dạng khác: “quá nhiều tính năng cạnh tranh và không ai xử lý hết được”
Ví dụ, tệp này có thể được
mmapmột cách hiệu quả không?Nếu nội bộ nó bắt chước tar thì có thể được, nhưng trước khi chạy thì không biết
Có thể nhảy tới một vị trí byte cụ thể và chỉ giải nén một phần không?
Biết đâu nó chỉ hỗ trợ bản tiền công bố của việc seek theo ISO-36898533, còn thư viện tệp bạn đang dùng thì đã bỏ hỗ trợ đó từ 6 năm trước
Nếu ghi lại 1MB ở giữa, bạn chỉ cần thay đúng các page tương ứng trên đĩa hay phải ghi lại toàn bộ?
Có thể khối Wasm đó hỗ trợ 97 API cho việc này, trong đó 35 cái chỉ là bản sao khác tên nên còn lớn hơn cả dữ liệu, nhưng chẳng ai bận tâm
Cuối cùng chỉ có 19 lựa chọn thực sự nhận diện được, mà bộ tăng tốc Wasm native của CPU chỉ xử lý được hai ba cái, nên có khi bạn vẫn phải đặc hóa mã rất mạnh
Ít nhất với
*.tar.gzthì còn có thể đoán được đại khái những gì làm đượcTốt thôi. Thế giới lúc nào cũng cần những định dạng dữ liệu tốt hơn
Chỉ là nếu README ghi ngay các ưu điểm so với Parquet và các định dạng tệp khác thì có lẽ sẽ thu hút được nhiều quan tâm hơn
Khi ai đó vào https://github.com/future-file-format/f3, họ nên thấy vì sao mình cần thử nó
Hãy đưa lên các lợi ích và chỉ số, thậm chí chỉ số có thể chọn những cái có lợi nhất cũng được
Có thể nó có những trường hợp sử dụng tốt, nhưng chỉ nhìn README hiện tại thì vẫn chưa rõ ai sẽ dùng và vì sao phải dùng
Nếu bạn lưu trữ dữ liệu ở quy mô PB trong hơn 10 năm, tôi sẽ không muốn phụ thuộc vào việc trong tương lai vẫn còn trình thông dịch Wasm để đọc tệp, và còn phải đủ nhanh nữa
Tôi muốn một đặc tả byte đơn giản, được tài liệu hóa tốt như Parquet
Hơn nữa, đưa logic giải mã vào trong nhị phân Wasm tức là thêm một lớp thực thi chủ động vào nơi lẽ ra nên là kho lưu trữ lạnh
Nó được sandbox và được chấp nhận rộng rãi, và Wasm cũng có cùng khả năng sandbox như vậy
Với lưu trữ dài hạn thì thậm chí còn có thể xem là tốt hơn
Không cần phải mang theo riêng chương trình giải nén, vì nó đã nằm ngay trong chính tệp archive
Nếu việc giải mã thất bại, tôi lo rằng sẽ phải debug Wasm do người khác nhúng vào, và trong đó có thể chứa các lỗi tùy ý
Sẽ hữu ích nếu dự án có một thư viện decoder tiêu chuẩn được quản lý và kiểm thử, nhưng tôi không chắc như vậy có làm mất đi lợi thế về tính linh hoạt mà cách này mang lại hay không
Tức là đây không phải vấn đề mới do hệ thống của tôi tạo ra, và họ phải có thể tái hiện nó một cách độc lập với bất kỳ client nào