F3 最反常的地方，不是又做了一个数据文件格式。

它想让文件自己带上“怎么读我”的能力。数据、元数据、Wasm 解码二进制放在一起。平台没有原生解码器，也可以通过文件内置的 Wasm 去解码。

这件事现在不能被理解成“Parquet 替代品已经来了”。F3 目前只是 SIGMOD 2026 论文相关的研究原型，GitHub README 明确写着不要用于生产。更准确的说法是：它把数据格式十多年没还完的一笔老债，换了一种还法。

F3 到底解决哪笔债

F3 盯的是列式文件格式。

它的参照物很清楚：Parquet、ORC。这些格式是数据湖、分析数据库、查询引擎、ETL 管线里的公共语言。公共语言的好处是人人能读，坏处是很难改。

问题Parquet / ORC 的现实处境F3 的尝试
格式定位十多年前形成的开源列式格式，生态极深面向未来的数据文件格式研究原型
主要目标稳定、通用、跨系统交换效率、互操作性、可扩展性
升级难点新编码、新布局要等引擎和平台适配把 Wasm 解码器随文件携带
当前状态生产环境事实标准之一论文相关原型，不建议生产使用
影响对象数据湖、分析数据库、查询引擎、存储格式维护者同一批人，但现在更像观察对象，不是迁移对象

Parquet 和 ORC 不是失败者。恰恰相反，它们太成功了。

成也萧何，败也萧何。一个格式一旦变成基础设施的共同语言，任何改动都会被生态放大。查询引擎要支持，湖仓组件要支持，治理工具要支持，云平台也要支持。规格可以往前走，部署不一定跟得上。

这就是 F3 想切开的地方。

硬件变了。CPU、缓存、向量化执行、云对象存储、AI 数据管线都变了。负载也变了。文件格式当然可以继续加扩展，但只要解码能力还卡在各个平台的原生支持里，升级就会慢。

F3 的判断很直接：别只让文件描述数据，也让文件带上读取数据的那段能力。

对工程团队来说，现在不是迁移，是设观察点

受影响最大的人，不是普通用户。是两类团队。

一类是数据基础设施工程师。你们现在不该把 F3 当新生产格式评估，更不该规划迁移。合理动作是读设计、跑隔离实验、看它对查询引擎接口有什么要求。尤其要看 Wasm 解码的资源限制、错误处理、沙箱边界和审计路径。

另一类是关注数据库和数据湖格式演进的人。F3 提醒你们，下一代格式竞争不只拼存储布局，也会拼“扩展能力怎么分发”。谁能让新编码少等几年适配，谁就可能改变格式演进的节奏。

但别急着兴奋。

文件携带 Wasm 解码器，听起来像把兼容性问题打包解决了。实际落地时，它会马上变成一串工程问题：

  • 查询引擎是否允许执行文件内嵌代码；
  • Wasm 运行时由谁维护；
  • 解码器耗 CPU、内存、I/O 时怎么限额；
  • 文件来源不可信时如何审计；
  • 十年后的旧 Wasm 解码器谁来兜底。

这些都不是论文里一句“可扩展”能盖过去的。

数据平台最怕的不是一个格式读不快。真正麻烦的是边界没人认领。文件如果只是数据，责任在解析器和格式规范。文件如果带执行能力，责任链就长了：格式作者、文件生产方、平台运行时、安全团队、数据治理团队，一个都跑不掉。

这也是 F3 最有价值、也最危险的地方。

它把兼容性从生态适配里拿出来，压回文件自身。短期看很聪明。长期看，等于让数据文件带着一小段可执行基础设施到处走。

Wasm 是解法，也是治理题

我不太买账的是那种轻飘飘的乐观：只要文件自带解码器，格式升级就顺了。

不可能这么便宜。

F3 的方向确实抓住了痛点。上一代格式的技术债，核心不是没人会设计更好的布局，而是新设计很难被全生态同时采用。数据基础设施里，最慢的常常不是算法，是升级链条。

铁路时代也有类似问题。轨距统一后，运输效率上来了；统一之前，每条线路都有自己的成本账。这个类比不完全一样，但利益结构很像：大家都说标准重要，真到执行层，谁出钱、谁背锅、谁维护，才是硬问题。

F3 试图绕开这条慢链路。

它不等所有平台先内置解码器，而是把解码器跟文件绑在一起。这样，新编码、新布局、新实验性优化，理论上可以更快被读取。格式不再只是静态规范，而是带了一个受控执行入口。

这一步很大胆。

可一旦文件格式变成执行入口，观察重点就要换。不能只问压缩率、扫描速度、编码效率。还要问这些更现实的问题：

观察点为什么关键
论文实验数据目前不能编造性能收益，必须看真实负载下的对比
Wasm 沙箱模型文件内嵌执行逻辑能否被安全隔离，是落地前提
与现有引擎集成路径查询引擎、数据湖组件是否愿意接入运行时，决定生态成本
解码器治理版本、签名、审计、长期维护决定十年后会不会再欠新债
失败处理解码器异常、超时、资源耗尽时，平台怎么兜底

这些问题看不清，F3 就只能停在漂亮原型。

但它问对了问题。

Parquet 的位置不是一篇论文能撼动的。它后面是工具链、云厂商、数据库、湖仓系统、BI、ETL 和治理平台。任何新格式想挑战它，都不是跑赢几组实验就够了。

F3 真正值得看的是那条路线：未来的数据格式不能只问怎么存得更好，还要问十年后怎么升级，怎么兼容，怎么少拖全生态下水。

如果 Wasm 内嵌解码器被证明安全、可审计、可维护，它可能缩短格式创新进入系统的距离。如果这些治理问题没人愿意承担，它也可能只是把旧债换了个账户。

回到开头那个反常点：文件自己带着“怎么读我”的能力。

这很聪明。但基础设施里，聪明从来不是免费午餐。真正的分水岭不是 F3 能不能立刻取代 Parquet，而是谁愿意为这种可执行文件格式建立边界、规则和长期维护账本。