日志处理场景经常会有数据晚到的异常场景，比如某个链路异常导致数据到达ES比较晚，但是其他日志数据到达ES时间是正常的。
当使对索引Rollup时并不知道数据已经是最终态，或者已经rollup的索引有了新数据，这时候Rollup是否能正常处理。
举例说明：
时刻1： Index_Ori 中有Doc A、B、C三条数据
时刻2：对Index_Ori进行合并，根据规则生成 Index_rollup，包含一条数据RollupA，RollupA=agg_func(A、B、C)
时刻3：Index_Ori有新数据D到达，该数据的时间戳和A、B、C在一个时间窗口呢，按照正常结果应该是： RollupA=agg_func(A、B、C、D)
看RollUp的文档介绍定时任务会处理最新的未处理过的数据，
这种场景下，数据D会自动处理吗？RollUp底层是增量合并的还是把 A\B\C\D全量重新合并了一次呢？
当使对索引Rollup时并不知道数据已经是最终态，或者已经rollup的索引有了新数据，这时候Rollup是否能正常处理。
举例说明：
时刻1： Index_Ori 中有Doc A、B、C三条数据
时刻2：对Index_Ori进行合并，根据规则生成 Index_rollup，包含一条数据RollupA，RollupA=agg_func(A、B、C)
时刻3：Index_Ori有新数据D到达，该数据的时间戳和A、B、C在一个时间窗口呢，按照正常结果应该是： RollupA=agg_func(A、B、C、D)
看RollUp的文档介绍定时任务会处理最新的未处理过的数据，
这种场景下，数据D会自动处理吗？RollUp底层是增量合并的还是把 A\B\C\D全量重新合并了一次呢？
4 个回复
kennywu76 - Wood
赞同来自: Danble
好在rollup api可以支持同时搜索裸索引和rollup过的索引，所以如果数据经常有延迟的话，可以考虑设置一个合适的delay，比如1h, 6h甚至24h等等。 这样rollup的索引产生会有延迟，但是能确保迟到的数据被处理。 从应用场景上看，rollup一般是为了对历史数据做聚合存放，减少存储空间，所以延迟几个小时，甚至几天都是合理的。 搜索的时候，同时搜索最近的裸索引和历史的rollup索引，就能将两者的数据组合起来，在给出正确的聚合结果的情况下，又兼顾了性能。
medcl - 今晚打老虎。
赞同来自:
Danble - 80后IT男
赞同来自:
所以数据延迟到达不会被处理，当前我们使用延迟1d的方式操作，正常场景下都可以处理。
fanmo3yuan
赞同来自: