数据更新策略：全量下载+增量追加
我的掌握程度：
先掌握这个答案
全量+增量：①全量（一次性）：下载全部历史→存parquet→标记快照日期；②增量（每日/每周）：从上次缓存的最后日期+1到现在→追加到单票文件→定期重拼面板。增量脚本结构：for code: last_date = cache.last_date; new = fetch(code, start=last_date+1); append。重新全量的触发：①复权因子变了（分红新发→全链重算）；②数据商修正历史数据（发生频率低但存在）；③季度重构（数据结构变化）。建议频率：每季度做一次全量校准。
先读结论，再核对下方使用边界；数字例题为教学情景，涉及实际行情与规则时请核对原始来源。
从理解到使用
本阶段实战方法 · 一条能复现的数据流水线
把接口返回的数据变成可用于因子研究的面板时，先处理时点、主键与单位。
- 建立数据字典：字段、单位、时区、交易日历、数据源、抓取时间、原始价与复权因子。
- 用(date, code)查重，区分停牌、未上市、窗口不足和真实缺失；不要用向后填充把未来值带回过去。
- 保存原始快照与清洗日志，固定随机种子和环境版本；接口字段变化时先核对官方文档。
使用边界
- 报告期不等于公告可用日，盘后公告通常不能用于当天收盘前决策。
- API输出名为“动态市盈率”时不能直接改名TTM；浏览器练习不支持任意原生库或行情抓取接口。
背景 · 从一个困惑说起
第一次花2小时下载全市场——每次研究都重新下载？还是每天只追加新数据？正确答案：一次全量+每日增量——节省99%的时间。
由此产生的问题
全量vs增量的策略设计？增量脚本的结构（上次日期+1到今天）？什么时候需要重新全量（复权/数据修订）？
核心概念
全量+增量：①全量（一次性）：下载全部历史→存parquet→标记快照日期；②增量（每日/每周）：从上次缓存的最后日期+1到现在→追加到单票文件→定期重拼面板。增量脚本结构：for code: last_date = cache.last_date; new = fetch(code, start=last_date+1); append。重新全量的触发：①复权因子变了（分红新发→全链重算）；②数据商修正历史数据（发生频率低但存在）；③季度重构（数据结构变化）。建议频率：每季度做一次全量校准。
为什么需要它
①研究节奏的解放：全量2小时→增量30秒——你每天想跑数据就跑不用「下决心」；②自动化的起点：增量脚本是迈向全自动数据管道（cron定时）的第一步；③快照纪律（q-359）的执行工具：增量追加+快照记录=可复现数据。
实际应用场景
脚本结构：python update_data.py --incremental→读每个缓存的最后日期→追加→重拼面板→更新README快照日期。
与之前知识的联系
q-328（全量下载战役）→本题（日常增量）→q-339（更新后校验）；快照纪律（q-359）的工具版。
⚠ 常见误解
- 每次都重新下载最保险：全量重下=2小时+可能触发限频——增量=30秒且安全；只有季度校准时才全量
- 增量需要改动原始缓存：追加模式（append）即可——不需要重写整个文件；parquet用partition或者用文件追加
- 增量数据不需要校验：增量更新后同样跑体检（行数/超界值/NaN率）——新数据引入新bug的概率不低
- 复权因子不常变所以不用全量：每次分红/送股都改因子→增量可能拼接错位（q-330的深坑）→季度全量校准是必须的
🛠 本题实践任务
为你的数据写增量更新脚本（或改造现有的下载脚本为增量模式）——运行一次确认只追加新数据不重复下载。加一行更新日志（日期+新行数）。
💡 提示（先自己想5分钟再看）
读缓存的最后日期→fetch从last+1开始→concat去重→追加；未来用cron/任务计划自动跑。
✅ 验收标准
一次成功的增量更新+日志记录。你的数据管道从手动战役进化为日常自动化。
在你的浏览器内运行。首次需联网下载 Python；支持标准库和 Pyodide 提供的 NumPy、pandas 等包。行情抓取、系统文件访问和部分第三方库请在本地环境运行。输出自检仅比对结果关键词，不代替逻辑审查。
Python · 独立工作线程 · 执行限时10秒
🤖 AI导师
导师会先检查你的前置知识（存储方案、缓存），再用案例、公式和代码帮助理解。此功能需要先启用服务。