Apache DevLake中Grafana仪表板PR创建日期过滤问题分析

Apache DevLake作为一个开源的数据湖平台，在DORA指标分析方面提供了强大的功能。其中，Grafana仪表板中的"Lead Time for Changes"面板用于展示代码变更的交付周期指标，但在实际使用中发现了一个关于PR创建日期过滤的重要问题。

问题背景

在DevLake的Grafana仪表板中，"DORA Details - Lead Time for Changes"面板用于展示PR的平均交付周期指标。当用户选择7天或更短的时间范围时，系统无法正确计算和显示平均指标值，尽管PR详情列表中可以正常看到相关PR数据。

问题根源分析

通过深入排查，发现问题出在SQL查询中对PR创建日期的双重过滤条件上：

1. 第一个条件使用Grafana的标准时间过滤函数$__timeFilter(pr.created_date)，这个条件工作正常
2. 第二个条件使用了复杂的日期计算：created_date >= DATE_ADD(DATE_ADD($__timeFrom(), INTERVAL -DAY($__timeFrom())+1 DAY), INTERVAL +1 MONTH)

第二个条件的设计意图是确保只考虑从时间范围起始日期的下个月第一天开始的PR。然而，这种设计存在严重缺陷：

• 对于短时间范围（如7天内），它实际上将PR创建日期与未来的日期（下个月1号）进行比较
• 即使对于较长时间范围（1个月以上），计算结果也不准确
• 这种过滤逻辑与用户选择的时间范围意图不符

技术影响

这种错误的过滤条件会导致：

1. 短时间范围查询时，几乎所有PR都被排除在外，导致无法计算平均指标
2. 较长时间范围查询时，数据也不准确，因为过滤基准不正确
3. 用户体验下降，用户无法获得期望时间段内的准确指标

解决方案建议

针对这个问题，可以考虑以下解决方案：

1. 完全移除第二个过滤条件，仅保留标准的Grafana时间过滤
2. 如果确实需要保留某种形式的额外过滤，应该重新设计逻辑，确保它：
   • 与用户选择的时间范围一致
   • 不会产生未来日期的比较
   • 能够准确反映用户期望分析的时间段

最佳实践

在处理时间过滤时，建议：

1. 保持过滤逻辑简单直观，与用户界面选择的时间范围一致
2. 避免复杂的日期计算，除非有明确的业务需求
3. 对时间过滤条件进行充分测试，覆盖各种时间范围选择场景
4. 确保过滤逻辑不会意外排除有效数据

这个问题提醒我们在设计数据分析仪表板时，需要特别注意时间过滤逻辑的正确性，确保它能够真实反映用户选择的分析时间段，避免因过度设计而导致数据不准确或缺失。