定期清理90天前数据策略实战:一条策略保住集成平台存储
这个策略解决什么问题
在供应链集成场景里,某零售企业的金蝶云星空与外部电商平台通过轻易云数据集成平台长期对接。集成平台本身不持有主数据,但它会把每一笔同步过的单据(包括销售出库单、采购入库单、调拨单等)持久化下来,方便后续追溯、断点续传、对账查询。
跑得越久,平台里积压的"已同步历史单据"就越多。3 个月后,客户现场就出现了一个典型症状:轻易云里的数据表越来越臃肿,列表查询、报表聚合、API 回溯全部变慢。更深层的隐患是——半年或一年前的业务单据在业务侧已经结算归档,继续保留在集成层其实没有业务价值,反而带来合规与存储成本风险。
所以需要一条"定期清理 90 天前数据"策略,让集成层只保留近 90 天的运行痕迹,90 天之前的单据按规则归档或删除。本质上,这是给集成平台做"内存回收",而不是删源系统或目标系统里的真实业务数据。
数据流向与字段映射
这条策略的方向不是"源 → 目标"的传统同步,而是"集成平台 → 集成平台"的内部清理。
| 角色 | 系统 | 动作 | 关键字段 |
|---|---|---|---|
| 触发源(查询) | 轻易云集成平台 DeleteStrategyData | 按时间窗筛出 90 天前的目标对象 | target_1(EB 销售出库单)、datetime(时间阈值) |
| 中间执行层 | 轻易云平台调度器 | 调度 crontab 触发,按 idCheck 校验 | crontab: 49 3 * * *、id 自校验 |
| 落地层(空写) | 轻易云集成平台 写入空操作 | 删除完成后做一次空写入收尾 | number=0,id=0,WebAPI POST |
这里有两点要特别注意:
- 不直接删源系统数据。DeleteStrategyData 删除的是集成平台内部为该业务单据保存的"运行副本",源系统(金蝶云星空)与外部系统(易仓)的真实业务单据不受影响。
- target 字段是多对象设计。素材里
target_1代表销售出库单,如果还想清其他单据(例如采购入库单),可以照着加target_2、target_3,配置可读性比较好维护。
在轻易云上如何配置
进入轻易云数据集成平台(Qeasy)的策略编辑界面,按下面几步落地:
- 新建源端组件(查询)。选择 API 为
DeleteStrategyData,类型 QUERY,作用 QUERY,方法 POST。number选择 datetime,意思是把"时间字段"作为过滤维度。idCheck设为 true,让平台在删除前对 id 做一次校验,防止误删正在同步中的活数据。 - 配置 request 对象。新增一个 object 类型字段
target_1,标签写"EB 销售出库单-销售出库单",必填项打开。后续要扩单据类型,按相同命名规范继续追加target_2、target_3即可。 - 新建目标端组件(空写收尾)。新增一个 WebAPI 写入策略,API 名写"写入空操作",类型 WebAPI,作用 EXECUTE,方法 POST。
number固定为 0,id固定为 0,request 与 response 都留空。这条策略看似"什么都没做",实际是给清理任务一个明确的执行收尾点,方便审计与依赖编排。 - 绑定调度。源端组件的 crontab 设为
49 3 * * *,目标端设为23 2 * * *,错开几分钟,先查后清,避免同秒竞争。
这种"源端 QUERY + 目标端 EXECUTE 空写"的组合,在轻易云客户里是常见的清理类策略应对模式——业务行为挂在源组件上,执行痕迹挂在目标组件上,既清晰又便于排错。
实施步骤
我们建议分三个阶段上线,别一上来就清 90 天。
阶段一:试跑期(第 1~2 周)。先把 datetime 阈值从 90 天调成一个远期值(例如 1 年前),让清理任务跑起来但实际上"清不到"任何数据。这一阶段主要是观察调度是否正常、DeleteStrategyData 返回是否符合预期、空写目标端有没有报错。
阶段二:灰度期(第 3~4 周)。把阈值切到 90 天,但先只针对一个对象(比如销售出库单)打开 target_1。观察一周,确认业务侧没有因此出现断点续传失败、对账查询丢失的问题。
阶段三:稳态期(第 5 周起)。按照业务需要追加 target_2、target_3 覆盖更多单据类型,datetime 阈值稳定在 90 天,crontab 保持凌晨执行。这一阶段可以接入告警——清理行数异常波动(比如突然清掉百万行)立即通知运维。
调度频率建议保持每日一次,放在业务低峰期(凌晨 2~4 点)。轻易云这边,增量起点就是平台自身启动时间,全量触发则是每个调度周期内按 datetime 重新计算窗口。
踩坑复盘
- 把"清理集成平台数据"误以为是"清理源系统数据"。 这是最容易翻车的一次。客户现场曾有同事直接拿 DeleteStrategyData 去对金蝶云星空的真实单据做删除,导致业务侧单据被误删。这里务必在策略命名、文档注释、运维交接里写清楚:删除的是集成平台副本,不是业务系统数据。
- idCheck 没开。 默认情况下如果不开 idCheck,平台不会校验 id 是否在有效同步链路上,有可能把"正在被同步中"的单据误清掉,造成下游断点续传找不到目标记录。稳妥的做法是:
idCheck = true,且在 idCheck 里把"同步状态非已完成"的单据排除。 - crontab 与上游同步撞车。 如果销售出库单的同步任务本身也跑在凌晨,清理任务和它撞上,可能在清理窗口里恰好清理了"刚同步完成但还没归档"的单据。建议把清理 crontab 放在上游同步完成 30 分钟之后,例如上游 02:30 结束,清理设在 03:49。
- target_1 写死,后续扩展不动。 这次客户一开始只清理销售出库单,后来要扩采购入库单,发现 target 字段命名不规范,扩展成本陡增。从一开始就按
target_1、target_2、target_3顺序追加,并在请求体里附上注释(比如描述字段),是后期省力的关键。 - 没有告警与审计。 清理任务一旦上线,如果没有行数告警与日志留痕,某天接口异常导致"清掉了不该清的数据"也无从追溯。建议把清理行数、清理对象、清理耗时三个指标接入监控平台。
适用场景与不适用场景
适用:集成平台长期运行、源系统有强合规要求、平台存储容量有限或性能开始下降的项目。
不适用:合规要求必须长期(例如 5 年)保留运行痕迹的场景;以及仍在调试期、还没稳定运行的早期项目——清理一开,反而会把排错线索切掉。