轻易云数据归档清理实战：两个月前的数据如何按策略批量删除

这个策略解决什么问题

在多套业务系统长期跑集成后,中间层会沉淀大量历史单据。我们在做某零售企业的供应链集成时就遇到这个情况:旺店通与金蝶云星空之间跑了几十条同步策略,半年下来日志表与中间库的数据量迅速膨胀,既拖慢查询,又增加存储成本。更麻烦的是,一旦涉及跨策略追溯,老数据反而成了"干扰项"。

这条策略的目的很明确:按策略名(Strategy)维度,把两个月前的中间数据批量删掉,只保留近期的可追溯范围。它属于"系统维护"层面的清理动作,而不是业务同步动作,适合作为集成平台的兜底治理策略。

数据流向与字段映射

清理动作的数据流向与常规的 A→B 同步不同,它是一条"清理源→平台内部清理动作→平台回写日志"的回路。

设计上有一个细节值得注意:删除动作做完之后,我们还会配一条"写入空操作"策略(crontab 23 2 * * *),作用是在归档窗口的前一刻再触发一次空写,作为清理动作顺利执行的"前置哨兵"。这是一种典型的兜底模式——如果空写失败,清理任务就会按依赖关系顺延,避免在脏数据上动手。

在轻易云上如何配置

在轻易云数据集成平台(Qeasy)里,这条策略的配置核心是 API 元数据 + 调度计划 两块。

1. 元数据建模:新增 WebAPI 元数据,API 选择 DeleteStrategyData,方法 POST,effect 设为 QUERY(平台内部按查询语义处理删除)。idCheck 保持开启,buildModel 关闭,autoFillResponse 打开,响应字段 datetime 与 params 由平台自动填充。
2. 请求对象配置:在 request 数组里添加若干个 object 类型的字段(target_1、target_2、…),每个对象的 value 留空,通过变量传入策略名。这里建议把策略名集中放到一个映射表里管理,避免散落在多个请求对象中——这是我们给客户最常做的"编码映射集中管理"模式。
3. 目标侧配置:目标端配置一个"写入空操作"的 WebAPI 元数据,作为依赖节点,确保清理动作发生时上游已经稳定。
4. 调度计划:源策略 crontab 设为 15 3 * * *,目标空写策略 crontab 设为 23 2 * * *,利用 cron 的时间差形成天然的先后顺序。

实施步骤

我们一般把这类清理策略分三个阶段上线,避免一刀切出问题。

阶段一:小范围灰度。先挑 1-2 条非关键策略试跑,例如优先级靠后的 ToC 销售退货单。观察平台返回的 params 与执行耗时,确认删除范围符合预期(只删中间层,不删源/目标系统)。

阶段二:扩大覆盖。把 ToB 销售出库单、ToB 销售退货单等核心业务策略纳入清理范围。此时建议同时打开"全量预演"开关——先做一次 dry-run,平台只返回将被删除的数据量而不真正执行,核对无误后再放开。

阶段三:常态化运行。crontab 每天 3:15 触发,保留两个月窗口。两个月前是一个相对稳妥的折中:既能覆盖大多数跨月对账场景,又能让中间库保持在合理体量。如果业务方要求更短窗口,只需调整平台内部的时间阈值,不需要改字段映射。

踩坑复盘

1. 别把"两个月前"写死成业务字段。最早我们试图在请求体里加一个 cutoff_date 字段让用户自己传,结果出现过客户传成 2025-13-01、时区错乱等问题。稳妥的做法是把时间窗口交给平台内部处理,只暴露策略名这一组入参。
2. 典型错误:删错了策略。多策略并存时,target_1、target_2 的命名一旦混乱,清理范围就会串。建议在请求对象里加一个 is_required=true 校验,并在映射表里给每个策略名加注释。
3. 空写策略别忘了配置。如果没有 23 2 * * * 的空写前置,清理动作可能在数据尚未稳定时就执行,造成"删早了"的假象。
4. 审计日志要单独存。平台返回的 datetime、params 是事后追溯的唯一凭据,建议把它落到一张独立的归档日志表,而不是和业务日志混在一起。
5. 公有云环境下的并发限制。如果一次清理的策略数太多(我们实测超过 20 条就可能触发节流),建议在 crontab 上做随机抖动(15 3 * * * 改为带随机秒),避免请求集中在某一秒。

适用场景与不适用场景

适用:中间层数据长期堆积、查询性能下降;业务侧只关心近 1-3 个月的可追溯范围;集成策略数量多(>10 条)、需要按策略粒度做精细化清理。

不适用:源/目标系统自身的历史数据清理(本方案只清中间层);监管要求长期归档的行业(如医药、金融),两个月窗口可能不满足合规;以及策略数量很少、清理收益不明显的轻量集成场景。