销售订单历史数据清理策略实战:用轻易云做「删除 90 天前数据」

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

在销售订单同步链路里,中间库或影子表会随时间不断膨胀。某零售企业上线半年,「销售单对接(1-零售业务)」「礼顿销售单对接(1-零售业务)」「销售单对接(2-分销业务)」三张对接表已经积累了上百天的历史数据。日志查询变慢,后续同步策略的扫描耗时也受影响。

「删除 90 天前数据」本身不搬运业务数据,而是为整条链路做「瘦身」,把已闭环的旧单据从对接表中清掉。它的价值不在于功能复杂,而在于让数据生命周期可控:增量策略跑得轻,排查问题更聚焦,合规审计也只针对活数据。

这条策略的特殊之处在于:它的"源"和"目标"都落在轻易云自身的对接中间层,不直接读写源系统与目标系统。

源端 api: DeleteStrategyData 是查询型接口,负责定位候选记录;目标端 api: 写入空操作 是执行型接口,真正的删除动作由轻易云平台按对象维度完成。target_2 设为非必填,意味着可按需扩展清理对象,而不是每次改策略都要重做。

在轻易云数据集成平台(Qeasy)中,这类「清理型」策略的典型配置要点如下:

策略类型归类:在策略列表中归到 系统维护 模块,而不是 业务单据。它不参与正向业务流转,只做后台维护。
源端元数据:选用 DeleteStrategyData 接口,type=QUERY、effect=QUERY、method=POST,标识这是「按条件挑数据」而非「取增量」。
请求对象:把 target_1、target_2、target_3 都作为 object 类型显式声明,target_2 设 is_required: false,留给后续扩展。这是轻易云客户常见的「编码映射集中管理」做法:同一类对象集中在一个策略里清,避免散落在十几条同步策略里各管各的。
目标端元数据:用「写入空操作」作为占位 API,关键是把 idCheck: true 打开,平台才知道按 id 维度去匹配。
平台归属:源与目标都填同一个 platform_id(轻易云自身),避免被误读成跨系统同步。

我们把这条策略拆成三段来上线,顺序很重要。

第一阶段:全量触发(上线当天)

先手动触发一次,清掉上线前已经积压的旧数据。典型做法是把时间窗口临时放宽,比如先删 180 天前的,跑完一轮观察无误再切到 90 天。轻易云的 autoFillResponse: false 在这一步非常关键——不希望平台自动补响应结构,避免把待删记录当成新单据回流。

第二阶段:增量起点(第二天 02:23)

目标端 crontab: 23 2 * * *,每天凌晨 02:23 触发。这是轻易云现场常说的「深夜窗口跑维护」模式:业务低峰期做清理,不挤压正午时段的同步资源。

第三阶段:调度稳态(源端兜底)

源端 crontab: 3 8 * * *,每天 08:03 跑一次扫描,把昨天生成的候选记录提前圈出来,等到 02:23 执行删除时直接命中。两段调度错峰,形成「上午圈数、深夜动手」的节奏,符合「增量与全量双轨」的工程习惯。

分阶段调度小结:

1. 把「删除策略」当成「同步策略」排进业务链路 典型错误是按 sequence A→B 的顺序把它排进 15 条业务策略里,导致清理动作被业务依赖拖住。稳妥做法是把它单独标记为 系统维护 模块,从业务编排图里摘出来。

2. 时间锚点选错字段 number: datetime 看似通用,实际不同对接表的「时间字段」语义不同:有的用单据日期,有的用同步入库时间。拿错字段会清掉还没闭环的活单。这里容易翻车,稳妥的做法是和业务方确认每个 target_x 的「90 天」到底从哪天算起。

3. 漏配 idCheck 如果 idCheck: false,平台可能用别的字段去匹配,删除结果不可预期。看似无关紧要的开关,一旦关错就是「误删」级别的事故。

4. 清理频率过密 每天清一次没问题,但如果同时跑 3 个 target_xx 对象、每个对象又叠加其他策略,凌晨容易撞库。稳妥做法是错峰编排,清理任务尽量串行。

5. 没留审计日志 清理型策略上线后,出问题第一反应就是「昨天清了谁」。建议在轻易云的响应结构里预留一个 audit 字段,把每天删除的记录数和最早/最晚时间戳落库,出问题时能反查。

适用:业务闭环已稳定、历史数据无分析价值、合规保留期短于 90 天的对接中间表;影子表、临时对接表、批量补单日志。不适用:作为唯一数据源的主业务表、存在合规审计要求(通常需保留 3-5 年)的财务单据、被其他 BI 系统实时读取的同步表。