这套系统是个人量化研究系统单用户日线级别盘后批处理——每天收盘后拉数据、算因子、跑策略、出报告只产出信号和分析报告不做实盘下单。部署在一台 2 核、1GiB 内存的云主机上。存储要装的东西按形态分是五类行情日线 bar、因子bar 的派生特征、财务三大报表和指标、任务与配置运行状态、股票池、分组、元数据与评估结果数据版本、IC 结果。选型最忌讳先定方案再补理由——结论一旦立住理由会自动补齐哪怕在场景里根本不成立。正确顺序是先刻画每类数据的本质特征特征指向什么就用什么。行情追加、不可变、按列扫描行情是最大的一类数据特征最鲜明追加式每天盘后新增一天历史不删除不可变已产生的数据不再修改复权因子偶尔被数据源修正属低频覆盖按列扫描回测与因子计算只消费 open、close、adj_factor 等少数几列其余列不参与计算规模全市场 5695 只股票1992 年至今约 8300 个交易日千万行级前三个特征指向列式、压缩、以文件为单位的不可变存储。parquet列式存储格式恰好是这种形态列存让只读几列只加载那几列行存要整行读入文件不可变让追加一天变成旧文件 新段合并与读操作天然隔离。第四个特征千万行级决定了一件事数据不能整表进内存。机器只有 1GiB 内存消费端全部按批流式处理扫描时只读需要的列——这同样由列式结构支撑。存储容量从来不是问题压缩后单文件数百 MB 级内存才是约束。因子bar 的派生视图因子是 bar 经计算得到的特征序列动量、波动率、量价关系等18 个因子各落一个文件。特征是可重建bar 不变时重跑计算函数得到相同结果缓存带数据版本bar 更新后旧因子自动失效。可重建意味着不需要数据库级别的管理没有事务、没有并发写只有算出来、写文件、按数据版本引用。所以它和行情一样落 parquet每个因子一个文件按列读取。评估结果IC、分层多空落 JSON供界面直接读。财务主键查询 缓存财务和行情是两个极端数据源要求逐股拉取Tushare 财务接口必填股票代码没有全市场批量接口查询形态是主键点查给定股票和报告期取最近 N 期报表需要缓存和增量首次查询拉最近 8 期之后直查缓存全市场刷新按已缓存期数是否足够跳过主键查询 存在则更新upsert 断点续拉这是典型的行存事务场景。SQLite 是最低成本的实现Python 标准库自带零依赖、零独立进程、单文件目前缓存 38MB。任务与配置事务型小数据任务状态进行中/成功/失败、股票池、分组、设置、告警——频繁小写、状态需要事务一致性。调度器、Web 服务、CLI 三个入口同时操作任务表同一时刻只允许一个回测在跑防双跑依赖数据库的锁和事务。它们与财务落在同一个 SQLite 文件里不同表。设计稿曾设想给 SQLite 开 WAL 模式应对读写并发落地时发现不需要单用户、写入量极小、事务短默认模式即可。元数据与评估结果一次写入人读meta.json 记录数据版本、拉取时间、股票池、行数报告头引用它作为可复现锚点ic.json、factor_eval.json 存因子评估结果界面直接读。体量 KB 级、一次写入、主要给人读。JSON 不需要 schema、不需要查询引擎编辑器打开就能看。反向排除特征不匹配的候选正向选型回答特征指向什么反向排除回答特征否定什么。DuckDB 和 PostgreSQL 都进入过候选最终未引入DuckDB解决即席 SQL 查询——用 SQL 直接查 parquet多查询并发毫秒级。我的查询全部是确定性 pipeline拉数→因子→策略→回测→报告没有临时写一句 SQL 探索数据的需求数据已是千万行级但读数据按列流式、按批处理存储不是瓶颈——拉数的瓶颈在数据源限流网络不在存储。查询慢的痛点没有出现。PostgreSQL / MySQL解决多用户并发、在线事务、网络访问。我的场景单用户、批处理写、本地文件即可。引入它们意味着常驻服务进程、账号权限、备份恢复、连接池——在一台 2 核机器上全是纯开销。SQLite 的文件级单写覆盖全部真实需求。设计稿曾给存储设过千万行阈值实际全历史数据已经在千万行级——阈值本身不是判决依据真正触发优化的条件是痛点查询变慢、或单文件读写成为瓶颈。届时再谈 DuckDB 与分区界面要对多用户公开再谈 PostgreSQL。触发条件存在的意义是未来做决定时对照而不是重新争论。落地让选型不翻车的机制选型只是第一步更新与并发才容易出问题增量更新对比已有数据只拉缺失的交易日避免每天全量重拉分片 断点续拉按 60 个交易日切分片每片独立拉取、原子落盘先写临时文件再改名失败重跑只补缺失分片跨进程互斥拉数用文件锁flock保证任意时刻全局只有一个拉取任务调度器、Web、CLI 并发也不超数据源限流备份每次拉数后按日期存一份保留最近 14 份数据损坏可回滚小结选型两步先刻画数据特征特征指向什么用什么再对照排除特征不匹配的不引入。五类数据最终落在三种存储上——parquet、SQLite、JSON——不是这三种技术最好是每类数据的特征恰好指向它们。不选择什么比选择什么更重要因为每个被排除的方案都标记了一个需求边界DuckDB 对应没有查询慢的痛点PostgreSQL 对应没有多用户并发。边界写清楚该换什么、什么时候换都是现成的答案。