Files
llm-wiki/entities/f3-file-format.md
T
2026-06-30 01:24:06 +09:00

33 lines
2.7 KiB
Markdown

---
title: F3 File Format
created: 2026-06-29
updated: 2026-06-29
type: entity
tags: [tool, dev-tool, data-format, reliability, hack]
sources: [raw/articles/f3-file-format-2026.md]
confidence: medium
---
# F3 File Format
F3 は、分析用データを保存するための新しい列指向ファイル形式を試す研究実装。Parquet や ORC のような既存形式が長く使われるなかで、古い配置や拡張しにくさを抱え続ける問題に対し、ファイルの中にデータ、メタデータ、必要なら WebAssembly の復号器まで入れる設計を提案している。
中心にある発想は [[extensible-data-file-formats]]。読み手が符号化方式をすでに知っていればそのまま読める。知らない場合でも、ファイル内の Wasm 復号器を使って読めるようにする。つまり「形式を読むための知識」を、実装や外部仕様だけに置かず、ファイル自身にも持たせる。
## 何が面白いか
- **将来対応の逃げ道**: 新しい圧縮・符号化・配置を試すたびにファイル形式全体を作り直すのではなく、符号化単位ごとに復号器を付ける道を作る。
- **細かい読み出しの設計**: row group、IOUnit/Chunk、EncUnit という階層で、入出力単位と符号化単位を分けて扱う。
- **自己説明性**: Arrow schema、列メタデータ、共有辞書、checksum、Wasm binary、任意メタデータを同じファイルにまとめる。
- **研究としての検証**: `fff-bench` と再現手順があり、Parquet、Vortex、Lance、Nimble、ORC などとの比較を論文側で扱っている。
## 注意点
README は明確に「研究プロトタイプであり本番利用しない」と書いている。実装にも、研究用 API、未整備の再現手順、Debian 12/Intel でのみ試験済みという制約が残っている。現時点では採用候補というより、データ形式の設計案と実験台として読むのがよい。
## Wiki 上の位置づけ
F3 は、[[ghidra-mcp]] が専門道具の操作を MCP の道具層へ寄せたのと少し似ている。どちらも、知識や手順を人間の記憶や prompt だけに置かず、扱う対象の近くに実行可能な形で置こうとする。ただし F3 の対象は逆解析ではなく、長く残るデータファイルそのもの。
また [[llm-wiki-pattern]] が raw source をあとから読める形で残し、合成された知識と出典を分けるのに対し、F3 はデータと読むための手掛かりを同じ保存物に近づける。どちらも「将来の読み手が困らないように、文脈を一緒に残す」設計として見られる。