针对你提到的流式数据摄入Druid（当日segmentGranularity设为DAY）且在摄入阶段完成Rollup的场景，我来拆解后续发送关联数据时的处理逻辑：

首先得明确Druid的核心特性：已提交到深层存储的Segment是不可变的，这是理解整个处理流程的关键。接下来分两种核心场景说明：

1. 新数据属于同一个未完成的Segment周期（当日内，Segment未被Finalize） #

如果首次Rollup完成后，你发送的新数据仍属于当天（时间维度和已聚合数据匹配），且负责实时摄入的任务（比如Kafka Indexing Service）还在运行、对应的当日Segment还没被"Finalize"（即还未正式提交到深层存储）：

• Druid的实时Rollup机制会在内存中维护当前的聚合状态，新进来的同维度数据会直接合并更新已有的聚合结果，不会生成独立的新聚合记录。
• 举个例子：你先发送10条user_id=1, action=click的数据，Rollup后得到user_id=1, action=click, count=10；之后再发5条相同维度的数据，实时任务会把count更新为15，最终写入Segment的是合并后的结果。

2. 新数据属于已Finalize的Segment周期（当日已结束，Segment已提交） #

一旦当天结束，对应的当日Segment会被Finalize并提交到深层存储，此时这个Segment就变成不可修改的了：

• 如果你之后再发送属于当天的同维度数据，Druid会创建一个新的Segment来存储这批数据的Rollup结果，不会修改已有的旧Segment。
• 当你查询当天的数据时，Druid会自动扫描所有属于该时间范围的Segment，将它们的聚合结果合并后返回，所以你最终拿到的还是正确的总和（比如旧Segment的count=15，新Segment的count=5，查询结果会是20）。

简单总结 #

• 同个未Finalize的Segment周期内：合并更新已有聚合值
• 已Finalize的Segment：生成新Segment追加，查询时自动合并

内容的提问来源于stack exchange，提问作者Explorer