使用fst压缩序列化R列表/对象是否存在缺点或风险？

fst包可针对数据框提供多线程压缩及读写能力。
我正在使用brms运行规模大、耗时长的贝叶斯模型，需要将结果保存到磁盘供后续复用。使用saveRDS()配合compress = "xz"参数存储时，输出文件大小约200MB，压缩耗时极长，读取解压也需要花费大量时间。
fst实现了高速多线程zstd压缩，我进行了如下测试：

x <- list(
  a = mtcars,
  b = as.POSIXlt("2021-01-01 14:00:05"))

saveRDS(compress_fst(serialize(x, NULL), compression = 100),
  file = "test_fst.RDS")

x2 <- unserialize(decompress_fst(readRDS("test_fst.RDS")))

all.equal(x, x2)

代码运行返回TRUE，其余快速测试也显示该方案运行正常。
请问我对任意R对象执行序列化、传入compress_fst()处理后写入磁盘的操作，是否存在遗漏的潜在缺点或弊端？

回答 #

这个方案可以大幅提升大体积R对象的压缩读写速度，但确实存在几个容易被忽略的潜在问题：

• 版本兼容风险：该存储链路同时依赖R原生序列化规则和fst包的压缩算法实现，两者任意一方迭代更新都可能导致旧文件无法读取。比如R不同版本的序列化格式存在不兼容情况，fst后续如果修改压缩逻辑，也会出现新旧版本解压失败的问题，跨设备、跨环境共享文件的失败概率远高于标准RDS或fst格式。
• 缺失完整性校验：标准saveRDS内置了文件完整性校验逻辑，文件损坏时会给出明确报错。你手动拼接的「序列化→fst压缩→写入RDS」链路没有统一的校验机制，文件损坏时只会抛出泛化的解压或反序列化错误，难以定位问题原因，也无法提前校验文件可用性。
• 格式非通用：你生成的文件既不是标准RDS格式也不是标准fst格式，只有知晓完整存储链路的人才能正确读取，协作者如果不知道你的处理逻辑，完全无法正常加载文件，也不符合R生态的通用存储规范，长期维护成本很高。
• 特殊对象兼容隐患：你测试用的都是通用基础对象，但brms生成的模型对象包含大量特殊结构，比如Stan模型对应的C++外部指针、会话绑定的环境变量、未计算的惰性求值对象，这类对象即使完成了序列化、压缩、解压、反序列化全流程，也可能出现指针失效、环境绑定丢失的问题，小范围快速测试无法覆盖所有极端情况。
• 小对象性能损耗：如果待存储的序列化结果小于10KB，fst多线程的启动开销会超过压缩带来的收益，读写速度反而低于原生压缩方案。不过针对你200MB级的模型存储场景，这个问题几乎没有影响。

如果你追求高速度的R对象存储，更推荐直接使用qs包，它底层同样采用zstd压缩，专门优化了R全类型对象的序列化存储逻辑，不需要手动拼接处理链路，稳定性和兼容性都优于自定义的处理方案。

内容的提问来源于stack exchange，提问作者Joshua