- F3(Future-proof File Format) は、相互運用性・拡張性・効率性を中核の設計原則とする次世代のオープンソース列指向ストレージフォーマットであり、データ処理やコンピューティング環境が変化するたびに新しいフォーマットを作る必要をなくす
- 各 F3 ファイルは 自己記述的(self-describing) な構造を持ち、データとメタデータはもちろん、WebAssembly(Wasm) バイナリデコーダ まで内蔵しているため、ネイティブデコーダがなくてもあらゆるプラットフォームで互換性を保証
- 段階的圧縮やベクトル化デコーディングなどの最新エンコーディング手法を含む 効率的なストレージレイアウト を提供し、Parquet と ORC のレイアウト上の問題点を改善して、I/O・エンコーディング・辞書単位を分離
- プラグインベースのデコーディング API と Wasm 埋め込みメカニズムにより、開発者は新しいエンコーディングスキームを容易に追加でき、ライブラリのバージョンに関係なくすべてのファイルを読み取れるため、Parquet の相互運用性の問題を解決
- 評価の結果、F3 のストレージレイアウト効率と Wasm ベースのデコーディングの利点が実証され、ストレージオーバーヘッドはキロバイト級とごく小さく、Wasm デコーディングの性能低下はネイティブ比で 10〜30% と許容可能な水準
背景と動機
既存の列指向フォーマットの限界
- Parquet と ORC は 2010 年代初頭に Hive、Impala、Spark のようなデータ分析システム向けに開発され、データウェアハウスとデータレイク間でのデータ共有を可能にした
- 10 年が経過した現在、研究ではこれらのフォーマットが現代のデータ分析には不十分であることが示されており、その理由は設計当時の 古いハードウェア性能の前提 と ワークロードのアクセスパターンの前提 に基づいていたため
- この 10 年でストレージとネットワーク性能は数十倍向上した一方で CPU 性能はそれほど伸びておらず、システムは I/O ではなく 計算側でボトルネック が発生
- データレイクの台頭により、より多くのデータが高帯域幅・高遅延のクラウドストレージ（例: Amazon S3）に保存されるようになった
- アプリケーションはもはや少数のカラムを持つ表形式データだけを保存するわけではない。ML ワークロードでは、数千のカラム を持つ幅広いテーブル、高次元ベクトル埋め込み、大容量 blob（画像、動画）などを保存することが一般的
- ランダムアクセスや更新を行いたいという要求も増えているが、既存フォーマットはこうした利用パターンに適していない
- 近年の圧縮・インデックス・フィルタリング手法の進歩がこれらの欠点を解決しようとしているものの、既存のファイルフォーマットは容易に拡張できるよう設計されていない
- 新機能を追加しても、Parquet や ORC ライブラリには多様な言語実装が多すぎて、最新バージョンの利用を期待しにくい
- 古いライブラリを使うシステムは新しいファイル内容をデコードできない可能性があり、そのため多くのシステムは 最小公倍数的な機能だけをサポート して相互運用性の問題を回避している
新しいファイルフォーマットの登場と限界
- これを克服するため、Meta Nimble、Lance、TSFile、Bullion、BtrBlocks など、まったく新しいファイルフォーマットの提案が登場
- しかし、これらも前世代のフォーマットと 同じ過ち を犯している
- 現代のハードウェアおよびワークロードの前提に基づいて設計されている
- 新機能をサポートしつつ既存デプロイメントとの相互運用性を壊さない 容易な拡張性を促進できていない
- このうちの 1 つが Parquet や ORC を置き換える主要フォーマットになったとしても、10 年後にはその欠点を解決するためにまた別のフォーマットを作らなければならないという同じ問題が発生する
F3 のアプローチ
- F3 は 相互運用性・拡張性・効率性 を同時に達成することを目標とする
- F3 の中核は次の 3 つの仕様定義にある:
- ファイル内容の メタデータ
- ファイル内のエンコード済みデータの 物理的グルーピングレイアウト
- データのエンコーディングスキームに依存しない データアクセス API
- F3 のメタデータスキームは、テーブルのカラム部分集合を取得するのに必要なデータを最小化する
- F3 は Parquet の包括的な "row group" 概念をなくし、I/O・エンコーディング・辞書単位を分離 してレイアウトの問題を解決
- 段階的圧縮 と ベクトル化デコーディング のような最新手法を統合
F3 概要
全体構造
- F3 ファイルは メタデータ部分 と データ部分 で構成される
- メタデータ部分: OptionalData(OptData)、Column Metadata(ColMetadata)、Footer、Postscript
- データ部分: Row Groups(RG) で構成され、実データを含む
- F3 は Parquet および ORC と同じ PAX レイアウト を採用
- ただし F3 には既存フォーマットとの間にいくつかの重要な違いがある:
- メタデータが デシリアライズのオーバーヘッドを除去（Parquet/ORC の問題点を解決）
- 物理 I/O Unit(IOUnit) を論理的 row group から分離し、ストレージ媒体に応じて IOUnit サイズを独立して調整可能
- 辞書エンコーディング範囲 を論理的 row group から分離し、各カラムごとに最も効果的な範囲を決定可能
- 各 IOUnit は複数の Encoding Unit(EncUnit) で構成され、EncUnit はエンコーディングおよびデコーディングの最小単位
相互運用性と拡張性のメカニズム
- F3 は 公開 API を提供し、実装がファイル内の圧縮データをどのようにデコードするかを定義する
- エンコーディング方式を プラグイン として扱い、コアライブラリとは別にインストールおよびアップグレード可能
- すべてのライブラリバージョンがすべてのファイルを読めるように、WebAssembly(Wasm) バイナリとして実装したデコーダをファイル内部に埋め込む
- つまり、すべての F3 ファイルにはデータと、そのデータを読むコードの両方が含まれる
- F3 の API はネイティブコード版と Wasm 版で別実装を必要とせず、同じコードを変更なしで 2 つのターゲットにコンパイルできる
- この設計により F3 は将来に備えたものとなり、前述の問題を回避し、既存ソリューションよりも速い進化を可能にする
- 開発者はフリート全体でのライブラリバージョン更新を心配することなく、Wasm コードをファイルに含めることで将来のエンコーディング方式を本番システムへ展開できる
- Wasm バイナリのストレージオーバーヘッドはごく小さく（キロバイト級）、ネイティブ実装と比べた Wasm デコーディングの性能低下も最小限（10〜30%）
結論
- F3 は 相互運用性・拡張性・効率性 を同時に達成する次世代の列指向ファイルフォーマット
- 効率的なファイルレイアウト設計により既存フォーマットの非効率を解消
- プラグインベースのデコーディング API と Wasm 埋め込み により、ライブラリバージョンに関係なくすべてのファイルを読める将来保証のメカニズムを提供
- プロトタイプ評価の結果、レイアウト設計の効率性と Wasm メカニズムの実用性が実証された
- Wasm オーバーヘッドはキロバイト級のストレージ使用量と 10〜30% の性能低下にとどまり、許容可能な範囲
1件のコメント
Hacker Newsの意見
ざっと見た感じ、Parquetの欠点をかなり補っているようで、とても期待できる
ParquetのメタデータはThriftベースなのに、「このフィールドがあればあのフィールドも必須」といった注釈があるだけで実際の検証ロジックがなく、不正なThriftを入れるとリーダーが壊れるだろうと思う
Parquetのメタデータはパースが必要なので、バッファ割り当てやメタデータ解析のための動的割り当てが繰り返され、ヒープ割り当てが多すぎる。今回のフォーマットはFlatbuffers方式を採用しており、Flatbufferバイト列をそのまま解釈できるのでこの問題が解消される
エンコーディングがはるかに強力だと感じる。データベース業界で昔から提唱されてきた軽量で組み合わせ可能なエンコーディングが可能になったようだ。BtrBlocksやFastLanesのような既存フォーマットはParquetより優れていたが、彼らの良いアイデアが継承されていてうれしい
ParquetのDremel record-shreddingは複雑すぎて好きではなかったが、今回はなくなっていてよかった
ParquetではDataPage内のrow数が一定でないため、欲しいrowを見つけるにはColumnChunk全体をスキャンしなければならないが、このフォーマットでは目的のDataPage(IOUnit)へ直接ジャンプできる
重い圧縮は取り除き、Delta/Dictionary/RLEだけを残した。重い圧縮は実質的な利得がなく、実装も面倒で、外部依存も多い
全体として大きな前進だ。このフォーマットがデータ分析業界を席巻してほしい
重い圧縮がzstdやbrotliのことなら、繰り返しの少ない文字列カラムではとても有用だ
wasmコンパイラが入ると、むしろ「heavy」compressionより多くの依存関係が増える可能性がある
Parquetファイルへのカラム追加に関するStackOverflowの議論
最近の圧縮方式はzstdに落ち着いた感じなのだろうか？
Parquetは意外と複雑だ。きちんと効率よく使うには、不便で文書化も不十分な細部を多く把握しなければならず、簡単ではない
Wes McKinney
Wes McKinneyを知らない人のために言うと、彼はPythonで最も広く使われている表形式分析ライブラリPandasの作者だ
彼が作ったフォーマットはリリース初期から市場の信頼を得やすく、また問題に長年愛着を持って取り組んできたため、彼の洞察は特に重要視される
Andy Pavloも言及する価値が大きい
Pandasの影響力についてはファンとして同意するが、技術的にはArrowデータフォーマットのほうがデータエコシステム全体により大きな影響を与えたと思う（例としてDataFusionなど）
Wes McKinneyはApache Arrowの創始者でもある
Parquetに対する彼の仕事が、むしろいっそう信頼感を与えると思う
データとコードを混在させるのは古典的なセキュリティミスだ
物理学者たちの未来には適用されない気がする
今後20年間、CERNのLarge Hadron Colliderで生成されるエクサバイト級データは、CERNが独自開発したフォーマットを使う
CERNデータフォーマット関連資料
CERNはこの分野で、ほとんどの人よりはるかに早くから大規模データを扱ってきた
カラム指向ストレージとの違いをよく理解できていない点についてはご容赦願いたい
なぜこれが革新的なのか気になるのだが、「小さなベクトル埋め込みデータベースをサンドボックス付きで配布できるのが核心なのか？」という疑問がある
論文から新たな基盤になりそうな印象を受け、プロジェクト名にもフランス風のオーラ（？）を感じた
自分は内容の大半を理解できていないが、図や色使いはきれいで大胆だと思った。すぐ説得されるタイプの自分としては親指を2本立てたい
核心は互換レイヤーだ
カラムストレージ方式の本当の利点は、複雑なネストしたスキーマをprimitive値に分解して保存できることだ
カラム指向ストレージの本当の利点は、列全体を一度に非常に高速でスキャンできることにある
select a where b = 'x'のクエリが非常に速くなるwasmデコーダがネイティブ比で10〜30%遅いのはかなり残念だ
つまり最初から10〜30%の性能低下を受け入れるということであり、今後デコーダを改善する機会も永久に放棄することになる
「ブロック全体をデコードしてメモリに格納する」以外の高度なデコーディング機能も使えなくなる
なぜわざわざこう作るのか本当に理解できない
速度が重要ならwasmは答えではないし、速度がそれほどでもないならよく知られたエンコーディングを使えばよいはずだ
WASMはバックアップ用途として提供される
同意できる点もあるが、話はもう少し複雑だ
VortexとF3の関係が正確には理解できない
どちらも「新しいフォーマットを作らなくてもエンコーディング方式を容易に追加できるよう設計する」というビジョンを語っている
紹介文にはVortexのエンコーディング実装を使うとあるが、型システムは異なるとも書かれている
プロジェクトがこう進んだ背景は複雑だ
来年のF4発表にも期待してしまう
ソースコードがどこにあるのかしばらく探したが、ここで公開されている
データを読むには必ずwebassemblyを実行しなければならないという義務が生じるので、依存関係や肥大化を減らしたい環境には向かないと思う
wasmは単純だ
ネイティブデコーダがあるならWASMを使う必要はない
WebAssemblyモジュールを埋め込んだ最初期のファイルフォーマットの一つのようだ
圧縮の観点で特に興味がある。WASMプリプロセッサをうまく設計すれば圧縮率を大きく改善できるという立場だ
私もこのコンセプトでファイルフォーマットを作っている
Alan Kayは、60年代にあるプログラマが作ったとされるテープベースの保存システムを「最初のオブジェクト指向システム」と説明したことがある