用轻易云清理90天前的中间表数据:一条常被忽略的运维策略实战

这个策略解决什么问题(场景与价值)

在一次实际的供应链集成项目中,我们把旺店通和金蝶云星空之间的销售出库单、销售退货单做了双向同步。运行两个月后,中间表里的累积记录已经接近百万级,平台本身的运行效率没有明显下降,但客户 IT 团队却坐不住了——审计要求保留 90 天可追溯明细,再老的就要清理掉,否则既占空间,导出报表时也慢。

这就是「删除90天前数据」这条策略的定位。它不是同步策略,而是一条运维类的清理策略,挂在轻易云集成平台里,定时把 90 天之前的中间表记录批量删掉。它的价值在于:让中间表保持“热数据温热、冷数据干净”的状态,既满足合规,又不拖累日常同步链路。

数据流向与字段映射(源 → 中间层 → 目标)

这条策略的链路比较特殊,它不是「源系统 → 中间表 → 目标系统」的数据搬运,而是「中间表 → 自身清理」的闭环操作。理解这一点,是配置时不踩坑的前提。

源接口的 request 字段里,target_1、target_2 这种对象设计是轻易云里常见的模式:每个 target 代表一个要被清理的业务策略,可以按需扩展。response 走 _autoFillResponse 自动填充,把查到的 datetime、params 透传给下游。

在轻易云上如何配置

我们用轻易云数据集成平台承接这条策略,通常按下面几个要点配置:

1. 新建 WebAPI 类型的源接口:API 名称填 DeleteStrategyData,请求方式 POST,effect 选 QUERY,勾选 autoFillResponse 和 idCheck,让平台自动处理返回结构。
2. 在 request 里声明要清理的目标对象:把 target_1、target_2 当成“清理对象清单”,每个对象里配置业务策略标识,而不是写死单据类型。这样新增业务模块时,只需要复制 target 即可。
3. 目标接口用「写入空操作」承接:这里用了一个常见技巧——目标端不需要再调任何业务接口,只需要让轻易云把上游传过来的清理参数执行掉,所以建一个空响应的 WebAPI 占位即可。
4. 调度 cron 拆开:源端 20 8 * * *,目标端 23 2 * * *,两条 cron 不在同一分钟,避免同时间并发压到中间表。

这套配置让客户的 IT 同事只需要在轻易云里维护 target 对象清单,不需要写一行 SQL。

实施步骤(分阶段调度:增量起点 / 全量触发 / 调度频率)

我们一般把这个策略上线拆成三步走:

• 第一步:验证清理范围。上线前一天手动跑一次,把要删的记录数量导出来给客户确认,避免误删。轻易云这边的 autoFillResponse 会把命中的 datetime、params 回填,可以直接核对。
• 第二步:小流量灰度。先把调度频率改成「每周一次」,观察一到两周内中间表大小、清理命中率、依赖策略(比如当天的销售出库单同步)有没有异常。
• 第三步:切到正式 cron。源 20 8 * * *、目标 23 2 * * *,每天清晨执行。轻易云客户常用的做法是:表头表体分阶段——表头 90 天,表体保留 180 天,这条清理策略只管表头,表体另起一条;增量与全量双轨——日常走增量 cron,每月初加跑一次全量核对,确认无残留。

踩坑复盘

1. 典型错误是直接把清理策略排在业务同步之前跑。一旦清理先于当天同步执行,审计追溯会断档。稳妥的做法是在轻易云的「依赖策略」里把它排在所有同步策略之后,或让 cron 时间点晚于当晚最晚的同步策略。
2. target 对象没集中管理,散落在多个策略里。某零售企业早期就是这样,后来把所有清理对象收敛到一个映射表里维护,新增业务模块时只追加一个 target,不再改主策略。
3. 忽略 _autoFillResponse 的回传字段。清理任务执行后,没有把命中的 datetime 落库,导致事后审计时无法回溯“哪天清掉了哪些批次”。
4. 没考虑目标端的写入空操作的幂等性。如果某天源端跑成功、目标端因网络抖动失败,第二天重跑时,同一批 ID 会被再次请求,需要在目标端做去重或让源端按 idCheck 过滤。

适用场景与不适用场景

适合:中间表有合规保留期要求、清理动作稳定可定时、对业务同步链路无强依赖的供应链集成项目。

不适合:有实时审计追溯要求,或中间表本身还要给 BI、数据仓库做长期供数的场景——清理会直接破坏下游链路,需要改用归档而非删除。