接口返回累计消耗，数仓能直接求和吗？差分为什么会出现负数？
面试怎么回答
我先确认接口字段是哪个范围的累计值，完整保存对象、业务日期、币种、统计口径和采集版本。日累计快照不能按采集次数求和，差分也必须在同一累计范围与可信顺序内计算。负差可能来自历史修正、重置或乱序，需要分类而不是截零。报表可以保留最新确认值，同时维护可追溯修正记录，并与同版本源数据对账。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
一个接口早上返回消耗100，中午返回150，晚上返回180。当天消耗是430，还是180？如果第二天复查又变成175，少掉的5元该当作脏数据丢掉吗？
累计值是某个范围截至某时点的快照，不是新增流水；差分前要固定统计范围、版本与重置规则，负差不能默认截零。
先读懂“累计到哪里”
累计可能是某业务日从零点到当前，也可能是活动启动到当前，或者查询区间内的总量。字段都叫cost，不代表具有相同的累加语义。
接口还可能按账户时区、币种、归因设置和过滤条件返回结果。这些维度改变后，两个数值不一定具有可比性，不能仅按广告ID排时间做LAG。
本文使用通用接口示例，不假定某个平台允许哪些修正。接入前应以实际接口合同、样例与业务确认明确字段性质，再设计计算方式。
原始快照表与业务结果表各司其职
原始采集层可以保存请求范围、业务对象、业务日期、累计值、源版本、采集时间和采集批次。重复重试按明确的采集或来源身份处理，保留必要追踪信息。
业务结果层则按目标粒度选取可信的当前版本，例如每对象每天一条已确认金额。不是把所有采集快照都当成独立交易流水追加到金额事实表。
采集时间晚，不保证源数据版本新。存在缓存或重放时，要优先使用接口提供的可靠版本信息；没有版本时也应记录局限，不能宣称恢复了真实变化顺序。
差分得到观察变化，不必然得到小时事实
同一日累计从100到150，相邻差值为50，可以解释为两次观察之间总量的变化。只有源系统语义保证时，才能进一步称为这几个小时实际发生的消耗。
例如晚到归因把上午的金额补进下午快照，差值包含的是历史补记，而不全是下午新增业务。若要精确小时指标，应优先获取对应小时粒度的权威数据。
首个快照也有边界：早上九点第一次看到100，不代表九点这一刻新增100。它可能包含零点以来的全部累计，不能均匀分配到未知时段后当作真实数据。
负差需要分类，不要统一截成零
同一统计范围从180修正为175，可能是净额调整；跨日从180变成5，可能是日累计重置；旧快照晚到，也可能造成表面下降。
这些原因对下游处理不同。截零会保留此前高估的结果，还会让所有修正无法守恒；直接当作退款流水，也可能把技术乱序错记成业务事件。
可以在确定同一范围与可信版本后记录净变化，同时保存原因类别和原快照引用。无法判定的变化进入核验，不自动改造成确定的业务解释。
一个典型场景：采集越勤，报表花费越高
假设团队把采集频率从每小时改为每十分钟，报表消耗突然扩大。最初怀疑投放增长，但源平台按天结果没有同幅变化。
根因是下游将累计快照逐条求和，采得越勤，同一段消耗被重复计入越多次。旧验数只抽查单条快照金额与接口是否一致，没有验证业务日期粒度的聚合方式。
修正从原始层重建每日可信版本，对受影响日期重新对账，再将采集频率变化纳入测试：改变观察次数，不应改变同一源版本的最终日金额。
遇到后续从180修正到175，保留更正轨迹，并按已确认的发布规则修正日结果，而不是在报告里永远保留180。
最终结果也需要声明截至时间
尚未稳定的当天金额可以作为暂估值，标注更新时间。历史日期是否继续回查、多久视为稳定，应由接口特点和业务要求决定，不能随意规定所有平台都只修正一天。
对账应固定相同账户、时区、币种、日期范围、口径和数据版本。只有这些条件一致，差异才具有可解释性，否则一次“金额不一致”可能只是两次观察的边界不同。