Dagster项目性能回归问题分析与修复

背景介绍

在Dagster 1.10.13版本中，用户报告了一个严重的性能退化问题。与1.10.12版本相比，某些工作流的启动时间增加了4倍。这个问题主要影响那些在Definitions对象中加载多个UnresolvedAssetJob的场景。

问题根源

通过性能分析工具py-spy的跟踪，发现性能瓶颈出现在作业解析阶段。具体来说，当系统尝试解析UnresolvedAssetJob时，会调用UnresolvedAssetJob.resolve()方法，该方法会检查作业中所有资产的可执行性。

问题的核心在于BaseAssetGraph.executable_asset_keys()属性的缓存机制被移除了。在之前的版本中，这个属性会被缓存，但在1.10.13版本中，每次调用都会重新计算所有资产的可执行性状态。对于包含多个作业的系统，这导致了大量的重复计算。

技术细节

在资产图中，executable_asset_keys属性用于确定哪些资产可以被执行。这个检查涉及多个维度的验证：

1. 资产是否被标记为可执行
2. 资产是否满足所有依赖条件
3. 资产是否被其他约束条件限制

在1.10.12及之前版本，这个属性的计算结果会被缓存，避免重复计算。但在1.10.13版本中，由于一个内部重构(PR #29598)，这个缓存机制被意外移除了。

影响范围

这个问题主要影响以下场景：

• 包含大量UnresolvedAssetJob定义的项目
• 每个作业中包含大量资产的系统
• 频繁启动新工作流的应用场景

解决方案

Dagster维护团队已经确认了这个问题，并在最新提交中修复了这个问题。修复方案主要是恢复了executable_asset_keys属性的缓存机制，避免了重复计算。

最佳实践

为了避免类似问题，建议：

1. 在升级Dagster版本前，进行充分的性能测试
2. 对于关键路径上的操作，考虑添加自定义缓存机制
3. 使用性能分析工具定期监控系统关键路径

结论

这个案例展示了缓存机制在系统性能中的重要性。Dagster团队已经快速响应并修复了这个问题，预计将在下一个发布版本(1.10.14)中包含这个修复。对于受影响的用户，建议暂时回退到1.10.12版本，或者等待官方发布修复版本。