Kedro项目中的数据目录重构：将默认数据集创建职责迁移至KedroDataCatalog

在数据工程领域，Kedro作为一个优秀的Python框架，其架构设计一直致力于保持组件间的低耦合性。近期社区针对Kedro运行器(runner)和数据目录(catalog)之间的职责划分进行了重要讨论，核心目标是将默认数据集创建逻辑从运行器迁移至KedroDataCatalog组件。这一变革将显著提升框架的模块化程度，使系统架构更加清晰。

现有架构的问题分析

在现有实现中，每个运行器类型（如SequentialRunner、ThreadRunner等）都各自维护着一套默认数据集模式(pattern)。这种设计导致：

1. 代码重复：相同的默认配置分散在各个运行器实现中
2. 紧耦合：运行器需要了解数据目录的内部工作机制
3. 维护困难：任何关于默认数据集的修改都需要同步更新所有运行器

更具体地说，当前实现会在运行器执行流程中临时修改数据目录配置——运行前添加内存数据集模式，执行后又移除这些模式。这种"魔术般"的行为不仅难以理解，也破坏了数据目录的封装性。

架构改进方案

新的设计方案将核心变更点放在以下几个方面：

1. 运行时模式的统一管理

引入专门的SharedMemoryDataCatalog类来统一管理运行时数据集模式，使用SharedMemoryDataset作为默认的运行时模式。这一改变使得：

• 同步管理器(SyncManager)的设置和数据集验证逻辑集中到数据目录中
• 会话(Session)根据所选运行器类型决定使用哪种数据目录实现
• 消除了运行器对MemoryDataset/SharedMemoryDataset的直接依赖

2. 并行运行器的简化

ParallelRunner的职责得到显著简化，现在它：

• 仅负责初始化同步管理器并通过数据目录进行配置
• 利用数据目录进行数据集验证
• 不再直接操作数据集对象

这种改进使得ParallelRunner的实现更接近ThreadRunner，提高了代码一致性。

3. 运行器输出格式标准化

AbstractRunner.run()方法现在统一返回所有管道输出的字典形式{"name": "datasets_object"}，但不立即加载实际数据。这一改变带来两个优势：

1. 简化了逻辑，使返回值不再依赖数据目录的状态
2. 适应了新模式解析机制，不再需要比较运行前后的目录差异

4. 模式解析机制重构

新的模式解析系统采用分层设计：

1. 数据集模式：来自配置文件(.yaml)的显式定义
2. 默认模式：用户设置的运行时默认模式
3. 运行时模式：由数据目录类型决定的固有模式

解析过程通过以下方法协作完成：

• contains：检查数据集是否在目录中或匹配任何模式
• match_pattern：匹配数据集名称与显式模式
• match_default_pattern：匹配默认和运行时模式
• resolve_pattern：综合所有模式解析出最终配置

架构改进的技术价值

这一系列重构为Kedro框架带来了显著的架构改进：

1. 关注点分离：数据目录完整封装了数据集管理职责，运行器只需关注执行逻辑
2. 可维护性提升：默认数据集配置集中管理，修改只需调整一处
3. 扩展性增强：新的模式解析机制为未来支持更多数据集类型奠定基础
4. 行为可预测性：消除了运行时的"魔术"修改，使系统行为更加透明

对使用者的影响

对于Kedro用户而言，这些底层架构的改进将带来更一致的开发体验：

1. 配置管理更加直观，不再需要理解运行器和目录间的隐含约定
2. 自定义运行器开发更简单，无需处理复杂的模式管理逻辑
3. 调试更便利，数据集生命周期管理完全由数据目录控制

这一重构体现了Kedro项目对软件设计原则的坚持，通过持续优化内部架构来为数据工程工作流提供更可靠的基础设施。随着这些改进的落地，Kedro在构建可维护、可扩展的数据管道方面将更进一步。