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

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

2025-05-22 22:11:29作者:盛欣凯Ernestine

在数据工程领域,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在构建可维护、可扩展的数据管道方面将更进一步。

登录后查看全文
热门项目推荐
相关项目推荐

项目优选

收起
kernelkernel
deepin linux kernel
C
23
6
docsdocs
OpenHarmony documentation | OpenHarmony开发者文档
Dockerfile
225
2.27 K
nop-entropynop-entropy
Nop Platform 2.0是基于可逆计算理论实现的采用面向语言编程范式的新一代低代码开发平台,包含基于全新原理从零开始研发的GraphQL引擎、ORM引擎、工作流引擎、报表引擎、规则引擎、批处理引引擎等完整设计。nop-entropy是它的后端部分,采用java语言实现,可选择集成Spring框架或者Quarkus框架。中小企业可以免费商用
Java
9
1
flutter_flutterflutter_flutter
暂无简介
Dart
526
116
RuoYi-Vue3RuoYi-Vue3
🎉 (RuoYi)官方仓库 基于SpringBoot,Spring Security,JWT,Vue3 & Vite、Element Plus 的前后端分离权限管理系统
Vue
987
583
Cangjie-ExamplesCangjie-Examples
本仓将收集和展示高质量的仓颉示例代码,欢迎大家投稿,让全世界看到您的妙趣设计,也让更多人通过您的编码理解和喜爱仓颉语言。
Cangjie
351
1.42 K
leetcodeleetcode
🔥LeetCode solutions in any programming language | 多种编程语言实现 LeetCode、《剑指 Offer(第 2 版)》、《程序员面试金典(第 6 版)》题解
Java
61
17
GLM-4.6GLM-4.6
GLM-4.6在GLM-4.5基础上全面升级:200K超长上下文窗口支持复杂任务,代码性能大幅提升,前端页面生成更优。推理能力增强且支持工具调用,智能体表现更出色,写作风格更贴合人类偏好。八项公开基准测试显示其全面超越GLM-4.5,比肩DeepSeek-V3.1-Terminus等国内外领先模型。【此简介由AI生成】
Jinja
47
0
giteagitea
喝着茶写代码!最易用的自托管一站式代码托管平台,包含Git托管,代码审查,团队协作,软件包和CI/CD。
Go
17
0
ohos_react_nativeohos_react_native
React Native鸿蒙化仓库
JavaScript
212
287