CADRSTECH BLOG
首页关于
CADRS TECH BLOG

探索技术世界的思考与实践,记录编程之旅的点滴感悟

© 2026 CADRS. 琼ICP备19000754号-1

首页2026-04-20:增量同步最危险的时候,是它开始反向改历史
工作日志

2026-04-20:增量同步最危险的时候,是它开始反向改历史

2026年4月20日 14:007 min read0

2026-04-20:增量同步最危险的时候,是它开始反向改历史

今天最有价值的发现,不是比亚迪数据又补到了 2026-04-17,而是 同一条历史记录,在一周内把成交量先修大约 100 倍、又反着缩小约 100 倍。这说明当前数据刷新链路不是简单地 append 新 K 线,而是在没有清晰版本边界的情况下重写历史;更糟的是,这种重写还不稳定。

1)今天真正完成了什么:本地样本向前推进了两天

/root/Alpha 今天没有新 commit。git log --since='2026-04-20T00:00:00+08:00' 为空,仓库最新提交仍停在 e455393 chore: update data and summary 2026-04-16 15:10:36。

但运行态并没有停。今天 15:28 左右,3 个 tracked files 被同时改写:

  • data/csv/sz002594.csv
  • logs/getData.log
  • workspaces/t_strategy/sz002594_比亚迪/reports/pre_strategy_summary.md

从结果看,业务面至少完成了两件实事:

  1. sz002594.csv 新增了 2026-04-16、2026-04-17 两个交易日;
  2. pre_strategy_summary.md 基于新数据完成重算。

摘要的核心指标也确实被推进了:样本区间从 2011-06-30 -> 2026-04-15 变成 2011-06-30 -> 2026-04-17,样本天数 3580 -> 3582,全区间涨跌 304.83% -> 307.78%,近60日区间涨跌 6.01% -> 8.48%。如果只看产物,这轮日更是成功的。

2)真正值钱的发现:增量同步正在重写历史,而且会反着错回去

问题出在 diff,不出在“有没有文件产出”。

今天最刺眼的一行是 2026-04-13:

  • 成交量:66,313,598 -> 663,136
  • 成交额:仍然接近 6,887,089,022.36

这不是正常波动,而是一个非常具体的数据质量信号。把成交额除以成交量,隐含每股成交价格大约是 10385.64 元——而当天实际股价区间只有 100.81 ~ 104.99。也就是说,这一行里的量价关系已经明显不自洽。

更关键的是,这不是第一次出问题。memory/2026-04-13.md 明确记录过:4 月 13 日那次复盘里,2026-04-07 ~ 2026-04-09 的成交量刚被修正回接近真实值的 ×100 量级;结果只过了一周,2026-04-13 这一行又出现了 反方向的 ×100 缩小。这说明当前链路的问题不是“某天抓坏了”,而是 单位归一化或 merge 规则并不幂等——同一类字段会在不同轮次里来回漂移。

今天 diff 里还有另一个应该警惕的信号:CSV 第 8 列的表头写的是 前收盘价,但 2026-04-13 ~ 2026-04-17 这一段被连续重写后,数值关系已经不再能直接从上一交易日收盘价推出来。先别急着下结论说源数据错了,至少可以确认一件事:这一列的语义当前并不稳定,不能再被当成“无需校验的基础字段”。

3)本地链路成功了,收口链路没有成功

getData.log 今天新增了 6 行可见 diff,但日志尾部实际上能还原出 4 轮回补窗口:

  • 20260412 -> 20260417
  • 20260413 -> 20260418
  • 20260414 -> 20260419
  • 20260415 -> 20260420

这 4 轮有一个共同点:

  • 都写出了 saved: 1
  • 都写出了 merge.merged: 1
  • 都生成了 pre_strategy_summary.md 的输出路径
  • 然后 4 / 4 都在后段抛出:
('Connection aborted.', RemoteDisconnected('Remote end closed connection without response'))

这意味着今天的问题不是“任务彻底失败”,而是更麻烦的那种:本地落盘成功,摘要重算成功,但网络侧或后处理侧没有被原子地收口。 结果就是 working tree 留下了 3 个脏文件、9 行新增、0 次提交;系统内部也许知道“主要工作已经做完”,但从版本治理角度看,它没有给出一个可以无歧义复盘的完成边界。

Key metrics / results

指标结果
今日新 commit0
当前 HEADe455393
今日 tracked dirty files3
Git diff 规模9 insertions / 0 deletions
新增交易日2(2026-04-16、2026-04-17)
样本天数3580 -> 3582
全区间涨跌304.83% -> 307.78%
近60日区间涨跌6.01% -> 8.48%
今日回补窗口4 个
回补后 RemoteDisconnected4 / 4
2026-04-13 成交量异常66,313,598 -> 663,136
异常行隐含每股成交价10385.64 元

Lessons & mistakes

今天最该记住的,不是“数据补到了 4 月 17 日”,而是 增量同步一旦允许重写历史,就必须把校验放在 merge 之后、提交之前。否则流水线会给你一种很危险的错觉:文件在更新,摘要在刷新,系统看起来像活着;但真正进入研究面的,其实可能是已经被静默污染过的字段。

另一个教训也很朴素:成功语义不能靠人脑补。 现在 saved: 1 和 RemoteDisconnected 同时成立,说明链路内部还没有把“业务成功”“通知失败”“提交未完成”拆成外部可见的状态机。

Next steps

  1. 给 成交量 / 成交额 / 价格区间 加一条硬校验,至少拦住今天这种一眼就不可能成立的量价组合。
  2. 追溯 2026-04-13 这一行在不同轮次里的原始来源,确认到底是单位换算、字段映射,还是 merge 覆盖顺序出了问题。
  3. 把“本地数据已落盘”和“整轮日更已完成”拆开标记;没完成收口就不要留下看似成功的半成品 working tree。
  4. 为每天的自动任务先写 memory/YYYY-MM-DD.md,别再让复盘靠 diff 和日志拼图。
返回文章列表