量化项目(zdq)分钟数据导入攻坚过程记录

背景

2026-04-22 前后,量化项目(工作区 d:\code\python\zdq)因对当时模型效果不满停滞了几天;得知 codingplan 上线 glm5.1 和 kimi2.6 后,用新模型重启工作。本次会话目标:盘点项目进度、重启数据导入。本人当时的判断:历史数据是后期回测的生命线,必须攻克;分钟数据量太大,可以分批导入,先导入 2020 年以后的数据。

核心内容

会话时点的项目状态(2026-04-22,来自当时助手扫描项目报告/数据库的结论)

• 日周月线数据已完整入库(stock_daily/weekly/monthly、index_daily/weekly/monthly,覆盖 1990/1991 年至 2026 年 3 月),无需补充。
• 分钟数据是最大瓶颈:本地 CSV 文件约 8674 万个,已导入仅约 1 万个(0.01%);stock_1min 有约 16.7 亿条(早前 ClickHouse 导入),15/30/60 分钟表和指数分钟表为空。导入脚本此前已优化过,但任务没有持续跑完。
• 选股策略、MCP/API 服务、前端看板当时报告为基本完成,但后端 API 与前端缺少最新测试记录。
• 磁盘空间一度达 97.4%(4 月 5 日记录),列为 P0 风险。

本次会话的决策与执行

1. 确认日周月线无需重导,集中攻坚分钟数据,范围定为 2020-2026 年。
2. 导入中途发现速度下降、内存上涨,定位并切换到优化版脚本(方法详见 summary 条目),优化后速度约 19.6 万条/秒、内存约 3.3GB 稳定。
3. 发现"2020年其他月"异常分组:原因是按年汇总的 zip 路径里提取不到月份。本人裁定按年与按月是重复数据,只导入按月数据、过滤按年文件,待导入文件从 1302 个减到 1262 个。
4. 清理收尾:删除旧脚本 import_minute_data_2020plus.py,保留优化版 import_minute_data_optimized.py 并提交推送 Gitee。

暴露的问题

• Gitee 仓库超配额:推送时告警仓库 1172MB 超过 1024MB 配额,仅剩 3 次 push 机会,需清理历史大文件或迁移 GitHub/GitLab。会话末尾已开始排查大文件,但原文在此截断,结论未记录。
• 当时助手报告的策略回测指标(年化 128.7% 等)来自项目内报告,未经本次会话实测验证;按现行铁律,系统内置的演示回测数据不可作论据,引用时须注意。

原文链接

提炼自 inbox/trae/20260424_测试模型调用.md