世界を動かす技術を、日本語で。

F3

2026年6月24日原文(github.com)

概要

  • F3 は効率性・相互運用性・拡張性を重視した次世代データファイルフォーマット
  • Parquet 等の従来形式の課題を解決しつつ、Wasmデコーダで将来性を確保
  • 研究プロトタイプ として公開、本番環境での利用は非推奨
  • ビルドや実験手順は Debian 12 環境で検証済み
  • MITライセンス で公開、論文引用情報も提供

F3: 次世代データファイルフォーマットの概要

  • F3 は効率的なデータ管理・高度な相互運用性・将来の拡張性を設計思想とするファイルフォーマット
  • Parquet など既存フォーマットのレイアウト上の課題を解消
  • Wasm(WebAssembly)デコーダ をファイル内に埋め込み、将来の互換性と拡張性を実現
  • 自己記述型 ファイル構造により、データ・メタデータ・デコーダバイナリを一体管理
  • プラットフォーム非依存でデコード可能、ネイティブデコーダがなくても動作保証
  • 新しいエンコーディング方式 の追加が容易な汎用APIを提供

利用上の注意

  • 本プロジェクトは 論文発表用の研究プロトタイプ
  • 本番環境での利用は推奨されていない
  • 実装・ビルドは Intel + Debian 12 マシンでのみ検証済み

ビルドと実行手順

  • リポジトリ初期化
    • git submodule update --init --recursive
  • 依存パッケージセットアップ
    • ./scripts/setup_debian.sh
  • PoCパッケージのビルド
    • cargo build -p fff-poc
  • ユニットテスト実行
    • cargo test -p fff-poc

重要ディレクトリ構成

  • format: FlatBufferによるファイルフォーマット定義
  • fff-poc: F3フォーマットのメインコード
    • fff-core, fff-encoding, fff-format, fff-ude-wasm などサブディレクトリを参照
  • fff-bench: 論文掲載のベンチマーク・実験コード
    • fff-bench/examples: マイクロ・E2E実験コード収録
  • fff-ude *: UDE(User-Defined-Encoding)、Wasmデコーダ実装関連
  • scripts, exp_scripts: 実験実行用スクリプト群

実験結果再現方法

  • 詳細手順は doc/paper_reproduction.md を参照

ライセンス

  • MITライセンス で公開
  • 詳細は LICENSE ファイルを参照

論文引用情報

  • 論文タイトル: F3: The Open-Source Data File Format for the Future
  • 著者: Zeng, Xinyu 他
  • 掲載誌: Proc. ACM Manag. Data
  • 発行年: 2025年9月
  • DOI: 10.1145/3749163
  • キーワード: カラムナストレージ、圧縮、拡張性、ファイルフォーマット

F3の特徴と意義

  • カラムナストレージ 形式による現代的なデータ分析システム基盤
  • オープンソース ファイルフォーマットの普及で異なるプラットフォーム間のデータ共有を促進
  • 従来形式 (Parquet, ORC等)は時代遅れの設計や制約が残存
    • 部分的な仕様更新も、全てのシステムでサポートされず
    • 抜本的な改善には新フォーマットの設計が必要
  • F3 は「新たなデータ処理・計算環境の変化ごとに新フォーマットを作る必要性」を解消
  • 自己記述型ファイルWasmデコーダ埋込 で最大限の互換性と拡張性
  • ストレージレイアウトの有効性Wasm駆動デコードの利点 を実証

参考情報

  • 本プロジェクトが有用な場合、上記論文を 引用 することを推奨

Hackerたちの意見

このプロジェクトのREADMEはあまり役に立たないね。プロジェクトが何をするのか全然説明してないし(ファイルフォーマットって何のため?聞いたことない他のものを名前だけ挙げても意味ないよ)。例もないし。フラットバッファのスキーマへのリンクはあるけど、あれはコメントがしっかりしてる分、実装の詳細が深すぎる。要するに、2〜3分で「なんでこれが必要なの?」って納得できないし、将来的に役立つシナリオに出会ったときに思い出すほどの情報もない。

効率性、相互運用性、拡張性を考えて設計されている。 「データの組織化を提供し、Parquetのような旧世代フォーマットのレイアウトの欠点を解消します。」これって全部マーケティングの言葉で、何も言ってないよね。 埋め込み型Wasmデコーダーを通じて、良好な相互運用性と拡張性(いわゆる未来に対応)を維持する。 これって一体何を意味してるの?デコーダーを提供することが未来に対応する保証にはならないよ。

表形式のデータ、Parquetを置き換えたいってこと?

もう少し「理由」が必要だね。Parquetの欠点がこれで克服されるって言ってるけど、具体的にどれ?ツールのサポートが広いわけじゃないし…なんでParquetやORCをやめてこの構造に移行する必要があるの?

「なぜ」はリードミーの最後にある参考文献に書いてあるよ。このリポジトリは単独で使うことを想定してないから、まずは論文を読んでみてね: https://doi.org/10.1145/3749163

うん、これの大半はParquetにもう少し開発時間をかければ解決できそうだね。

論文ではParquet、ORC、Nimble、Lance、TSFile、Bullion、BtrBlocksについて言及されている。

いいね!使うよ。「未来」に。ニンブル?ランス?それも未来に。多分。今はParquetを使うよ。

いいね!世界は常により良いデータフォーマットを必要としてる。READMEにParquetや他のファイルに対する利点を直接書いたら、注目されるかもしれないよ。誰かがhttps://github.com/future-file-format/f3に行ったときに、試すべき理由がわかるように。利点を挙げて、メトリクスも載せて!メトリクスは選りすぐって!これには良いユースケースがあると思うけど、今のREADMEからは誰がこれを使うべきか、なぜ使うべきかが全然わからない。

この部分はかなり天才的だね。特定の言語のSDKやライブラリに依存する代わりに、存在しない場合はエクスポートされたWASMメソッドにフォールバックできるっていう。

「各自己記述型F3ファイルには、データとメタデータ、データをデコードするためのWebAssembly(Wasm)バイナリが含まれています。各ファイルにデコーダーを埋め込むことで、最小限のストレージ(キロバイト)で済み、ネイティブデコーダーが利用できない場合でも、どのプラットフォームでも互換性が確保されます。」

ファイルに実行可能なコードを埋め込むのはセキュリティリスクじゃない?私の予想は「はい」だよ。

攻撃者は特別に破損したファイルを作成する必要がないってこと?攻撃を実行するコードをデータファイル自体に含めるだけでいいの?

wasmはCバインディングよりどういいの?

Hacker Newsで議論の続きを見る