螞蟻集團 投稿
量子位 | 公眾號 QbitAI
訓練一個大模型之前，語料需要經過解析、清洗、去重、質量評分、Token化和樣本組裝論文。
規模來到PB級，工程團隊每天面對的不止算力賬單，還有數百張表、不斷增加的特徵，以及少數幾條就可能讓整批任務重跑的異常資料論文。
以此為背景，論文《OmniTable: A Unified Wide-Table System for Petabyte-Scale LLM Data Curation and Exploration》介紹了一套由螞蟻集團研發的統一寬表系統——OmniTable論文。論文已獲今年的VLDB工業賽道最佳論文，聚焦的正是大模型訓練中非常重要，但也常被忽視的環節——資料準備。
△螞蟻集團論文獲評VLDB 2026工業賽道最佳論文論文，9月1日在波士頓舉行的大會上獲頒獎項
展開全文
論文披露，OmniTable已在生產環境管理超過35PB、3050億條以上的大模型訓練資料，覆蓋Web、程式碼、PDF和SFT等資料域論文。在一項真實SFT資料準備任務中，端到端週期從約14天縮短到2.5天，手工操作步驟從45步降至12步。
這個結果並非來自一臺更快的機器論文。OmniTable改了資料工程師組織資料和特徵的方式：同一資料域在上層呈現為一張邏輯寬表，底層繼續按資料規模、訪問方式和計算引擎拆分；特徵也從指令碼中的臨時計算，變成帶有定義、版本、依賴和血緣的系統資產。
一個特徵論文，為什麼會牽出106張表
傳統的大模型資料加工通常圍繞物理表展開論文。一個資料來源接入後，解析結果落一張表，清洗結果再落一張，質量分、領域標籤、去重簽名和安全標記繼續產生新的表或中間結果。Web、程式碼、PDF、SFT又各自維護一套流程。
單條管道並不難理解論文。資料來源和特徵持續增加後，維護物件會迅速膨脹。新增一個質量特徵，工程師需要先找到所有相關表，核對欄位和版本，再為每個資料集配置任務、資源、檢查點和失敗處理。論文記錄了一個實際案例：為了補一個特徵，工程師需要在任務畫布上處理106張表。
更麻煩的是，表只儲存結果，很少完整記錄結果是怎樣算出來的論文。UDF分散在不同程式碼庫，輸入列、運算元版本、執行批次和下游訓練任務之間缺少穩定關聯。排查一條異常樣本時，工程師往往要跨表、跨指令碼追溯；特徵版本一旦變化，還要判斷哪些歷史批次需要重新計算。
OmniTable將這類問題概括為三項工程成本：資料難定位、特徵難回刷、結果難追溯論文。系統的設計起點也很直接——讓資料批次和特徵列成為一等物件，把物理表退回到儲存實現層。
△異構資料經過分散管道後形成彼此割裂的資料集論文。來源：論文Figure 1“一張表”位於邏輯層
OmniTable的核心原則是“邏輯統一、物理分離”論文。
在邏輯層，每一行代表一條可追蹤的資料實體，每一列儲存某個處理階段的狀態或一項衍生特徵論文。RawData、ProcessedData和TrainableData分別對應原始資料、處理中間態和訓練可用形態，後面還可以繼續新增質量、領域、安全、去重等特徵列。
兩類系統欄位負責把這些列對齊論文。_ai_unique_id_是全域性主鍵，同一條資料在不同來源、處理階段和特徵列中使用同一個標識； _ai_append_name_記錄接入批次、來源和版本。資料回刷、點查和血緣追蹤都有了穩定錨點。
這裡的“一張表”是一份邏輯契約論文。生產環境按Web、程式碼、PDF和post-SFT劃分為四張領域邏輯寬表，合計管理35+PB、3050億條以上記錄；每張邏輯表的列由其Table Family中的多張物理表承載，並可繼續按行、按列拆分。其中最大的Web寬表管理約25PB、3000億條以上記錄，包含800多個邏輯列和200多個已註冊特徵。論文還在固定約2PB資料的受控實驗中將邏輯列擴充套件到2500列。
邏輯列與物理位置的對應關係由Catalog儲存論文。底層可以拆行、拆列、合併小檔案、調整分割槽，或為高頻列組建立物化檢視，上層的schema和列語義保持不變。下游查詢無需跟著每次物理調整修改。論文也給出了這項設計的代價：為熱點列組建立物化結果，可能增加約8%–15%的儲存開銷。
△Catalog連線資料接入、特徵執行、查詢匯出與後臺治理論文。來源：論文Figure 2特徵計算從“畫任務”改成“報目標列”
統一邏輯檢視解決了“資料在哪”的問題，Catalog繼續管理特徵怎樣產生論文。
一個特徵註冊時，需要寫清輸入列、輸出列、UDF/SQL/模型推理邏輯、版本，以及CPU或GPU的執行偏好論文。工程師提交回刷任務時，只需指定目標批次和目標特徵。OmniTable會查詢當前計算狀態，沿列級依賴DAG找到尚未完成的最小依賴閉包，再按拓撲順序生成物理執行計劃。
例如，某個質量分依賴清洗文字，而清洗文字又依賴解析結果論文。舊流程需要工程師確認三段任務是否齊全，並分別定位輸入輸出表。OmniTable直接檢查這些列在目標批次上的狀態：已經完成的結果複用，缺失的祖先列進入計劃。共享輸入、執行引擎相同的多個運算元還能合併到一次掃描中。
任務成功完成後，Catalog原子登記“批次—特徵列”的狀態、版本、物理位置和列級血緣；未提交的結果不會進入穩定邏輯檢視論文。此後再查詢一列資料，系統能夠回答它用了哪個輸入批次、依賴哪些父列、採用哪個特徵版本、由什麼引擎計算，以及結果落在什麼位置。
過去分散在指令碼、排程平臺和人工記錄裡的資訊，由此進入同一個後設資料面論文。工程師仍然負責定義特徵語義，系統接手依賴展開、執行路由、狀態管理和結果提交。
△系統解析依賴、生成計劃並排程特徵計算論文。來源：論文Figure 3少數壞樣本，不再拖著整批資料重跑
非結構化語料裡總會混入異常編碼、超長文字或損壞內容論文。資料達到數億、數十億條後，極低的異常比例也會產生大量壞樣本。傳統批任務常以任務為失敗單位，一次UDF OOM或超時就可能讓多TB計算整體退出。
OmniTable把常見UDF故障隔離到記錄級論文。每次UDF呼叫帶有超時和記憶體檢查；遇到Python OOM、超時或未捕獲異常時，系統記錄樣本ID、異常型別和錯誤摘要，將該條結果寫為NULL，其餘記錄繼續處理。錯誤記錄統一進入error table，方便後續修復和補算。
論文在一個500GB、約6億條記錄的特徵任務上做了對照論文。資料中有31247條異常記錄，佔0.005%。開啟failover後，除31247條異常記錄外，其餘約99.995%的記錄一次處理完成，耗時約6.2小時，無需人工介入；關閉該能力，任務直接失敗。舊流程需要三輪排查、刪除和重提，總耗時約52小時，其中約18小時是人工處理。
記錄級包裝會增加約3%–5%的執行開銷，也無法消除機器故障、網路中斷等所有失敗論文。它處理的是生產中最常見、也最浪費工程師時間的一類問題：單條異常資料拖垮整批任務。
一次掃描多算幾列論文，CPU和GPU各做合適的工作
大模型資料特徵的計算形態差異很大論文。文字長度、字元比例和規則過濾通常適合CPU或SQL；模型推理既可能執行在CPU，也可能交給GPU，取決於模型規模、運算元畫像與資源條件。OmniTable根據使用者宣告、運算元畫像、引擎能力和叢集負載，在Spark、MaxCompute SQL與GPU推理平臺之間選擇執行後端，並結合歷史執行資訊調整資源引數。
路由之外，重複掃描也是一筆大開銷論文。多個特徵讀取同一列、執行在同一引擎時，OmniTable會把它們融合成一個任務，一次讀取產生多列結果。
在論文的運算元融合實驗中，8個CPU/Spark特徵都讀取parsed_text論文。測試資料約2.5PB、3000億條以上。融合後，掃描次數從8次降為1次，CPU Hours從4.2萬降到1.85萬，減少55.9%；端到端時間從38小時降到14小時，提速2.7倍。
自適應調優則用於減少引數試錯論文。針對50GB、500GB和2TB三種批次規模的受控實驗，OmniTable的自適應配置首次提交成功率為100%，任務成本與專家手調相差不超過5%。這組結果對應特定BERT特徵任務，說明系統能夠給出接近專家配置的可用引數，並不代表任意任務都能自動達到最優。
△運算元融合減少重複掃描，自適應調優在不同批次規模下接近專家配置論文。來源：論文執行評測。邏輯表持續變寬，後臺持續整理物理佈局
寬表上線後仍會不斷增加批次和特徵論文。小檔案累積、分割槽傾斜、列數增長和查詢熱點變化都會拖慢訪問。OmniTable的後臺治理服務持續觀察這些指標，自動執行小檔案合併、行拆分、列拆分和物化檢視構建。
治理過程採用Prepare—Execute—Commit：先準備新佈局並完成物理重寫，驗證透過後，再原子切換Catalog對映論文。舊佈局在切換前繼續服務查詢，失敗的治理任務可以回滾。使用者仍然查詢同一組邏輯列，無需感知檔案和表族怎樣變化。
△後臺治理根據規模和訪問模式調整物理佈局論文。來源：論文Figure 4
列拆分讓邏輯schema可以越過單個引擎的物理列數限制論文。在固定約2PB資料、查詢列集合不變的測試中，邏輯列從200增至2500，P95延遲約從25秒升到38秒，跨過了底層引擎約1200列的物理上限。另一組規模測試覆蓋1TB到25PB，過濾匯出吞吐保持在18–23TB/小時。
單樣本排查走另一條路徑論文。全域性ID索引直接把ai_unique_id定位到物理表、分割槽和row group。在25PB、3000億條以上記錄、800多個邏輯列的Web資料上，查詢完整邏輯行的P50為8.3秒，P99為14.7秒；全掃描分別需要184秒和612秒以上。
需要一次匯出多列時，後臺物化檢視會預先消除熱點列組之間的JOIN論文。一個涉及15列、4張物理表的代表性場景中，過濾匯出吞吐從4.8TB/小時提升到20.1TB/小時。點查、批次篩選和大規模匯出使用不同路徑，Catalog為它們提供統一入口。
5.6倍提速論文，主要省下的是協調和重跑時間
論文用一個真實SFT資料準備任務做了端到端對照論文。任務包含8個資料來源和12個特徵，其中9個是CPU UDF，3個是GPU推理。
舊流程需要約2天定位和接入資料，約9.5天完成特徵回填，再花約2.5天編寫多表JOIN並匯出結果，總週期約14天論文。過程中涉及約45個手工步驟、24條獨立管道或指令碼，以及35張物理表。
OmniTable將接入階段縮短到約0.5天，特徵回填約1.7天，過濾匯出約0.3天，總計約2.5天論文。手工步驟降至12個，獨立命令降至10條，使用入口是一張SFT領域邏輯寬表。端到端提速5.6倍，手工操作步驟減少73.3%，獨立管道和指令碼減少58.3%。
△SFT資料準備任務從約14天縮短至約2.5天論文。來源：論文端到端實驗
這組數字只對應論文評測中的同一項生產任務論文。它清楚展示了時間省在什麼地方：逐表編排變少，共享輸入不再重複掃描，少量異常不會頻繁觸發整批重跑，物理佈局也不必等到效能下降後再人工調整。
寬表只是入口論文，完整生命週期才是重點
OmniTable把過去分散在多套工具裡的四類資訊放到一起管理：資料批次、特徵定義、執行狀態和列級血緣論文。邏輯寬表為使用者提供穩定入口，Catalog維護資料與特徵之間的關係，執行和治理服務繼續在底層選擇合適的物理組織。
這套做法也有明確成本論文。熱點列物化需要額外儲存，記錄級容錯會增加少量執行開銷，後臺治理要佔用叢集資源。不同企業的資料域、計算引擎和團隊習慣也不相同，因此OmniTable更適合作為一套經過35+PB生產部署檢驗的系統設計參考。它給出的思路是：先穩定邏輯語義，再讓物理佈局持續演進。
當大模型訓練進入PB時代，資料工程的挑戰已不再是把一次任務跑通，而是讓持續增長的資料、特徵和計算長期保持可管理論文。OmniTable試圖節省的，也不只是機器執行的時間，還有工程師反覆找表、補任務和排查異常的時間。
論文連結論文：
