2.7 KiB
2.7 KiB
title, created, updated, type, tags, sources, confidence
| title | created | updated | type | tags | sources | confidence | ||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| F3 File Format | 2026-06-29 | 2026-06-29 | entity |
|
|
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 はデータと読むための手掛かりを同じ保存物に近づける。どちらも「将来の読み手が困らないように、文脈を一緒に残す」設計として見られる。