A 股数据本地存储方案对比JSON、SQLite、ClickHouse、DuckDB 怎么选把 A 股全市场 5000 只股票的历史行情、财务数据、逐笔交易、五档盘口搬回本地之后第一个绕不开的问题就是用什么格式存储本篇从实际工程实践出发把 JSON、SQLite、ClickHouse、DuckDB 四种方案在 A 股量化场景下的表现做一次系统对比给有同样困惑的量化研究员一份选型参考。一、本地存储在 A 股量化中的真实价值云端 API 在过去十年是 A 股数据获取的主流方式但随着量化策略对数据颗粒度和回测速度的要求越来越高本地存储的优势开始显现。本地数据引擎的核心价值不在于省钱而在于三点第一数据可复现。云端 API 的接口参数、字段定义、限流策略随时可能调整导致同一套回测代码在不同时刻跑出不同结果。本地存储的数据是快照任何时刻回测都是同一份数据。第二回测速度。5000 只股票 5 年的逐笔交易数据如果每次回测都从云端拉耗时是小时级如果从本地拉单次回测可以压缩到分钟级甚至秒级。第三数据安全。本地存储意味着数据完全归属于用户不受任何第三方平台政策影响。这对长期量化研究至关重要。但本地存储并不是免费的。第一个要解决的问题就是选型用什么格式存用什么引擎查这是本篇要回答的核心问题。二、四种主流方案对比下面这张表从数据规模适应性、查询性能、写入速度、运维复杂度、生态成熟度、适用场景六个维度做对比。维度JSON 文件SQLiteClickHouseDuckDB数据规模适应性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 单机部署未来如果数据规模超过单机容量可以平滑迁移到 ClickHouseClickHouse 集群部署扩展性最强但初期投入大。6.2 跨平台兼容性DuckDB 的文件格式是开放的可以被多种编程语言读取ClickHouse 的存储格式相对封闭迁移到其他系统需要做数据导出SQLite 的格式几乎所有平台都支持是跨平台兼容性最好的选择。6.3 工具链生态SQLite 和 DuckDB 的工具链生态最丰富几乎所有数据分析工具都支持ClickHouse 的工具链生态主要集中在专业的大数据领域个人用户的学习成本较高。七、本地数据引擎的存储适配策略成熟的本地数据引擎通常会提供多种存储格式的适配器用户可以根据自己的数据规模和查询模式灵活选择。下面这张表总结了本地数据引擎 ig50 在不同存储格式下的适配情况存储格式数据规模查询性能适配情况JSONGB 级极差适合配置文件、临时数据SQLiteGB 级中等适合个人量化新手DuckDBGB-TB 级强适合个人量化进阶默认推荐ClickHouseTB 级极强适合团队/机构量化ig50 本地数据引擎默认推荐 DuckDB 作为个人量化的存储方案主要原因是 DuckDB 在 1GB-50GB 数据规模下的查询性能接近 ClickHouse但运维成本接近 SQLite。对于个人量化研究员来说DuckDB 是 2026 年最值得投入学习的存储方案。八、实战建议最后给出几条实战建议帮助量化研究员在选型时少走弯路。建议 1先用 SQLite 跑通回测再考虑升级。很多量化新手一开始就追求高性能数据库结果大部分时间花在搭建和调优上而不是策略本身。建议先用 SQLite 把回测链路跑通验证策略逻辑后再考虑升级到 DuckDB 或 ClickHouse。建议 2关注查询模式而不是数据规模。同样是 10GB 数据如果主要是单只股票的时间序列分析SQLite 就够用如果是全市场聚合查询DuckDB 才能胜任。选型前先想清楚自己的策略需要什么类型的查询再决定用什么存储方案。建议 3预留 3-5 年的扩展空间。数据规模会随着研究深入而增长今天 1GB 的数据三年后可能变成 50GB。建议选型时考虑未来的扩展性避免频繁迁移。建议 4本地数据引擎是数据源不是存储方案。本地数据引擎提供的是数据采集、清洗、标准化、本地落盘的完整链路存储方案是用户自己选择的。这种数据源 存储方案的解耦设计让用户可以根据自己的需求灵活选型。资料参考ig50gitee开源地址github开源地址