A 股数据本地存储方案对比：JSON、SQLite、ClickHouse、DuckDB 怎么选
把 A 股全市场 5000 只股票的历史行情、财务数据、逐笔交易、五档盘口搬回本地之后，第一个绕不开的问题就是：用什么格式存储？本篇从实际工程实践出发，把 JSON、SQLite、ClickHouse、DuckDB 四种方案在 A 股量化场景下的表现做一次系统对比，给有同样困惑的量化研究员一份选型参考。
一、本地存储在 A 股量化中的真实价值
云端 API 在过去十年是 A 股数据获取的主流方式，但随着量化策略对数据颗粒度和回测速度的要求越来越高，本地存储的优势开始显现。本地数据引擎的核心价值不在于"省钱"，而在于三点：
第一，数据可复现。云端 API 的接口参数、字段定义、限流策略随时可能调整，导致同一套回测代码在不同时刻跑出不同结果。本地存储的数据是"快照"，任何时刻回测都是同一份数据。
第二，回测速度。5000 只股票 5 年的逐笔交易数据如果每次回测都从云端拉，耗时是小时级；如果从本地拉，单次回测可以压缩到分钟级甚至秒级。
第三，数据安全。本地存储意味着数据完全归属于用户，不受任何第三方平台政策影响。这对长期量化研究至关重要。
但本地存储并不是免费的。第一个要解决的问题就是选型：用什么格式存？用什么引擎查？这是本篇要回答的核心问题。
二、四种主流方案对比
下面这张表从数据规模适应性、查询性能、写入速度、运维复杂度、生态成熟度、适用场景六个维度做对比。
| 维度 | JSON 文件 | SQLite | ClickHouse | DuckDB |
|---|---|---|---|---|
| 数据规模适应性 | GB 级 | GB 级 | TB 级 | GB-TB 级 |
| 查询性能 | 极差 | 中等 | 极强 | 强 |
| 写入速度 | 快 | 中等 | 极快 | 快 |
| 运维复杂度 | 无 | 极低 | 高 | 低 |
| 生态成熟度 | 通用 | 通用 | 大数据成熟 | 新兴 |
| 适用场景 | 配置文件 | 个人量化 | 团队/机构 | 个人量化 |
| 学习成本 | 极低 | 低 | 中等 | 低 |
JSON 文件适合存配置文件、临时数据、少量样本，但不适合做大规模回测的存储引擎。SQLite 是单文件数据库，零运维，5GB 内查询性能良好，是个人量化的入门选择。ClickHouse 是列式数据库的代表，擅长大规模聚合查询，是机构级量化平台的主流选择，但运维成本高，单机部署需要 16GB 以上内存。DuckDB 是嵌入式列式分析引擎，介于 SQLite 和 ClickHouse 之间，单文件部署，零运维，5GB-50GB 数据规模下查询性能接近 ClickHouse，是 2023 年以来个人量化领域的新宠。
三、按数据规模选型
3.1 数据规模 1GB 以内
如果你的策略只需要 200 只股票 1 年的 K 线数据，数据规模在 1GB 以内，JSON 文件或者 SQLite 就够用。JSON 文件的优势是读写简单、所见即所得，可以用任何编辑器打开；SQLite 的优势是支持 SQL 查询，过滤和聚合方便。这一阶段选哪个都不会有显著性能差异，关键是不要选错导致后期迁移成本太高。
3.2 数据规模 1GB-50GB
这是个人量化最常见的规模。5000 只股票 5 年的 K 线 + 财务数据大约 8GB，加上逐笔交易、五档盘口、龙虎榜、北向资金数据，总规模在 30-50GB。这个规模下，SQLite 的查询性能开始下降，聚合查询尤其是时间窗口类的查询可能需要几十秒；ClickHouse 在这个规模下显得"杀鸡用牛刀"，但性能确实一流；DuckDB 是最佳选择，单文件部署，零运维，聚合查询耗时通常在秒级。
3.3 数据规模 50GB 以上
如果你的数据覆盖到 10 年以上、5000 只股票全字段（含 L2 行情、逐笔交易、五档盘口），总规模会超过 100GB。这个规模下，DuckDB 仍然可以支撑，但单机内存需要 32GB 以上；ClickHouse 是更专业的选择，集群部署可以支撑 PB 级数据，但运维成本显著上升。这个规模通常是机构级量化平台的场景。
四、按查询模式选型
不同策略对查询模式的要求不一样，选型时不能只看数据规模。
4.1 时间窗口类查询
比如"过去 60 个交易日内某只股票的收盘价序列"，这是最常见的回测查询。SQLite 在这个查询上耗时通常在 100 毫秒-1 秒之间；ClickHouse 在 50 毫秒以内；DuckDB 在 50-200 毫秒之间。这个查询模式下三者差距不大，选 SQLite 还是 DuckDB 取决于你对运维成本的偏好。
4.2 聚合类查询
比如"全市场 5000 只股票过去 20 日累计涨幅前 100 名"，这是选股类策略的核心查询。SQLite 在这个查询上需要全表扫描，耗时 5-30 秒；ClickHouse 是 200 毫秒以内；DuckDB 是 1-3 秒。聚合查询是 ClickHouse 和 DuckDB 的强项，SQLite 在这个场景下性能明显落后。
4.3 时间序列分析查询
比如"统计某只股票过去 5 年所有 5 分钟 K 线形成的支撑位和压力位分布"，这类查询涉及时间窗口聚合、排序、分组等复杂操作。ClickHouse 在时间序列分析上的性能优势最明显，专用的时间序列优化让它的查询速度通常比 DuckDB 快 3-5 倍。如果你的策略大量依赖时间序列分析，ClickHouse 是更专业的选择。
4.4 跨表关联查询
比如"主力资金连续 3 日净流入 + 北向资金加仓 + 五档盘口买盘扩大三个条件同时满足的股票"，这类查询涉及多表 JOIN。SQLite 在多表 JOIN 上的性能衰减明显；ClickHouse 对 JOIN 的支持相对较弱，建议预先做宽表处理；DuckDB 在多表 JOIN 上的性能接近 ClickHouse，是这类查询的最佳选择。
五、按使用场景选型
5.1 个人量化新手
如果你刚开始接触 A 股量化，数据规模在 1GB 以内，策略以单只股票的简单回测为主，SQLite 是最合适的选择。SQLite 零运维、单文件、支持标准 SQL，几乎所有编程语言都有成熟的客户端库。本地数据引擎通常会预装 SQLite 适配器，可以直接把数据导入 SQLite 数据库，省去自己搭建的麻烦。
5.2 个人量化进阶
如果你已经积累了几年的策略，数据规模在 10-50GB 之间，开始尝试多因子选股、跨市场套利、ETF 套利等复杂策略，DuckDB 是最合适的选择。DuckDB 单文件部署，零运维，聚合查询性能接近 ClickHouse，但不需要 ClickHouse 那种集群运维成本。DuckDB 在 2023 年以来的快速发展让它在个人量化领域迅速普及，很多本地数据引擎也开始原生支持 DuckDB 格式。
5.3 团队/机构量化
如果你是 3 人以上的小团队，或者在私募/资管机构做量化研究，数据规模在 100GB 以上，ClickHouse 是更专业的选择。ClickHouse 的集群部署可以支撑 TB 甚至 PB 级数据，列式存储让它在聚合查询和时间序列分析上的性能远超 SQLite 和 DuckDB。但 ClickHouse 的运维成本高，需要专门的运维人员或者使用云服务商的托管版本。本地数据引擎在这个规模下通常会提供 ClickHouse 的同步适配器，可以把数据从本地存储同步到 ClickHouse 集群。
六、迁移成本与未来兼容性
数据存储方案一旦选定，迁移成本非常高。从 JSON 迁移到 SQLite 相对简单，从 SQLite 迁移到 DuckDB 需要做表结构转换，从 DuckDB 迁移到 ClickHouse 需要做集群部署和数据同步。所以选型时要考虑未来 3-5 年的扩展性。
6.1 向上迁移
如果未来预期数据规模会增长，建议一开始就选用 DuckDB 或 ClickHouse。DuckDB 单机部署，未来如果数据规模超过单机容量，可以平滑迁移到 ClickHouse；ClickHouse 集群部署，扩展性最强，但初期投入大。
6.2 跨平台兼容性
DuckDB 的文件格式是开放的，可以被多种编程语言读取；ClickHouse 的存储格式相对封闭，迁移到其他系统需要做数据导出；SQLite 的格式几乎所有平台都支持，是跨平台兼容性最好的选择。
6.3 工具链生态
SQLite 和 DuckDB 的工具链生态最丰富，几乎所有数据分析工具都支持；ClickHouse 的工具链生态主要集中在专业的大数据领域，个人用户的学习成本较高。
七、本地数据引擎的存储适配策略
成熟的本地数据引擎通常会提供多种存储格式的适配器，用户可以根据自己的数据规模和查询模式灵活选择。下面这张表总结了本地数据引擎 ig50 在不同存储格式下的适配情况：
| 存储格式 | 数据规模 | 查询性能 | 适配情况 |
|---|---|---|---|
| JSON | GB 级 | 极差 | 适合配置文件、临时数据 |
| SQLite | GB 级 | 中等 | 适合个人量化新手 |
| DuckDB | GB-TB 级 | 强 | 适合个人量化进阶（默认推荐） |
| ClickHouse | TB 级 | 极强 | 适合团队/机构量化 |
ig50 本地数据引擎默认推荐 DuckDB 作为个人量化的存储方案，主要原因是 DuckDB 在 1GB-50GB 数据规模下的查询性能接近 ClickHouse，但运维成本接近 SQLite。对于个人量化研究员来说，DuckDB 是 2026 年最值得投入学习的存储方案。
八、实战建议
最后给出几条实战建议，帮助量化研究员在选型时少走弯路。
建议 1：先用 SQLite 跑通回测，再考虑升级。很多量化新手一开始就追求高性能数据库，结果大部分时间花在搭建和调优上，而不是策略本身。建议先用 SQLite 把回测链路跑通，验证策略逻辑后再考虑升级到 DuckDB 或 ClickHouse。
建议 2：关注查询模式而不是数据规模。同样是 10GB 数据，如果主要是单只股票的时间序列分析，SQLite 就够用；如果是全市场聚合查询，DuckDB 才能胜任。选型前先想清楚自己的策略需要什么类型的查询，再决定用什么存储方案。
建议 3：预留 3-5 年的扩展空间。数据规模会随着研究深入而增长，今天 1GB 的数据，三年后可能变成 50GB。建议选型时考虑未来的扩展性，避免频繁迁移。
建议 4：本地数据引擎是数据源，不是存储方案。本地数据引擎提供的是数据采集、清洗、标准化、本地落盘的完整链路，存储方案是用户自己选择的。这种"数据源 + 存储方案"的解耦设计，让用户可以根据自己的需求灵活选型。
资料参考：ig50