F3

F3 是什么（根据讨论推断）

• 一种列式数据存储格式，旨在作为 Parquet/ORC/Nimble/Lance 的替代方案，而不是通用文件格式。
• 面向分析 / “大数据” 工作负载，重点关注随机访问和可扩展性。
• 在每个文件中嵌入 WebAssembly（Wasm）解码器，作为一种自描述、向前兼容的机制。
• 解码器似乎输出 Arrow 风格的缓冲区；格式元数据本身通过 FlatBuffers 定义。

对文档与“为什么这样设计”的批评

• 许多读者认为 GitHub README 含糊且偏营销：不清楚这个格式做什么、解决什么问题、或者适合用在哪里。
• 核心动机主要在链接的研究论文里；单看仓库很难理解。
• 有人要求在 README 中直接概述相较于 Parquet 的优势（带上指标）。

相对于 Parquet 和其他格式的动机

• 对 Parquet 的常见批评包括：不考虑硬件特性设计、全局/笨拙的元数据、在保持兼容性的同时很难加入新的编码，以及随机访问能力较弱。
• 有些人认为，这些问题可以通过对 Parquet 或 Vortex、Lance 等替代格式投入更多工程工作来解决。
• 另一些人认为，对于混合批处理 + 随机访问和 ML 工作负载，新格式仍然有价值，不过 Parquet 广泛的兼容性仍然是一个很大的护城河。

嵌入式 Wasm 解码器：优缺点

• 支持者：
  • 解决了新编码的向前兼容问题，而不需要更新每一个读取器。
  • 与平台无关、处于沙箱中的虚拟机；解码器可以是返回缓冲区的纯函数。
  • 类似想法早已存在（RAR VM、字体、Anyblox）；Wasm 运行时可以限制内存和指令数量。
• 怀疑者：
  • 在数据文件中嵌入可执行代码会增加攻击面（RCE、DoS、压缩炸弹）。
  • 即使有沙箱，Wasm 引擎或宿主接口中的漏洞也很可能出现。
  • 这使得摄入不受信任数据变得危险，除非禁用 Wasm，而这又削弱了一个关键卖点。
  • 调试第三方 Wasm 解码器可能很痛苦。

性能、采用与长期生存

• 有人担心基于 Wasm 的解码可能更慢，并会干扰引擎级优化（例如 DuckDB 风格的向量化）。
• 也有人质疑：一个近期提交很少、没有生态支持的研究项目，是否能取代 Parquet。
• 有些人认为 F3 可能更适合归档；但也有人认为，简单、类文本的格式（CSV/JSON）或 Parquet 本身更具未来适应性。
• 总体情绪：这是一个有趣、巧妙的想法，但在实际应用、安全性和采用方面都面临严重障碍。