F3: 下一代开源数据文件格式

F3 是一个下一代开源列式数据文件格式的研究原型，旨在解决 Apache Parquet 和 ORC 等传统格式的僵化问题。其核心创新在于使用嵌入式 WebAssembly (Wasm) 解码器，这使得文件即使在原生解码器不可用或引入新的编码方案时，也能保持自描述性和可读性。

通过嵌入式 Wasm 解码器解决格式僵化问题

F3 通过将解码数据所需的逻辑直接嵌入文件本身，确保了长期的互操作性和可扩展性。虽然传统格式依赖外部 SDK 或库来实现特定的编码方案，但 F3 包含作为备选解码器的 Wasm 二进制文件。

这种方法提供了几个技术优势：

• 前向兼容性： 开发人员可以实现新的编码方案，而无需等待文件格式规范的全局更新或新 SDK 的广泛采用。
• 平台无关性： 由于 Wasm 是一种可移植的二进制指令格式，嵌入的解码器可以在任何具有 Wasm 运行时的平台上运行。
• 极小的开销： 项目文档指出，嵌入这些解码器仅需要几 KB 的额外存储空间。

与传统列式格式的对比

F3 被定位为 Parquet 等“上一代”格式的继任者。该项目旨在纠正这些旧格式中固有的布局缺陷，这些格式是为已经发生演变的硬件和工作负载环境设计的。

通过提供一个用于添加新编码方案的通用 API，F3 旨在消除每次数据处理或计算范式发生转变时都需要创建全新文件格式的需求。该格式的结构使用 FlatBuffers 定义，这为访问序列化数据提供了一种高效的方式。

技术实现与研究状态

F3 目前是一个与 SIGMOD 2026 论文相关的研究原型。它并非旨在用于生产环境。目前的实现是用 Rust 编写的，并包含几个关键组件：

• fff-poc：主要的概念验证代码。
• fff-ude-wasm：通过 Wasm 实现的用户自定义编码 (UDE)。
• fff-bench：用于验证存储布局有效性的基准测试和实验套件。

社区批评与技术权衡

虽然嵌入式解码器的概念被一些人视为解决 SDK 依赖问题的“天才”方案，但其他技术观察者对安全性和长期可行性提出了重大关切：

安全与攻击面

批评者认为，在数据格式中引入一个活跃的执行层（虚拟机）会显著增加攻击面。具体而言，存在以下担忧：

• 远程代码执行 (RCE)： 从文件内部执行 Wasm 二进制文件的能力可能会被恶意利用。
• 资源耗尽： 恶意构造的 Wasm 解码器可能被用于通过资源耗尽发起拒绝服务攻击。

长期归档问题

对于冷存储和长期归档（例如 10 年以上），一些人认为，“简单直接、文档详尽的字节规范”比二进制解码器更可取。依赖 Wasm 解释器引入了对遥远未来 Wasm 运行时持续可用性和性能的依赖。

功能局限性

一些观察者指出，解码器只能解决将比特流转换为数据的转换问题；它无法解决如何使用解码后数据的高层问题。有人提出了关于 F3 是否支持关键性能特性（如高效的 mmap 或在无需执行嵌入式 Wasm blob 的情况下进行部分寻址）的担忧。

"嵌入每个文件中的解码器需要极小的存储空间（KB 级别）并确保在原生解码器不可用的情况下在任何平台上保持兼容性。"

"将解码逻辑放入 WASM 二进制文件中，是在本应是冷存储的内容中引入了一个活跃的执行层。"