F3：SIGMOD 2026 開源資料檔案格式，要解決 Parquet 十年沒解決的問題

編按：本文綜合整理自 GitHub: future-file-format/f3 專案 README 與其 SIGMOD 2026 paper，並加入 Siami 編輯部觀點與分析。

CMU 與資料庫產業的學者（Xinyu Zeng、Ruijun Meng、Andrew Pavlo、Huanchen Zhang 等）把論文投進 SIGMOD 2026，並把整套實作開源放出來——F3（Future-proof File Format）宣稱要解決 Parquet、ORC 這些十年老格式「硬體跑太快、改不動」的窘境。

F3 是什麼？

F3 是一個開源欄位儲存格式（columnar file format），主打三大設計原則：

• 效率（Efficiency）：資料佈局修正 Parquet 等上個世代格式的缺點
• 互通性（Interoperability）：跨平台讀寫，不要「裝完才能用」
• 擴充性（Extensibility）：靠內嵌的 WebAssembly（Wasm）解碼器自帶未來擴充能力（這就是所謂的「future-proof」的由來）

每一個 F3 檔案都是自描述的（self-describing）——同時包含資料、元資料、以及 Wasm 二進位檔案。意思是，就算十年後硬體環境又翻一輪，只要 Wasm runtime 還活著，讀這個檔的人就不用再等 SDK 改版。

為什麼這件事重要

Parquet 跟 ORC 都是 2013 年前後誕生的格式，當時還在用機械硬碟、HDD 隨機讀寫慢，所以設計時把重點放在「壓縮比 + 循序讀取」。但 2026 年的場景完全不同：

• NVMe SSD + Optane 已成主流：循序 vs 隨機的差距從 100x 縮到 5x，Parquet 早期那些「為 HDD 優化」的設計變成包袱
• GPU 加速查詢（如 RAPIDS、cuDF）：需要更精細的記憶體佈局，Parquet 的 row group 切法常常讓 GPU 算力閒置
• 雲端物件儲存（S3、R2）：HTTP GET 的 latency 是 HDD 的 1000 倍，格式本身的 metadata 設計直接決定查詢要 round-trip 幾次

Siami 認為：F3 的真正賣點不是「比 Parquet 壓縮比更高」（雖然 paper 裡有 benchmark 數字），而是它把格式演進的主導權還給了使用者。Wasm decoder 這招等於是「在格式裡內建升級路徑」，這是 Parquet 社群吵了十年都沒吵出來的東西。

數據解讀與質疑

論文摘要直接點出 Parquet 的問題：「格式本身的缺陷，常常需要整個系統重寫才能繞過」。F3 團隊的解法是：

• 用 FlatBuffer 當 schema 定義語言（比 Parquet 的 Thrift 更現代）
• 用 Wasm 內嵌解碼器處理「這格式未來還沒發明出來的新編碼」
• Benchmark 顯示在某些場景比 Parquet 快 2-5x（具體數字要看 paper 完整版）

不過 Siami 編輯部要誠實說三個疑點：

1. README 寫得太空泛。HN 上 Arainach 直接吐槽：「沒解釋這是做什麼的檔案格式、沒範例、只丟一堆我沒聽過的名詞」。這對開源專案是大忌——第一印象的 doc 決定 90% 的人會不會繼續看。
2. 8 個月沒新 commit（adammarples 在 HN 點出）。SIGMOD 論文週期長，但 release 後 8 個月沒動靜，會讓社群懷疑「會不會又是一個學術 prototype 發完 paper 就沒人維護」。
3. 生態系是零。Parquet 有 Pandas、Spark、DuckDB、Polars、Arrow 全套支援；F3 目前只有 fff-poc 這個 PoC crate。沒有人會為了「理論上比較快」就放棄整條已經能跑的資料管線。

業界怎麼看？

HN 討論串 573 分、126 則留言裡，主流聲音有三種：

「請直接告訴我為什麼我要離開 Parquet」 — largbae, HN

「Nice! 世界總是能容納更好的檔案格式。但請把 Parquet 的缺點直接寫在 README」 — owentbrown, HN

「Wasm 解碼器的 fallback 設計很天才——不用依賴特定語言 SDK」 — gavinray, HN

Siami 觀點：F3 真正的機會不在「取代 Parquet」，而在雲端原生 + GPU 加速這個新場景。DuckDB 跟 Polars 已經證明「嵌入式 columnar engine」可以吃下原本屬於 Spark 的市場；下一輪換成「GPU 原生檔案格式」時，F3 的 Wasm 設計就有機會變成標準介面。

結論：研究原型，不是馬上能用的東西

作者自己也在 README 標註：「This project is a research prototype verifying the ideas in the paper. You should not use it in production.」

• ✅ 適合：學術研究、Wasm 在資料格式上的可行性驗證、追蹤 SIGMOD 2026 論文進度
• ❌ 不適合：直接拿來替換你 production 的 Parquet / ORC 管線

引用格式（從 README 摘錄）：

@article{zeng2025f3,
  author = {Zeng, Xinyu and Meng, Ruijun and Prammer, Martin and McKinney, Wes and Patel, Jignesh M. and Pavlo, Andrew and Zhang, Huanchen},
  title = {F3: The Open-Source Data File Format for the Future},
  year = {2025},
  doi = {10.1145/3749163}
}

想看完整 paper：https://doi.org/10.1145/3749163（ACM Digital Library） 想跑實驗：git submodule update --init --recursive && ./scripts/setup_debian.sh && cargo test -p fff-poc

這篇文章由 Siami 編輯部根據 GitHub 開源專案與 SIGMOD 2026 論文整理，並加入產業分析觀點。資料引用請見上方論文 DOI 與 GitHub 連結。

延伸閱讀

• F3 GitHub 專案 — 完整 source code、benchmark 程式碼、重現步驟
• SIGMOD 2026 paper（DOI: 10.1145/3749163） — 學術全文，含完整 benchmark 數據
• HN 討論串（573 分 / 126 留言） — 第一手業界反應
• Apache Parquet 官方文件 — 理解「為什麼需要 F3」的對照組