技术问询：如何在Druid中处理随时间变化的行数据

嘿，我懂你现在的难处——Druid天生是为不可变的流式数据设计的，要处理这种会随其他交易动态变化的计算值，确实得绕开它的原生限制。结合物流交易的场景，我整理了几个实际项目里验证过的方案，你可以参考下：

Druid其实支持增量更新，不过它不是直接修改已有的行，而是通过提交带变更数据的增量流来覆盖旧值：

• 当交易A的计算值因为其他交易发生变化时，你只需要生成一条包含**相同主键（比如交易ID）**和新计算值的记录，用Delta Stream的方式摄入Druid。
• Druid会自动在查询阶段合并同一主键的最新记录，返回当前的最新计算值。
• 关键是要让你的数据源能精准追踪到哪些交易的计算值变了，只发送变更后的记录，别搞全量重导，不然性能会崩。

如果你的计算值是基于当月/当日的其他交易汇总而来（比如累计运费、订单优先级调整），这种方式会很省心：

• 配置一个滚动窗口任务（比如每小时跑一次），重新计算所有相关交易的最新值，然后把全量的最新结果用Overwrite模式重新摄入Druid，直接覆盖旧数据集。
• 这个方案的好处是实现简单，查询的时候不用处理复杂的增量合并，直接拿最新结果就行；缺点是如果数据量特别大，重导的开销会比较高，适合数据规模中等、实时性要求不是极致的场景。

要是变更特别频繁，或者计算逻辑复杂到Druid扛不住，咱们可以拆分存储：

• 把原始的、不会变的交易数据存在Druid里，把需要动态更新的计算值放在支持实时写的存储里（比如Redis、PostgreSQL），用交易ID当关联键。
• 查询的时候，先从Druid拉原始交易数据，再去外部存储取最新的计算值，组合成最终结果。
• 这种方式不破坏Druid的不可变特性，还能满足实时更新需求，就是得多维护一套存储，查询时多一步关联操作。

Druid的Lookup功能专门用来在查询时动态关联外部键值数据，刚好适配你的场景：

• 把交易ID和最新计算值维护成一个Lookup表（可以选JDBC Lookup或者Redis Lookup），确保这个表能实时同步变更。
• 查询的时候，用Druid的LOOKUP函数把交易ID映射成最新的计算值，每次查询都会拿到当前的最新结果。
• 这个方案比方案3轻量，不需要额外写关联逻辑，直接在Druid查询层就搞定了，适合实时性要求高、变更逻辑简单的场景。

最后提几个注意点： #

• 不管用哪种方案，交易ID的唯一性是核心，不然没法准确追踪和更新。
• 如果用增量更新，要注意Druid的Segment合并策略，别生成太多小Segment，会拖慢查询性能。
• 实时性要求极高选Lookup或外部存储关联；实时性一般、数据规模小选滚动重聚合；增量更新适合中等规模、变更频率适中的场景。

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