F3 - 未来のためのオープンソースデータファイル形式
(github.com/future-file-format)- F3は、効率性、相互運用性、拡張性を念頭に設計されたデータファイル形式
- Parquetのような前世代フォーマットのレイアウト上の限界を是正するデータ編成方式を提供しつつ、内蔵Wasmデコーダーによって相互運用性と拡張性を維持
- 自己記述型のF3ファイルは、データとメタデータだけでなく、データをデコードするWebAssemblyバイナリも一緒に格納する構造
- ファイルにデコーダーを内蔵する方式は、キロバイト単位の最小限の保存領域を必要とし、ネイティブデコーダーがない場合でも、どのプラットフォームでも互換性を保証するための設計
- 開発者が新しいエンコーディング方式を簡単に追加できるよう、データ編成構造と汎用APIを提供するFuture-proof File Formatプロジェクト
- 現在の状態は、論文のアイデアを検証する研究プロトタイプであり、本番環境での利用は禁止
- ビルドはIntelマシンのDebian 12でのみテストされており、PoCパッケージのビルドと単体テストは
cargo build -p fff-poc、cargo test -p fff-pocで実行 - ファイル形式の定義はFlatBufferベースで、主要コード、Wasmデコード実装、論文実験用のベンチマークとスクリプトをあわせて提供
- ライセンスはMIT License
1件のコメント
Hacker Newsのコメント
なぜこれがここまで高く評価されているのかよく分からないし、ランディングページもいまひとつなので、論文を読んだほうがよさそう: https://dl.acm.org/doi/epdf/10.1145/3749163
Parquetの欠点を一部補おうとするカラム指向ストレージ形式のように見えるが、この種の形式で本当に勝負になるのは互換性であり、新しい形式は登場した瞬間からその点で不利だ
Parquetは最初に広く普及したというだけでも非常に強く、論文によれば最もよく使われているParquetのバージョンですら2013年の最古のバージョンで、ParquetでさえParquetを置き換えられていないことになる
F3がこれを超えるにはかなり強い結果が必要に見えるが、そうは見えない
個人的には、Parquetに対する最大の不満である1ファイル1テーブルの問題にも触れていないので、名前もちょっと大げさに感じるし、デコード用のWasmバイナリを入れておきながら、その塊をパースするのにFlatBuffersが必要という点も目的をぼやけさせている
主な成果はランダムアクセスの改善のように見えるが、カラム指向ストレージはもともとランダムアクセスを捨てて高速な分析を得るために生まれたもので、F3はWasmデコーダのせいで高速分析を犠牲にしているように見え、あまり腑に落ちない
Spark、DataFusion、DuckDBは、複数テーブルを含むファイルを渡されても何をすべきかよく分からないだろう
Parquetが多くのことをうまくこなすのは事実だが、先に出たからという理由だけで永遠に唯一の分析用ファイル形式であるべきという意味ではない
高速分析と最近の機械学習系ワークロードは、本質的に一括スキャンとランダムアクセスが混在している
F3の著者の一部は、Parquetの欠点を詳しく扱った論文も書いている: https://www.vldb.org/pvldb/vol17/p148-zeng.pdf
最近出てきたVortex、Lance、F3のような形式は、その論文で整理された問題を解こうとしている
Lanceには興味深いアイデアがあり、VortexはParquetのブラックボックス的なエンコーダを透過的なエンコーディングに置き換え、拡張性と性能に注力している
これにより、大量デコードと要素単位デコードのトレードオフを小さくして、効率的な全件スキャンと非常に高速なランダムアクセスを両立できる
たとえばLangChainは、ParquetファイルベースのシステムをVortexで作り直し、大きな速度向上が得られたと説明している: https://www.langchain.com/blog/introducing-smithdb
参考までに、自分はVortexを開発しているので、「なぜ新しい形式を作るのか」という問いは自分でもずいぶん考えてきた
複数のテーブルが必要ならParquetファイルを複数作ってtarで束ねればいいし、tarとParquetのライブラリがあるどの言語でも読みやすく、美しいほど単純だ
.parquetzという形式を想像したことがある非圧縮のParquetファイルを複数入れたzipファイルなら、単一ファイルで複数テーブルを持ち運べるし、レンジリクエストでのアクセスも可能だろう
言語ごとのSDKやライブラリに依存せず、なければ内蔵のWasmメソッドにフォールバックできるという点はかなり巧妙だ
「各自己記述型F3ファイルは、データとメタデータだけでなく、データをデコードするWebAssembly（Wasm）バイナリも含む。各ファイルにデコーダを内蔵するために必要な保存領域は小さく（キロバイト単位）、ネイティブデコーダがない場合でもすべてのプラットフォームで互換性を保証する」
PDF向けの内蔵デコーダはどんな見た目になるのだろう?
ファイルのバイト列と強く結び付いているので、ファイル作成者はどの形式が妥当かを選べるのかもしれないが、すべての形式に固有の「正しいデコード手順」があるわけではない
デコーダは何にデコードするのか?
データの種類に完全に依存するはずで、ある形式はバイトストリームだし、ある形式は2次元ピクセル平面で、また別の形式では頂点、2次元ピクセル平面、UVマップが必要で、場合によってはオブジェクトグラフのほうが自然だ
みんなが何を見て話しているのか分からない
READMEには、これが何なのか、どんな問題を解くのかについての情報がほとんどなく、FlatBuffersの説明とソースコードディレクトリへのリンクしか見当たらない
何か文脈を見落としているのだろうか?
もう少し「なぜ」が必要に見える
Parquetの欠点を克服すると言うが、どんな欠点なのか気になる
幅広いツール対応が理由なのは確かに違うだろう
なぜParquetやORCを離れてこの構造を使うべきなのか？
論文から先に見るのがよさそう: https://doi.org/10.1145/3749163
この記事は興味深かった: https://medium.com/@reliabledataengineering/f3-the-future-pr...
天才的だと言う人もいたが、面倒なHN懐疑論者の役をやるなら、やや愚かにも見える
データ圧縮形式は、デコード後にそのデータで何をするかに比べれば副次的なものだ
音声ファイルとSVG画像はまったく別物であり、動画を生ピクセルに戻す組み込みVMがあったとしても、テキストエディタでその動画を再生できるようになるわけではないので、根本的に新しい相互運用性が生まれるわけではない
新しい形式ごとに、結局は形式別の処理が必要になる
たとえばH.265より優れた動画圧縮方式を作っても、すべてのプラットフォームが対応していないなら、デコーダを内蔵して古いハードウェアで再生させる用途はありうる
しかし、それもやはり弱点を露呈する。古いハードウェアが将来の動画形式をソフトウェアデコードでうまく処理できる可能性は低く、このアイデアが1990年代に出ていたとしても、i386でNetflixを見られるようにはならなかっただろう
同様に、Word 2021のファイルをWord 97で開けるようにできたかも疑わしいし、データ構造の間に1:1対応はない
こうした互換性が明確な勝利でないなら、目標が何なのか分からない
欠点は明らかだ。デコーダに修正すべきバグが見つかったら、すでにそのデコーダを内蔵したすべてのファイルをどうやってパッチするのか？
さらにサイズのオーバーヘッドとセキュリティリスクもあり、あらゆる形式パーサに かなり大きな攻撃面 を追加することになり、リモートコード実行やリソース枯渇攻撃などの機会が増える
常に間違ったアプローチというわけではないが、利益が何なのかが重要だ
カラム指向ストレージ形式 を調べれば、長所と短所は最近かなりよく整理されている
もちろん動画デコード用ではない
一部の現代的な形式の利点は、ツールが非常に高い体感速度で読み取れることだ
たとえばDuckDBは、自前のネイティブ形式やParquetを読むときに、ありとあらゆる最適化を適用できる
しかし、形式を理解するためにWasmの塊を実行しなければならない形式にも、そうした最適化を効果的に適用できるのかはよく分からない
SIMDであれSIMD最適化済みであれ、データを一度走査するあいだにそのパスがクエリを理解していなければ、その時点で損をしているかもしれない
論文の冒頭しか流し読みしていないので、実際の形式は聞こえるほど汎用的ではないのかもしれない
自己展開EXEの代替になる姿はある程度想像できるが、特定のファイル形式を選ぶ理由の多くは、その形式が提供する具体的な機能にある
自己記述型システムも、他の形式と同じく「競合する機能が多すぎて誰も全部は処理できない」状態に陥りうる
たとえばこのファイルは効率よく
mmapできるのか？内部的にtarを真似していれば可能かもしれないが、実行してみるまで分からない
特定のバイト位置へシークして一部だけ展開できるのか？
ISO-36898533ブラウジングのプレリリース版しか対応しておらず、使っているファイルライブラリは6年前にその対応を削除しているかもしれない
真ん中の1MBを書き換えるとき、ディスク上のそのページだけを更新すればよいのか、それとも全体を書き直す必要があるのか？
Wasmの塊がそのためのAPIを97個サポートしていて、そのうち35個は名前だけ違う複製で、データ本体より大きくなっていても誰も気にしていないかもしれない
結局、認識可能な選択肢は19個しかないのに、CPUのネイティブWasm高速化は2つか3つしか扱えず、依然としてコードを強く特化させる必要があるかもしれない
少なくとも
*.tar.gzなら何ができるかはある程度見当がつく良いことだ。世の中には常により良いデータ形式が必要だ
ただ、READMEにParquetや他のファイル形式に対する利点をすぐ書いたほうが、もっと関心を集められると思う
誰かが https://github.com/future-file-format/f3 に入ったとき、なぜ試すべきかが分かるようにすべきだ
利点と指標を載せ、指標は都合のよいものだけ選んでもよい
良いユースケースがある可能性はあるが、現状のREADMEだけでは、誰がなぜ使うべきかが明確ではない
PB級のデータを10年以上保管するなら、ファイルを読むために将来も Wasmインタプリタ が存在し、しかも十分高速であることに依存したくはない
Parquetのように単純で、よく文書化されたバイト仕様が欲しい
しかも、デコードロジックをWasmバイナリの中に入れるのは、本来コールドストレージであるべき場所に能動的な実行レイヤーを追加することだ
サンドボックス化されて広く受け入れられており、Wasmにも同じサンドボックス能力がある
長期保管にはむしろその方が良いと見ることもできる
展開プログラムを別に持ち歩く必要がなく、アーカイブファイル自体に入っているからだ
デコードに失敗したら、誰かが入れた Wasm をデバッグしなければならず、そこに任意のバグが含まれている可能性があるのが心配
プロジェクトが管理・テストする標準デコーダライブラリがあれば役に立つかもしれないが、そうするとこの方式が提供する 柔軟性 の利点を損なうのかどうかはよく分からない
つまりこちらのシステムが新たに生んだ問題ではなく、どのクライアントとも独立に相手側で再現できるはず