量化历史数据放进 COS 后，生命周期规则别只看“省空间”

做量化久了，行情快照、因子文件和回测结果会越积越多。最省事的办法似乎是全部丢进一个 COS 存储桶，再配一条生命周期规则自动转冷。但真到需要复盘旧策略时才会发现，存储类型选错了，省下来的容量费可能抵不过取回时间和操作成本。

我更愿意先按“多久会再读”给数据分层。最近几个交易日仍会反复计算的行情和因子放标准存储；月度或季度才会访问、但要求拿来就用的数据，可以考虑低频存储；多年以前的原始快照，如果只是审计或少数复盘才用，再考虑归档。腾讯云官方文档把标准、低频、归档和深度归档区分为不同访问频度、取回费用与访问时延的类型，并不是越冷越划算。

量化数据还有一个特点：小文件很多。按股票、日期分别保存 CSV 时，单个文件可能很小，而低频和归档类型存在最小存储单元与最短存储时间要求。官方规格说明中，部分冷存储对象不足 64KB 仍按 64KB 计量。与其直接沉降几万份碎文件，不如先按交易日或月份合并为 Parquet，再设计生命周期规则，查询和成本都更可控。

生命周期的范围也要用对象前缀隔开。例如 raw/daily 保存原始行情，factor/latest 保存近期因子，backtest/archive 保存旧回测。规则只匹配明确前缀，不要整桶一刀切。官方文档说明，生命周期可按最后修改时间或最后访问时间执行存储类型转换和过期删除；如果选择最后访问时间，需要先开启访问跟踪。

归档前还要问清楚恢复要求。归档对象下载前需要先恢复，深度归档的标准取回通常需要 12 到 24 小时，批量取回更久。临时想重跑十年全市场数据时，这种等待可能直接打乱研究安排。我会保留一份近期可直接读取的数据集，并给旧数据准备“恢复—校验—回测”的流程，而不是让研究脚本直接依赖归档对象。

生命周期规则上线后，最好先用测试前缀放几批样本，确认沉降时间、版本对象和费用变化，再扩大范围。