Dask项目中xarray存储操作导致块级融合失效的问题分析

问题背景

在Dask项目的近期开发中，一个关于xarray数据存储操作的变更引入了一个潜在的性能回归问题。这个问题特别影响到当使用xarray的storeAPI且设置compute=False时的场景。

技术细节

在Dask的PR#11844之前，da.store函数会显式地对输入数组调用优化操作，这确保了无论后续操作如何，数组都会被优化。然而，变更后当compute=False时，xarray会将da.store的结果再次包装在一个延迟对象中，这实际上禁用了优化过程。

问题影响

这个变更会导致以下性能问题：

1. 当xarray用户使用to_zarr等存储方法并设置compute=False时
2. 块级融合(blockwise fusion)优化将被禁用
3. 计算图会包含更多不必要的中间任务
4. 整体计算效率会降低

解决方案分析

开发者提出了两种可能的解决方案路径：

1. 修改Dask的延迟接口，确保所有传递给延迟对象的集合都会调用优化操作

   • 这与Dask处理表达式(Expr)对象的方式一致
   • 保持了HLG(High Level Graph)对象处理的一致性

2. 在xarray上游进行修改，使其能够正确处理这种情况

测试验证

通过测试用例可以验证这个问题：

# 测试计算图是否按预期融合
def test_xarray_blockwise_fusion_store(compute):
    # 设置自定义调度器来验证任务数量
    coord = da.arange(8, chunks=-1)
    data = da.random.random((8, 8), chunks=-1) + 1
    x = xr.DataArray(data, coords={"x": coord, "y": coord}, dims=["x", "y"])
    
    y = ((x + 1) * 2) / 2 - 1  # 一系列操作应被融合
    
    # 验证存储操作
    with tmpdir() as dirname:
        if compute:
            y.to_zarr(dirname, compute=True)  # 直接计算
        else:
            stored = y.to_zarr(dirname, compute=False)
            dask.compute(stored)  # 延迟计算

技术影响评估

这个问题涉及到Dask的核心优化机制，特别是：

1. 任务图优化流程
2. 延迟计算与立即计算的差异
3. 与xarray等上层库的交互

结论

这个问题虽然尚未发布，但被标记为发布阻塞项，因为它会影响现有xarray用户的性能预期。开发团队正在考虑最合适的修复方案，既要在Dask层面保持一致性，又要确保与xarray等生态系统的兼容性。

对于Dask和xarray用户来说，了解这一潜在的性能变化很重要，特别是在使用存储操作且需要延迟计算时。在问题修复前，用户可以考虑暂时使用compute=True来避免性能下降。