Ant Group giành giải bài báo xuất sắc nhất tại VLDB: Hệ thống OmniTable tăng tốc xử lý 35PB dữ liệu AI gấp 5,6 lần

< img id="wx_img" src="https://www.qbitai.com/wp-content/uploads/imgs/qbitai-logo-1.png" width="400" height="400">

02/09/2026 14:20:17 Nguồn: QbitAI

Ant Group ra mắt hệ thống bảng rộng thống nhất OmniTable, bài báo nghiên cứu được vinh danh là bài báo xuất sắc nhất tại hạng mục công nghiệp của VLDB 2026.

Trước khi huấn luyện một mô hình ngôn ngữ lớn (LLM), dữ liệu thô cần trải qua các bước phân tích, làm sạch, khử trùng lặp, chấm điểm chất lượng, Token hóa và lắp ghép mẫu. Khi quy mô dữ liệu đạt đến cấp độ PB (Petabyte), đội ngũ kỹ thuật không chỉ đối mặt với hóa đơn chi phí điện toán mà còn phải xử lý hàng trăm bảng dữ liệu, các đặc trưng (features) ngày càng tăng, cùng những dữ liệu bất thường chỉ với vài dòng lỗi cũng có thể khiến toàn bộ lô tác vụ phải chạy lại từ đầu.

Bài báo xuất sắc nhất tại hạng mục công nghiệp của VLDB năm nay tập trung vào một khâu cực kỳ quan trọng nhưng thường bị bỏ qua trong quá trình huấn luyện LLM: chuẩn bị dữ liệu. Bài báo có tiêu đề "OmniTable: A Unified Wide-Table System for Petabyte-Scale LLM Data Curation and Exploration" giới thiệu một hệ thống bảng rộng thống nhất do Ant Group phát triển mang tên OmniTable.

(Chú thích ảnh: Bài báo "OmniTable: A Unified Wide-Table System for Petabyte-Scale LLM Data Curation and Exploration" của Ant Group được vinh danh là bài báo xuất sắc nhất hạng mục công nghiệp tại VLDB 2026, giải thưởng được trao tại hội nghị diễn ra ở Boston vào ngày 1 tháng 9.)

Link bài báo: https://www.vldb.org/pvldb/vol19/p4276-fu.pdf

Bài báo tiết lộ, OmniTable đã quản lý hơn 35 PB dữ liệu huấn luyện LLM với hơn 305 tỷ bản ghi trong môi trường sản xuất, bao phủ các lĩnh vực dữ liệu như Web, mã nguồn, PDF và SFT (Supervised Fine-Tuning). Trong một tác vụ chuẩn bị dữ liệu SFT thực tế, chu kỳ end-to-end đã giảm từ khoảng 14 ngày xuống còn 2,5 ngày, các bước thao tác thủ công giảm từ 45 bước xuống còn 12 bước.

Kết quả này không đến từ một cỗ máy nhanh hơn. OmniTable đã thay đổi cách các kỹ sư dữ liệu tổ chức dữ liệu và đặc trưng: cùng một lĩnh vực dữ liệu được trình bày ở tầng trên dưới dạng một bảng rộng logic, trong khi tầng dưới vẫn tiếp tục được phân tách theo quy mô dữ liệu, phương thức truy cập và công cụ tính toán; các đặc trưng cũng chuyển từ việc tính toán tạm thời trong script thành tài sản hệ thống có định nghĩa, phiên bản, sự phụ thuộc và nguồn gốc (lineage) rõ ràng.

Tại sao một đặc trưng lại có thể liên quan đến 106 bảng dữ liệu?

Việc xử lý dữ liệu LLM truyền thống thường xoay quanh các bảng vật lý. Sau khi một nguồn dữ liệu được kết nối, kết quả phân tích được lưu vào một bảng, kết quả làm sạch lại lưu vào một bảng khác, điểm chất lượng, nhãn lĩnh vực, chữ ký khử trùng lặp và nhãn bảo mật tiếp tục tạo ra các bảng mới hoặc kết quả trung gian. Web, mã nguồn, PDF và SFT đều duy trì các quy trình riêng biệt.

Một đường ống (pipeline) đơn lẻ thì không khó hiểu. Nhưng khi nguồn dữ liệu và đặc trưng tăng lên, các đối tượng cần duy trì sẽ phình to nhanh chóng. Để thêm một đặc trưng chất lượng, kỹ sư cần tìm tất cả các bảng liên quan, đối chiếu cột và phiên bản, sau đó cấu hình tác vụ, tài nguyên, điểm kiểm tra (checkpoint) và xử lý lỗi cho từng tập dữ liệu. Bài báo ghi lại một trường hợp thực tế: để bổ sung một đặc trưng, kỹ sư phải xử lý tới 106 bảng trên bảng điều khiển tác vụ.

Rắc rối hơn là các bảng chỉ lưu kết quả, hiếm khi ghi lại đầy đủ cách kết quả đó được tính toán như thế nào. Các UDF (User-Defined Functions) nằm rải rác trong các kho mã nguồn khác nhau, thiếu sự liên kết ổn định giữa cột đầu vào, phiên bản toán tử, lô chạy và các tác vụ huấn luyện hạ nguồn. Khi kiểm tra một mẫu bất thường, kỹ sư thường phải truy xuất qua nhiều bảng và nhiều script; một khi phiên bản đặc trưng thay đổi, họ còn phải xác định xem những lô dữ liệu lịch sử nào cần tính toán lại.

OmniTable tóm tắt những vấn đề này thành ba chi phí kỹ thuật: khó định vị dữ liệu, khó làm mới đặc trưng và khó truy xuất kết quả. Điểm khởi đầu thiết kế của hệ thống rất trực diện: biến các lô dữ liệu và cột đặc trưng thành các đối tượng hạng nhất, đưa các bảng vật lý trở về tầng thực thi lưu trữ.

Hình 1: Dữ liệu không đồng nhất sau khi đi qua các đường ống phân tán sẽ tạo thành các tập dữ liệu bị chia cắt. Nguồn: Hình 1 trong bài báo.

"Một bảng" nằm ở tầng logic

Nguyên tắc cốt lõi của OmniTable là "thống nhất về logic, phân tách về vật lý".

Ở tầng logic, mỗi hàng đại diện cho một thực thể dữ liệu có thể truy vết, mỗi cột lưu trữ trạng thái của một giai đoạn xử lý hoặc một đặc trưng phái sinh. RawData, ProcessedData và TrainableData tương ứng với dữ liệu thô, trạng thái trung gian và dạng dữ liệu có thể huấn luyện, sau đó có thể tiếp tục thêm các cột đặc trưng về chất lượng, lĩnh vực, bảo mật, khử trùng lặp, v.v.

Hai loại trường hệ thống chịu trách nhiệm căn chỉnh các cột này. _ai_unique_id_ là khóa chính toàn cục, cùng một dữ liệu trong các nguồn, giai đoạn xử lý và cột đặc trưng khác nhau đều sử dụng chung một định danh; _ai_append_name_ ghi lại lô nhập, nguồn và phiên bản. Việc làm mới dữ liệu, truy vấn điểm và truy vết nguồn gốc đều có điểm neo ổn định.

"Một bảng" ở đây là một hợp đồng logic. Môi trường sản xuất được chia thành bốn bảng rộng logic theo lĩnh vực gồm Web, mã nguồn, PDF và post-SFT, quản lý tổng cộng hơn 35 PB và hơn 305 tỷ bản ghi; các cột của mỗi bảng logic được hỗ trợ bởi nhiều bảng vật lý trong Table Family của nó và có thể tiếp tục phân tách theo hàng hoặc cột. Trong đó, bảng rộng Web lớn nhất quản lý khoảng 25 PB và hơn 300 tỷ bản ghi, bao gồm hơn 800 cột logic và hơn 200 đặc trưng đã đăng ký. Bài báo cũng cho thấy trong một thí nghiệm kiểm soát với khoảng 2 PB dữ liệu, các cột logic đã được mở rộng lên 2.500 cột.

Mối quan hệ tương ứng giữa cột logic và vị trí vật lý được lưu trong Catalog. Tầng dưới có thể phân tách hàng, cột, hợp nhất các tệp nhỏ, điều chỉnh phân vùng hoặc thiết lập các view vật chất hóa (materialized views) cho các nhóm cột tần suất cao, trong khi schema và ngữ nghĩa cột ở tầng trên vẫn giữ nguyên. Các truy vấn hạ nguồn không cần sửa đổi theo mỗi lần điều chỉnh vật lý. Bài báo cũng chỉ ra cái giá của thiết kế này: việc thiết lập kết quả vật chất hóa cho các nhóm cột nóng có thể làm tăng khoảng 8%–15% chi phí lưu trữ.

Hình 2: Catalog kết nối việc nhập dữ liệu, thực thi đặc trưng, xuất truy vấn và quản trị nền tảng. Nguồn: Hình 2 trong bài báo.

Tính toán đặc trưng chuyển từ "vẽ tác vụ" sang "khai báo cột mục tiêu"

View logic thống nhất đã giải quyết vấn đề "dữ liệu ở đâu", Catalog tiếp tục quản lý cách các đặc trưng được tạo ra.

Khi đăng ký một đặc trưng, cần ghi rõ cột đầu vào, cột đầu ra, logic UDF/SQL/suy luận mô hình, phiên bản và ưu tiên thực thi trên CPU hoặc GPU. Khi kỹ sư gửi tác vụ làm mới, chỉ cần chỉ định lô mục tiêu và đặc trưng mục tiêu. OmniTable sẽ truy vấn trạng thái tính toán hiện tại, dọc theo DAG (đồ thị có hướng không chu trình) phụ thuộc cấp cột để tìm ra bao đóng phụ thuộc tối thiểu chưa hoàn thành, sau đó tạo kế hoạch thực thi vật lý theo thứ tự topo.

Ví dụ, một điểm chất lượng phụ thuộc vào văn bản đã làm sạch, và văn bản đã làm sạch lại phụ thuộc vào kết quả phân tích. Quy trình cũ đòi hỏi kỹ sư phải xác nhận xem ba tác vụ có đầy đủ hay không và định vị riêng biệt các bảng đầu vào/đầu ra. OmniTable kiểm tra trực tiếp trạng thái của các cột này trên lô mục tiêu: kết quả đã hoàn thành sẽ được tái sử dụng, các cột tổ tiên còn thiếu sẽ được đưa vào kế hoạch. Nhiều toán tử chia sẻ đầu vào và cùng công cụ thực thi còn có thể được hợp nhất vào một lần quét duy nhất.

Sau khi tác vụ hoàn thành thành công, Catalog đăng ký nguyên tử trạng thái, phiên bản, vị trí vật lý và nguồn gốc cấp cột của "lô—cột đặc trưng"; các kết quả chưa gửi sẽ không đi vào view logic ổn định. Sau đó, khi truy vấn một cột dữ liệu, hệ thống có thể trả lời nó đã sử dụng lô đầu vào nào, phụ thuộc vào những cột cha nào, áp dụng phiên bản đặc trưng nào, được tính toán bởi công cụ gì và kết quả nằm ở vị trí nào.

Những thông tin vốn nằm rải rác trong các script, nền tảng lập lịch và ghi chép thủ công nay đã đi vào cùng một bề mặt siêu dữ liệu. Kỹ sư vẫn chịu trách nhiệm định nghĩa ngữ nghĩa đặc trưng, còn hệ thống đảm nhận việc triển khai phụ thuộc, định tuyến thực thi, quản lý trạng thái và gửi kết quả.

Hình 3: Hệ thống phân tích sự phụ thuộc, tạo kế hoạch và lập lịch tính toán đặc trưng. Nguồn: Hình 3 trong bài báo.

Một vài mẫu lỗi không còn kéo theo việc phải chạy lại cả lô dữ liệu

Trong dữ liệu thô phi cấu trúc luôn tồn tại các mã hóa bất thường, văn bản quá dài hoặc nội dung bị hỏng. Khi dữ liệu đạt đến hàng trăm triệu, hàng tỷ bản ghi, tỷ lệ bất thường dù rất thấp cũng tạo ra lượng lớn mẫu lỗi. Các tác vụ hàng loạt truyền thống thường lấy tác vụ làm đơn vị thất bại, một lỗi UDF OOM (hết bộ nhớ) hoặc quá thời gian có thể khiến toàn bộ quá trình tính toán hàng TB bị hủy bỏ.

OmniTable cô lập các lỗi UDF phổ biến xuống cấp độ bản ghi. Mỗi lần gọi UDF đều có kiểm tra thời gian chờ và bộ nhớ; khi gặp Python OOM, quá thời gian hoặc ngoại lệ không bắt được, hệ thống ghi lại ID mẫu, loại ngoại lệ và tóm tắt lỗi, ghi kết quả đó là NULL, các bản ghi còn lại tiếp tục được xử lý. Các bản ghi lỗi được đưa vào bảng lỗi (error table) thống nhất để thuận tiện cho việc sửa chữa và tính toán bổ sung sau này.

Bài báo đã thực hiện đối chứng trên một tác vụ đặc trưng với 500 GB dữ liệu, khoảng 600 triệu bản ghi. Trong dữ liệu có 31.247 bản ghi bất thường, chiếm 0,005%. Sau khi bật tính năng failover, ngoại trừ 31.247 bản ghi lỗi, khoảng 99,995% bản ghi còn lại được xử lý xong trong một lần, mất khoảng 6,2 giờ mà không cần sự can thiệp của con người; nếu tắt tính năng này, tác vụ sẽ thất bại ngay lập tức. Quy trình cũ cần ba vòng kiểm tra, xóa và gửi lại, tổng thời gian mất khoảng 52 giờ, trong đó khoảng 18 giờ là xử lý thủ công.

Việc đóng gói ở cấp độ bản ghi sẽ làm tăng khoảng 3%–5% chi phí thực thi và cũng không thể loại bỏ tất cả các lỗi như hỏng máy, mất mạng. Nó giải quyết loại vấn đề phổ biến nhất và lãng phí thời gian nhất của kỹ sư trong sản xuất: một dữ liệu bất thường đơn lẻ làm sập toàn bộ lô tác vụ.

Quét một lần tính nhiều cột, CPU và GPU làm đúng công việc phù hợp của mình.