Zarr-Python项目中v2版本组在RemoteStore中打开失败的问题分析

问题概述

在zarr-python项目中，当用户尝试使用标准open()函数打开存储在远程存储(RemoteStore)中的v2版本组时，会遇到打开失败的问题。这个问题特别出现在使用S3等远程存储后端时，而直接使用open_group()或open_consolidated()函数则可以正常工作。

技术背景

Zarr是一个用于分块、压缩、N维数组的存储格式，支持多种存储后端。在v2和v3版本中，Zarr的元数据存储方式有所不同。v2版本使用.zarray和.zgroup文件，而v3版本则使用zarr.json文件。

RemoteStore是Zarr提供的一种抽象，允许用户通过统一接口访问不同后端(如S3、GCS等)的存储。当使用open()函数时，Zarr会首先尝试以数组方式打开，如果失败再尝试以组方式打开。

问题根源

当前实现中存在两个关键问题：

1. 异常处理不完整：在异步API的open()函数中，当尝试以数组方式打开失败时，只捕获了KeyError和NodeTypeValidationError，而没有处理FileNotFoundError。这导致当路径指向一个v2组时，异常未被正确处理。

2. 元数据检查逻辑：v2和v3版本的元数据文件检查逻辑不一致，导致在RemoteStore中无法正确回退到组打开方式。

解决方案

开发团队已经提出了两种解决方案：

1. 短期修复：扩展异常处理逻辑，在open()函数中同时捕获FileNotFoundError异常。这样可以确保当数组打开失败时，能够正确回退到组打开方式。

2. 长期规划：统一元数据检查的异常类型，确保无论是v2还是v3版本，当元数据文件不存在时都抛出相同类型的异常。这将使代码更加一致和可靠。

影响与兼容性

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

• 使用v2格式存储的数据
• 存储在远程后端(S3等)的数据
• 使用标准open()函数而非特定组打开函数

值得注意的是，使用open_group()或open_consolidated()函数可以绕过这个问题，因为它们直接以组方式打开，不经过数组打开尝试。

最佳实践建议

在修复发布前，用户可以采取以下临时解决方案：

1. 明确使用open_group()函数代替open()函数
2. 使用open_consolidated()函数，如果数据使用了 consolidated 元数据
3. 对于新数据，考虑使用v3格式存储

开发团队已经在相关PR中修复了这个问题，用户可以在未来的版本中期待更稳定的行为。