Apache Druid版本升级后查询性能下降问题分析与解决方案

问题背景

在将Apache Druid从22版本升级到27版本后，用户遇到了一个显著的查询性能退化问题。一个原本在5秒内完成的查询，在升级后执行时间延长至300秒以上。该查询针对一个包含20亿行数据的表，主要操作包括条件过滤、聚合计算和排序。

问题现象

查询SQL示例：

SELECT
  id,
  sum(val)/30 as l30d_ado
FROM mp
WHERE country = 'xx'
  AND (is_cross_border = 1 OR id IN (570092232, 664177432, ...))
  AND __time BETWEEN '2025-03-08 17:00:00' AND '2025-04-07 17:00:00'
GROUP BY id
ORDER BY l30d_ado DESC

关键发现：

1. 在22版本中，EXPLAIN显示使用了高效的IN过滤器
2. 在27版本中，EXPLAIN显示生成了大量BOUND过滤器
3. 数据类型显示差异：22版本显示为BIGINT，27版本显示为VARCHAR

根本原因分析

1. 数据类型合并策略变更

在22版本中，Druid采用"最新区间"策略确定列类型，即优先使用最新segment中的类型定义。而在27版本中，默认改为"最小限制"策略，当遇到类型冲突时（如STRING和LONG），会选择STRING类型。

这种变化源于27版本引入的新配置项druid.sql.planner.metadataColumnTypeMergePolicy，其默认值从latestInterval改为leastRestrictive。

2. 查询计划生成差异

在27版本中，由于列类型被识别为STRING，导致以下问题：

• IN条件无法被优化为高效的IN过滤器
• 生成了大量独立的BOUND过滤器
• 查询计划生成时间显著增加

具体来说，查询优化器在以下环节出现问题：

1. 无法将BOUND过滤器转换为SELECTOR过滤器
2. 进而无法将多个SELECTOR过滤器合并为IN过滤器

解决方案

临时解决方案

设置以下配置恢复22版本行为：

druid.sql.planner.metadataColumnTypeMergePolicy=latestInterval

长期建议

1. 统一数据类型定义：确保批处理和实时摄取任务使用一致的列类型定义
2. 升级到最新版本：32版本及以后对IN过滤器的处理有显著改进
3. 监控配置变更：关注版本升级说明中的"行为变更"部分

技术深度解析

查询优化器工作原理

Druid查询优化器在处理IN条件时经历多个阶段：

1. SQL解析阶段：识别IN操作符
2. 转换为BOUND过滤器
3. 尝试转换为SELECTOR过滤器
4. 合并多个SELECTOR过滤器为IN过滤器

在27版本中，由于类型系统变更，第3阶段的条件判断失败：

bound.getOrdering().equals(comparator)  // 返回false

因为bound使用数值比较器，而comparator基于STRING类型生成字符串比较器。

性能影响分析

大量BOUND过滤器导致：

1. 查询计划生成时间增加
2. 序列化/反序列化开销增大
3. 过滤计算效率降低

相比之下，IN过滤器可以：

1. 批量处理值列表
2. 使用更高效的查找结构
3. 减少网络传输量

最佳实践建议

1. 升级前测试：在测试环境验证关键查询性能
2. 审查数据类型：确保批处理和实时任务定义一致
3. 关注版本说明：特别注意标记为"行为变更"的更新
4. 查询优化：避免使用超长IN列表，考虑使用临时表或JOIN替代

总结

这次性能问题揭示了Druid类型系统和查询优化器之间的微妙交互。通过深入分析版本差异和内部机制，我们不仅找到了解决方案，也加深了对Druid查询处理流程的理解。对于使用Druid的企业，建立完善的升级测试流程和性能基准至关重要。

未来版本的Druid（32+）已经改进了数值IN过滤器的处理，建议用户在适当时候规划升级，以获得更好的查询性能。