Parquetが10年支配した後、WASMはそれを揺るがせるか？
あなたは8年間蓄積されたParquetテーブルを持っている。データ量は大きくもなく小さくもなく、300GB強。ある日、新たな要件が降ってくる：このテーブルに対してポイントクエリを実行せよ——フルスキャンではなく、主キーで数十行を拾うだけだ。試してみると、Parquetでも不可能ではないが、毎回row groupのcolumn chunkからターゲットページを探し出さねばならず、ページ粒度は往々にして数十万行、I/Oオーバーヘッドが要件とまったく釣り合わないことがわかる。
あなたは思う：列指向ストレージフォーマットは十数年も開発されてきたのに、なぜまともなランダムアクセスすらできないのか？
これこそがCMUデータベースグループがSIGMODで発表したF3（Future File Format）の出発点だ。そしてまさにこの出発点が、フォーマット戦争において最も敏感な琴線を踏んだ。
新しいフォーマット、古くからの問題
F3が解決しようとする問題を一言でまとめれば：既存の列指向ストレージフォーマット（Parquet、ORC）はHadoop時代に生まれ、そのストレージレイアウトと進化メカニズムは現在のハードウェアとワークロードに適合しなくなっている。 Parquetのrow group粒度は粗く、メタデータ階層はフラットで、列エンコーディングは仕様に固定されている——新しいエンコーディングを導入するには、すべてのreader実装が更新されるのを待たなければならない。そしてF3論文が引用する一連のデータは非常に示唆的だ：現在最も広く使われているParquetバージョンは、いまだに2013年のv1である。
Parquet自身ですらParquet自身を置き換えられていない。
F3のソリューションは二方面からの同時攻撃だ。レイアウト面では、より精細な階層構造を導入する：IOUnit（I/O基本単位）→ EncUnit（エンコーディング基本単位、デフォルト64K行）→ オプションのサブEncUnitベクトル。この階層により、readerは読み取り時にきめ細かなプロジェクションが可能になる——ある列のうち特定の数千行だけを取りたい？EncUnitインデックスを走査し、無関係なブロックをスキップすればよい。
拡張性の面では、F3の中核的創造はデコーダをWASMバイナリ形式でファイル自身に埋め込むことだ。各EncUnitにはWASM IDをマークでき、ファイル末尾に格納されたデコーダを指す。readerがローカルでそのエンコーディングを認識できなければ、WASMモジュールを直接ロードしてデコードする——readerのバージョンアップも、コミュニティの合意形成も不要だ。論文によればWASMデコーダのサイズはKBレベルで、「無視できるストレージコスト（negligible storage cost）」とされる。
これがF3の二枚のカードだ：より精細なランダムアクセスと、WASMによる互換性デッドロックの迂回。
データの背後にあるもの
F3のベンチマークはParquet、ORC、Vortex、Lance、Nimbleと比較している。論文の実験からいくつかの傾向が読み取れる：
- ランダムアクセス：F3のポイントクエリレイテンシはParquetを有意に下回る。特に少数の列と少数の行のみが必要なシナリオで顕著だ。これは魔法ではない——EncUnit階層が本質的により小さなI/O粒度をサポートするからだ。
- 圧縮率と解凍速度：概ねParquetと同水準。F3はデフォルトで64K行ごとのEncUnitにCascadeエンコーディング（Vortexのデフォルトエンコーディングに類似）を使用し、Zstd/LZ4圧縮と組み合わせる。勝ってもいないが、負けてもいない。
- WASMデコードオーバーヘッド：WASMデコーダを使用するとネイティブデコードより一段遅いが、論文はその差が許容範囲内であることを力説する。ここで必要なエンジニアリング判断は：WASMデコーダの存在意義は「ファイルが読めること」を保証することだ。 それはフォールバックであり、アクセラレータではない。
総合的に見れば、F3はベンチマーク上で「ある次元では向上があり、全体としてParquetに劣らない」という姿勢を示している。SIGMOD論文としては、この結果は合格だ。フォーマット置き換え戦争としては、この結果はまだ足りない。
互換性：真の堀
HN議論欄で最高票のコメントはvouwfietsmanによるもので、残酷だが反論しがたい一言を放った：
Parquet is unfortunately very good just by virtue of being first, and so widely supported.
Parquetのエコシステム的地位がどれほど強固か？いくつかの事実を列挙すれば明らかだ：Spark、DuckDB、Pandas、Polars、Snowflake、BigQuery、Redshift Spectrum、AWS Athena、Trino、Presto、ClickHouse（外部テーブル）……名前の挙がるほぼすべてのデータツールがParquetをネイティブサポートしている。その仕様はオープンだが、20以上の主要実装による繰り返しの磨合を経て、事実上の標準となった。あなたが生成したParquetファイルはあらゆるツールで読み取れる——それはコミュニティの10年にわたるバグ修正と相互運用性適応の積み重ねだ。
ここから一つのパラドックスが導かれる：F3はWASMを用いて「新しいエンコーディングを古いreaderが認識できない」という互換性問題を解決しようとするが、新しいフォーマットを本当に阻んでいるのはエコシステムへの参加コストだ。
ある企業がF3に切り替えるには、何が必要か？
- すべての下流クエリエンジンにF3 readerを追加する（WASMフォールバックはEncUnitをデコードできるだけで、完全なreader実装を代替できない——ファイルヘッダ解析、メタデータ走査、述語プッシュダウン、プロジェクション刈り込み、これらすべてにネイティブコードが必要だ）。
- すべてのデータパイプライン（ETL/ELT）がF3 writerをサポートする。
- すべてのデータガバナンスツール（カタログ、スキーマレジストリ、リネージ追跡）がF3メタデータを解析できる。
- データ共有の外部パートナーがF3を読める。
これは一つのWASMデコーダで解決できる問題ではない。Parquetの堀は10年蓄積されたエコシステムの織物だ。
WASMソリューションの緊張
F3のWASM設計はHN上で激しいサブ議論を引き起こし、焦点は三つの層に集中した。
第一層はセキュリティ。 ファイルに実行可能コードを埋め込むことは、WASMサンドボックスがいかに成熟していようと、技術者のセキュリティ神経を自然に刺激する。PDF内のJavaScriptとの類推をする者もいる——標準はその能力を設計したが、まともなビューアはすべてデフォルトでそれを無効にする。F3支持者は反論する：WASMデコーダは純粋関数にすぎず、I/O能力はなく、サンドボックスが命令数とメモリ上限を制限できる。しかしデータエンジニアリングのワークフローはしばしば信頼できないソースからのデータファイルを扱い、任意のWASM実行を許可することは多くのセキュリティチームが受け入れない選択肢であり続けるだろう。
第二層はパフォーマンスポジショニング。 vouwfietsmanは痛烈に指摘する：列指向ストレージフォーマットのコアバリューはシーケンシャルスキャンで分析性能を引き換えにすることであり、ランダムアクセスを犠牲にすることだ。F3はランダムアクセスの改善を主要なセールスポイントとしているが、ランダムアクセス自体は列指向ストレージの設計目標ではない。ランダムアクセスを最適化してフルテーブルスキャンが遅くなったなら（たとえWASMデコードパスだけであっても）、それはコアの優位性を副次的な能力と交換していることになる。
第三層は技術選定の自己整合性。 F3のメタデータ層はGoogleのFlatBuffersを使ってスキーマとファイルレイアウト情報をシリアライズしている。WASMデコーダはホスト言語とWASMメモリの間でデータを行き来させる必要があり、FlatBuffers解析自体にも一定のオーバーヘッドがかかる。あるコメント投稿者は、WASMランタイム＋FlatBuffersシリアライズ／デシリアライズの組み合わせは、読み取りパスに二層の抽象化オーバーヘッドを追加することになり——これは列指向ストレージが可能な限り削減したい部分そのものだと指摘する。
これらの疑問はF3の設計が間違っていることを意味しない。しかしそれらは核心的命題を指している：F3が解決しようとしているのは、フォーマット進化における副次的矛盾であって、主要矛盾ではない。 主要矛盾は「どうすれば全員に切り替えたいと思わせられるか」であり、「新しいエンコーディングをどう実装するか」ではない。
歴史のこだま
HNのコメントではxkcd #927（「Standards」）を貼る者、OpenDocの運命——技術的にはより先進的だが最終的にネットワーク効果に敗れたファイルフォーマット——を持ち出す者がいた。それほど悲観的になる必要はないと考える者もいる：もしF3が特定のニッチシナリオでParquetが提供できない価値を提供するなら（例えば頻繁なランダムアクセスが必要なオンライン特徴ストアや、カスタムエンコーディングが必要な垂直領域）、市場全体を勝ち取る必要はなく、自分のエコシステム的地位を固めればよい。
筆者はこの二つの判断が相互排他的ではないと考える傾向にある。フォーマット置き換えの歴史は確かに一面において「互換性優先」論を支持しているが、歴史に「デコーダをファイルに埋め込む」設計は登場したことがない。WASMの出現はクロスプラットフォーム実行可能コードのコスト構造を変えた——10年前、ファイルにサンドボックス化実行環境を埋め込むことは想像不可能だったが、今日ではそれは単に一行のwasmtime::Module::new()だ。
F3はParquetを置き換えないかもしれない。しかしF3が提案したWASMデコーダパラダイムは、Parquetまたは他のフォーマットに吸収される可能性がある。最良の結末は置き換えではなく、汚染だ——古いフォーマットにあなたの良い設計を学び取らせ、あなた自身は次の無人地帯へと奔赴する。
現在のトレンドから見ると
F3は現在もなお研究プロトタイプである——READMEの冒頭で「本番環境で使用すべきではない」と宣言し、GitHub上のコミットはわずか4回、ベンチマーク再現スクリプトもまだ完全ではない。「エンジニアリングチームが代替案として真剣に評価できる」段階までは、まだ長いエンジニアリング化の距離がある。
業界トレンドから見れば、Parquetの地位は短期的にはほぼ揺るがない。Iceberg、Delta Lake、Hudiといったオープンテーブルフォーマットの台頭は、Parquetをレイクハウスアーキテクチャの基層にさらに固定した——テーブルフォーマットの戦いは上層へと移行し、ファイルフォーマットはむしろより深く「ロックイン」されてしまった。Icebergを切り替えながら、同時に基層のファイルフォーマットも切り替えることはまずない。それは二倍の移行コストだ。
しかしF3が提起した問題には価値がある。Parquetの進化のボトルネックはリアルだ——10年間動かなかったv1がいまだに世界を支配している。これは正常な状態ではない。WASMデコーダという発想は、たとえ最終的にF3を成就させなくとも、他のフォーマットのあるバージョンのspecを成就させるかもしれない。
言い換えれば：これはParquetの葬儀ではない。しかし次世代列指向ストレージフォーマットの最初の胎動かもしれない。
参考：F3 SIGMOD論文 · GitHubリポジトリ · HN議論