6 điểm bởi GN⁺ 2025-10-07 | 1 bình luận | Chia sẻ qua WhatsApp
  • OpenZL do Meta công bố là một khung nén mã nguồn mở mới cung cấp nén không mất dữ liệu cho dữ liệu có cấu trúc, nhận biết định dạng dữ liệu để thực hiện quá trình biến đổi hiệu quả
  • Mỗi định dạng tệp áp dụng các bước biến đổi khác nhau, nhưng được thiết kế để mọi tệp đều có thể được giải nén bằng một bộ giải nén đa dụng duy nhất
  • Bằng cách truyền tường minh cấu trúc dữ liệu cho bộ nén, hệ thống tối ưu hóa quá trình biến đổi và có thể chọn nhiều điểm cân bằng khác nhau giữa tốc độ và tỷ lệ nén thông qua cấu hình nén (config) đã được huấn luyện
  • Điểm nổi bật là khả năng tích hợp với hệ thống Managed Compression nội bộ của Meta, cho phép tự động huấn luyện lại và cập nhật theo sự thay đổi của dữ liệu
  • Thể hiện hiệu năng cao trên các tập dữ liệu có cấu trúc rõ ràng, giúp cải thiện hiệu quả xử lý của trung tâm dữ liệu và gợi mở khả năng đơn giản hóa hệ sinh thái nén bằng một bộ giải mã duy nhất

Tổng quan về OpenZL

  • OpenZLkhung nén dữ liệu nhận biết định dạng do Meta công bố, cung cấp hiệu quả nén chuyên biệt cho dữ liệu có cấu trúc
    • Khi định dạng dữ liệu được cung cấp một cách tường minh, hệ thống dùng đồ thị biến đổi nội bộ để tìm ra tính quy luật và sự lặp lại trong dữ liệu nhằm nén hiệu quả hơn
  • Đây là khái niệm kế thừa của Zstandard, kết hợp hiệu năng của nén tối ưu theo từng định dạng với tính dễ bảo trì của một tệp thực thi duy nhất
    • Zstandard đã tạo ra bước nhảy lớn trong trung tâm dữ liệu khi đồng thời đáp ứng tốc độ và tỷ lệ nén, nhưng vẫn tồn tại giới hạn cải tiến dần do tính tổng quát của thuật toán
  • Với dữ liệu có cấu trúc, nén tùy biến theo đúng hình thái dữ liệu có lợi hơn cả về tỷ lệ lẫn tốc độ so với phương pháp nén tổng quát
  • Tuy nhiên, việc xây dựng và vận hành bộ nén/khôi phục chuyên dụng cho từng định dạng tệp tạo ra gánh nặng lớn
  • OpenZL theo đuổi đồng thời hiệu năng của các bộ nén tùy chỉnh riêng lẻ và sự tiện lợi khi vận hành một binary duy nhất

Phương pháp nén dựa trên cấu trúc

  • Trong khi các bộ nén thông thường xử lý dữ liệu theo kiểu suy đoán, OpenZL nhận cấu trúc dữ liệu như đầu vào tường minh
    • Người dùng có thể mô tả hình dạng dữ liệu (hàng, cột, enum, cấu trúc lồng nhau, v.v.) thông qua Simple Data Description Language (SDDL)
    • Dựa trên thông tin này, OpenZL tạo ra chuỗi biến đổi tối ưu (Plan) thông qua quá trình huấn luyện ngoại tuyến (trainer)
    • Sau đó khi nén, hệ thống tạo đồ thị giải mã thực tế (Resolved Graph) dựa trên Plan này và nhúng nó vào frame

Ví dụ: nén dữ liệu SAO

  • Lấy tệp SAO trong Silesia Compression Corpus làm ví dụ, OpenZL tách từng trường để chuyển thành các luồng dữ liệu đồng nhất, rồi tối ưu riêng cho từng luồng
    • Tọa độ trục X (SRA0) có xu hướng được sắp xếp nên áp dụng biến đổi delta
    • Tọa độ trục Y (SDEC0) tận dụng giới hạn phạm vi để áp dụng biến đổi transpose
    • Các trường còn lại có số lượng giá trị phân biệt thấp nên dùng biến đổi tokenize để nén dựa trên từ điển
  • Kết quả là đạt tỷ lệ nén hơn 2 lần so với zstd và tốc độ nhanh hơn (340 MB/s)

Tạo bộ nén tự động và quá trình huấn luyện

  • Trainer của OpenZL tự động khám phá và học chiến lược nén dựa trên các mẫu dữ liệu
    • Quy trình huấn luyện: describe(SDDL) → train(tạo Plan) → compress(nhúng đồ thị) → decode(khôi phục bằng một binary duy nhất)
    • Sử dụng control points để chọn đường đi tối ưu tại thời điểm chạy dựa trên thông tin thống kê
    • Ngay cả khi áp dụng Plan mới, dữ liệu hiện có vẫn có thể giải mã nguyên vẹn, duy trì khả năng tương thích ngược

Ưu điểm của bộ giải nén đơn nhất

  • OpenZL cho phép mọi dữ liệu đã nén bằng bất kỳ định dạng nào đều được khôi phục bằng một binary giải nén duy nhất
    • Chỉ cần thực hiện kiểm chứng bảo mật và độ ổn định một lần là có thể áp dụng cho toàn hệ thống
    • Khi cập nhật bộ giải nén, mọi dữ liệu cũ cũng được hưởng lợi từ cải thiện hiệu năng
    • Đảm bảo sự đơn giản trong vận hànhtính nhất quán trên toàn bộ fleet
    • Có thể quản lý đồng thời nhiều định dạng mà vẫn duy trì tương thích ngược

Kết quả so sánh hiệu năng

  • Trên nhiều tập dữ liệu, đạt tỷ lệ nén và tốc độ cao hơn so với các bộ nén đa dụng như zstd, xz
    • SAO: tỷ lệ nén 2.06 lần, tốc độ khôi phục 1200 MB/s
    • ERA5 (dữ liệu số): đạt tỷ lệ nén cao hơn trong cùng một khoảng thời gian, hoặc tốc độ nhanh hơn ở cùng một tỷ lệ nén
    • Với các tập dữ liệu Parquet, CSV cũng có thể tối ưu hóa tùy biến dựa trên nhận biết định dạng
  • Tuy nhiên, với dữ liệu không có cấu trúc như dữ liệu dạng văn bản, hiệu quả bị hạn chế và hệ thống sẽ fallback sang zstd để đảm bảo mức hiệu năng tối thiểu
  • Có thể lựa chọn nhiều tổ hợp khác nhau trên 3 trục tỷ lệ nén/tốc độ nén/tốc độ khôi phục, mang lại độ linh hoạt khác với việc chỉnh “level” của bộ nén truyền thống

Sự tiến hóa của dữ liệu và tái huấn luyện tự động

  • Tích hợp với Managed Compression của Meta để tự động học lại kế hoạch nén khi định dạng dữ liệu thay đổi
    • Lấy mẫu, đánh giá định kỳ và tự động cập nhật khi phát hiện Plan tốt hơn
    • Bộ giải nén vẫn được giữ nguyên nên giảm thiểu rủi ro vận hành

Tham gia hệ sinh thái mã nguồn mở và hướng đi tiếp theo

  • OpenZL phù hợp với dữ liệu dạng vector, bảng và cây, đồng thời cho thấy hiệu quả nổi bật với chuỗi thời gian, tensor ML, bảng cơ sở dữ liệu, v.v.
  • Với văn bản không có cấu trúc (ví dụ: enwik, dickens, v.v.), hệ thống dùng zstd
  • Kế hoạch sắp tới:
    • Mở rộng thư viện biến đổi cho dữ liệu chuỗi thời gian và dữ liệu lưới
    • Tăng cường khả năng biểu diễn dữ liệu lồng nhau của SDDL
    • Cải thiện hiệu năng và độ ổn định của trình khám phá bộ nén tự động
  • Cách tham gia cộng đồng:
    • Có thể tham khảo ví dụ và tài liệu trên trang OpenZL chính thứckho GitHub
    • Thử nghiệm các định dạng dữ liệu mới và đề xuất Plan
    • Có thể đóng góp tối ưu hóa engine C/C++, thêm biến đổi mới, và benchmark

Kết luận

  • OpenZL là một cách tiếp cận mới, vừa chuẩn hóa nén dựa trên nhận biết định dạng, vừa có thể hợp nhất hệ sinh thái hiện có xoay quanh một bộ giải mã duy nhất
  • Thông qua đó, Meta muốn đồng thời cải thiện hiệu quả nén, tốc độ và khả năng bảo trì trên toàn bộ trung tâm dữ liệu

1 bình luận

 
GN⁺ 2025-10-07
Ý kiến Hacker News
  • Gần đây sau khi đọc bài trên HN về nén dữ liệu bộ gen (liên kết), tôi đã phải rất cố kiềm chế không nhắc đến OpenZL; đó là một ví dụ rất rõ cho thấy chỉ cần những phép biến đổi thật đơn giản trên dữ liệu cũng có thể cải thiện mạnh hiệu quả nén, và OpenZL cũng có thể dễ dàng thực hiện kiểu biến đổi này ở bên trong (dùng SDDL)
    • Tôi cũng nghĩ ngay tới bài đó; không biết có ai đã từng so sánh bộ nén chuyên dụng được nhắc ở đó với OpenZL chưa. Ví dụ, bộ dữ liệu Grace Blackwell 2.6Tbp 661k là một benchmark kinh điển cho bộ gen vi sinh vật, và phương pháp MiniPhy của Karel Břinda đã giảm nó từ 2.46TiB xuống 27GiB (tỷ lệ nén 91). Tôi tò mò liệu có thể đạt kết quả tương tự không
    • Tôi muốn xem kết quả benchmark trên các định dạng bộ gen phổ biến (fa, fq, sam, vcf), đặc biệt là khả năng áp dụng cho dữ liệu nanopore. Việc lưu FAST5/POD5 rất khó, nên chúng tôi đang mất đi rất nhiều dữ liệu hữu ích
    • [0] Tôi là tác giả bài viết; chúc mừng vì đã kiềm chế được, làm tốt lắm. Tôi rất muốn thử nó. Ngoài hướng dẫn OpenZL về huấn luyện bộ nén fasta (liên kết), không biết còn lời khuyên nào thêm không
  • Một chuyện hơi liên quan là gần đây có thảo luận về định dạng tệp F3 (liên kết); ở đó cũng có thể nén theo nhận biết định dạng bằng cách nhúng mã decompressor dưới dạng WASM. Động lực chính của F3 là khả năng tương thích trong tương lai, nhưng nó cũng có thể dùng thuật toán nén tùy chỉnh. Cách tiếp cận hoàn toàn khác OpenZL, và OpenZL cũng nhẹ phụ thuộc hơn nhiều (chỉ cần SDDL compiler/runtime)
    • zpaq cũng đã có tính năng decompressor nhúng suốt 15 năm rồi, tiếc là không thấy được nhắc đến
    • Tôi lo việc đưa mã có thể thực thi vào tệp nén sẽ làm tăng nguy cơ lỗ hổng virus
  • Tôi ngạc nhiên khi có một công cụ tốt đến vậy xuất hiện; theo tôi đáng ra nó nên có từ sớm hơn nhiều. Nếu hiểu đúng cấu trúc của container dữ liệu thì hiệu quả khử trùng lặp tăng lên rất lớn. Giấy phép BSD-3-Clause, triển khai C++ gọn gàng, tài liệu cũng rất tốt; tôi hy vọng sẽ thấy thêm nhiều định dạng tệp được bổ sung
    • Đặc tả theo định dạng tệp vốn đã là một cách làm có từ trước (ví dụ: x86 opcode prefilter của 7-Zip, nhúng specialized decoder bytecode của ZPAQ), nhưng phần triển khai thực tế, cách mô tả dữ liệu và hệ thống huấn luyện của OpenZL rất ấn tượng
  • Nếu tôi hiểu đúng, có vẻ như khi mô tả cấu trúc dữ liệu bằng SDDL, bộ nén có thể xây dựng chiến lược nén tối ưu cho từng phần. Trông thật tuyệt; tôi hy vọng nó có thể phát triển thành một framework tổng quát cho nén định dạng tùy chỉnh
    • Đúng vậy! SDDL (liên kết) cung cấp một bộ công cụ no-code để làm việc này. Tính năng hiện vẫn còn hạn chế nhưng dự kiến sẽ mở rộng thêm. Trước đó, bạn cũng có thể tự viết parser định dạng bằng C++ hoặc Python. Xin lưu ý là đoạn mã này chỉ cần ở phía bộ nén; còn decompressor hoạt động độc lập với định dạng
  • Không biết công cụ này có hỗ trợ seekable compression không
  • Khi đọc tài liệu, tôi tự hỏi AI sẽ chuyển các mô tả kỹ thuật hiện có như imhex, Kaitai sang SDDL tốt đến mức nào. Nếu làm được như vậy thì có vẻ sẽ nhanh chóng thu thập được nhiều schema tốt
    • Đây là lần đầu tôi biết đến các công cụ kiểu này, nhưng có vẻ thật sự có thể chuyển sang SDDL được. Tôi nhất định sẽ kiểm tra thử
  • Nimble của Meta đã tích hợp OpenZL (phiên bản trước khi OSS) theo cách native và đang thu được lợi ích rất lớn
    • Nén backend cho định dạng dữ liệu dạng cột cực kỳ hợp với OpenZL. Khi biết dữ liệu cần nén là các số như i64 hay float thì có thể có lợi thế lớn ngay so với Zstandard
  • Tôi tò mò liệu OpenZL có phù hợp cho dữ liệu log (log JSON chưa chốt schema) hay không; tôi đang phát triển một công cụ nén log (liên kết)
  • Non-Linear Compression (nén phi tuyến) trước đây tôi cũng từng có chút ý tưởng và thử qua nhưng không đi được xa (liên kết); rất vui khi thấy những nỗ lực như thế này, cảm ơn vì đã chia sẻ
  • Trông thú vị đến mức điên rồ thật sự; tối nay tôi nhất định sẽ thử nó trên một lượng lớn CSV
    • Sẽ rất tuyệt nếu bạn chia sẻ trải nghiệm sử dụng. OpenZL ban đầu được phát triển cho mục đích sử dụng nội bộ tại Meta, và gần đây đã đầu tư nhiều công sức để người dùng bên ngoài cũng có thể dùng dễ dàng hơn. Rất hoan nghênh phản hồi của bạn