多次执行带GROUP BY的Druid查询结果不一致问题排查

问题背景 #

• 环境：Druid 25.0.0，基于Kafka进行实时数据摄入
• 表结构：my-tabla包含以下列：
  • __time: 映射自源数据时间戳
  • message: JSON格式字段
  • path: String类型字段
  • id: 标识字段
• 执行的查询语句：

SELECT COUNT(*) AS "Count", path
FROM "my-tabla"
GROUP BY (path)
ORDER by "Count" DESC

• 异常现象：多次查询计数波动，首次为11,256,000，第二次增至11,260,000（符合预期），第三次骤降至10,300,000
• 已调整的配置：
  • 前端查询选项：关闭Use cache、Use approximate TopN、Use approximate Count(Distinct)
  • Broker缓存配置：

    druid.broker.cache.useCache=false
    druid.broker.cache.populateCache=false
    druid.broker.cache.useResultLevelCache=false
    druid.broker.cache.populateResultLevelCache=false
    

可能导致计数波动的配置与机制原因 #

1. 实时Segment的合并与清理配置 #

Druid实时摄入任务会生成小粒度的实时Segment，满足条件时会触发后台合并，旧Segment也可能被清理。若查询未指定__time过滤条件：

• 合并过程中可能出现短暂的Segment不可见（取决于合并策略），导致漏统计数据
• 若配置了druid.coordinator.retention.period（Segment保留周期）、druid.coordinator.loadqueuepeon.loadTimeout（Segment加载超时）等，可能出现过期Segment被卸载、新合并Segment未及时加载的情况

相关检查点：

• 实时任务合并参数：druid.indexer.task.maxRowsPerSegment、druid.indexer.task.maxTotalRows、druid.indexer.task.partitionDimensions
• Coordinator的Segment保留与加载配置：druid.coordinator.retention.period、druid.coordinator.loadqueuepeon.loadTimeout

2. 查询的默认时间范围限制 #

若查询未显式指定__time过滤条件，Druid控制台默认会查询最近1小时的数据（具体取决于控制台默认设置）。如果源数据__time映射存在延迟、或Kafka摄入的时间戳有波动，不同查询时刻的时间窗口覆盖数据量会变化，导致计数波动。

检查点：

• 控制台查询界面的默认时间范围是否为动态窗口（如"最近1小时"），而非"所有时间"
• 确认__time字段的映射逻辑是否正确，是否存在数据时间戳跳变或延迟的情况

3. Kafka摄入任务的容错与重处理配置 #

Kafka消费过程中若出现重启、重平衡，或配置了druid.kafka.indexing.task.supervisor.recovery.pauseDuration等容错参数，可能引发Segment版本冲突：

• 摄入任务重启时可能生成重复Segment，后续合并过程中会基于时间范围和版本去重，导致计数突然下降
• 若未开启druid.kafka.indexing.task.supervisor.enableExactlyOnce，可能存在数据重复或丢失的情况

4. Broker的查询合并配置 #

即使关闭了缓存，Broker合并多Segment查询结果时，部分配置可能影响结果准确性：

• druid.broker.merge.useParallelMerge：并行合并配置不当可能导致部分Segment结果未被正确合并
• druid.broker.http.numConnections：连接数不足导致部分Historical节点的Segment查询超时，结果未被计入

5. Historical节点的Segment加载状态 #

Historical节点负责存储已完成的Segment，若节点故障、重启，或开启了自身缓存，可能导致部分Segment无法被查询：

• 检查Historical节点日志，是否存在Segment加载失败记录
• 确认druid.historical.cache.useCache是否关闭，避免旧计数结果干扰

排查建议 #

1. 给查询添加明确的__time过滤条件（如WHERE __time >= TIMESTAMP '2024-01-01 00:00:00'），排除动态时间窗口的影响
2. 查看Coordinator控制台的Segment列表，对比每次查询前后Segment的数量、时间范围、状态变化
3. 检查实时摄入任务日志，确认是否存在合并、重启、重平衡的记录
4. 执行SELECT MAX(__time), MIN(__time), COUNT(*) FROM "my-tabla"，对比整体计数变化，判断是单path计数异常还是整体数据量波动

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