Kedro 架构全景解析：项目、框架、库与扩展如何协同支撑生产级数据管线

Kedro 架构全景解析：项目、框架、库与扩展如何协同支撑生产级数据管线

【免费下载链接】kedroKedro is a toolbox for production-ready data science. It uses software engineering best practices to help you create data engineering and data science pipelines that are reproducible, maintainable, and modular.项目地址: https://gitcode.com/GitHub_Trending/ke/kedro

本篇文章以 docs/getting-started/architecture_overview.md 为核心骨架，结合本仓库源码（kedro/framework、kedro/io、kedro/pipeline、kedro/config 等）对 Kedro 的整体架构进行纵深解读。读完你将掌握：Kedro 的五大组成部分（项目、框架、Starter、库、扩展）各自承担什么职责、它们之间的边界与调用关系，以及如何根据自己的工作方式选择"全量采用、按需引入、二次扩展"三种用法。

三种使用 Kedro 的方式

从架构文档出发，Kedro 并没有强制要求你必须以某种固定方式使用它。根据工作流的不同，存在三种典型路径：

1. 端到端采用 Kedro：同时使用框架（framework）、项目模板（project）、Starter 与库（library）。这是收益最完整的路径——从项目脚手架、配置加载、Pipeline 建模到执行调度全部由 Kedro 提供，能够获得"可复现、可维护、模块化"的完整价值主张。
2. 按需引入 Kedro 组件：在既有代码库中仅导入DataCatalog（I/O）、OmegaConfigLoader、pipeline与runner等库组件，不采用 Kedro 项目模板。适合已有一套工程结构、只想借力 Kedro 数据抽象与管线能力的团队。
3. 为 Kedro 开发扩展：编写自定义 Starter、插件（plugin）、Hooks 或自定义库组件，反哺 Kedro 生态。

三种方式对应三种身份：Pipeline Developer（面向项目）、Library User（面向库组件）、Extension Developer（面向扩展）。

五大组成部分总览

架构文档给出了 Kedro 的顶层视图，可概括为五大模块：

• Kedro project：数据管线开发者日常交互的项目结构；
• Kedro framework：连接项目与库组件的框架层（Session、Context、Hooks、CLI）；
• Kedro starter：用于生成新项目脚手架的模板；
• Kedro library：独立可复用的核心库单元（ConfigLoader、Pipeline、Runner、I/O）；
• Kedro extension：对 Kedro 行为的扩展机制（自定义 Starter、Hooks、插件、自定义库组件）。

下文逐一拆解。

Kedro project：管线开发者的工作台

作为数据管线开发者，你打交道最多的是 Kedro 项目，它由以下核心部分组成。

conf/：项目配置目录

存放数据目录（catalog）配置与参数（parameters）等运行时配置，按环境（如base、local）分层组织。注意它与settings.py的区别：conf/中的是随环境变化的运行时配置，而settings.py中的是应用级设置。可参考 docs/configure/configuration_basics.md 了解配置基础。

src/：项目源码目录

• pipelines/：各条管线的源码。默认布局下，框架会通过find_pipelines自动发现src/<package>/pipelines/下暴露了create_pipeline函数的模块（见 kedro/framework/project/init.py 中的_create_pipeline与find_pipelines实现），并自动注册为命名管线。
• settings.py：项目应用设置，包括库组件注册与自定义 Hook 注册。所有可用设置项在 docs/tutorials/settings.md 中有完整清单与说明（详见下文"应用设置"小节）。默认情况下settings.py中全部代码处于注释状态，未提供时 Kedro 采用框架内置的合理默认值。
• pipeline_registry.py：定义可通过kedro run --pipelines运行的管线集合。从源码看，框架通过configure_project将pipelines对象指向f"{package_name}.pipeline_registry"模块，并在首次访问时惰性调用其中的register_pipelines()（见 kedro/framework/project/init.py 的_ProjectPipelines）。
• __main__.py：项目以"包模式"运行时的入口，对应 docs/deploy/package_a_project.md 所描述的打包部署方式。

pyproject.toml：项目根标识与元数据

pyproject.toml通过[tool.kedro]段标识项目根并提供项目元数据。标准模板（见 kedro/templates/project/cookiecutter.json 生成的默认文件）包含：

[tool.kedro] package_name = "package_name" project_name = "project_name" kedro_init_version = "kedro_version" tools = "" example_pipeline = "False" source_dir = "src"

• package_name：合法的 Python 包名，必须符合 Python 包命名规范；
• project_name：人类可读的项目名；
• kedro_init_version：生成项目时使用的 Kedro 版本，升级 Kedro 后应同步更新；
• source_dir：源码目录，默认为src。如需改用扁平布局（flat layout），可将其置为空字符串（source_dir = ""）。

应用设置一览

settings.py支持的设置项及默认值（摘自 docs/tutorials/settings.md）：

源码层面，这些设置由 kedro/framework/project/init.py 中的_ProjectSettings（基于 Dynaconf 的LazySettings）定义并附带校验规则，例如CONTEXT_CLASS必须是KedroContext的子类、CONFIG_LOADER_CLASS必须继承自AbstractConfigLoader、DATA_CATALOG_CLASS必须实现CatalogProtocol。值得注意的是CONFIG_LOADER_ARGS的默认值为{"base_env": "base", "default_run_env": "local"}，与 docs/configure/configuration_basics.md 中"base环境 +local运行环境"的约定一致。

Kedro framework：项目与库之间的接口层

框架层是项目与库组件之间的桥梁，其四个主要构件在源码中均有对应实现。

kedro.framework.session：管理一次 Kedro 运行的生命周期

kedro.framework.session 暴露了AbstractSession、KedroSession与KedroServiceSession。其中KedroSession（见 kedro/framework/session/session.py）是管理 Kedro run 生命周期的核心对象，负责创建 hook manager、注册 Hooks、构建 Context、执行 pipeline 并记录 session store。典型用法（来自其 docstring）：

from kedro.framework.session import KedroSession from kedro.framework.startup import bootstrap_project from pathlib import Path # 在 Kedro 项目之外创建 session 时，需要先 bootstrap_project bootstrap_project(Path("<project_root>")) with KedroSession.create() as session: session.run()

从AbstractSession（kedro/framework/session/abstract_session.py）的抽象方法可以看出，任何 Session 实现都必须提供create、close与run，并支持上下文管理器协议。

kedro.framework.context：持有配置与核心功能

kedro.framework.context 提供KedroContext、KedroContextError、CatalogCommandsMixin与compose_classes。KedroContext（见 kedro/framework/context/context.py）是"持有配置与 Kedro 主要功能、作为与核心库组件交互的入口"的基类，其关键属性包括：

• catalog：只读属性，基于catalog.yml（含模块化管线配置）构建 DataCatalog，加载前会通过_convert_paths_to_absolute_posix将配置中的相对路径转换为绝对路径；
• params：只读属性，返回parameters.yml中的参数，并结合运行时参数与管线节点类型注解进行参数校验与转换（通过kedro.validation.parameter_validator.ParameterValidator实现）。

从_get_catalog的实现可以看到catalog的构建链路：config_loader["catalog"]→ 路径绝对化 → 读取 credentials →DataCatalog.from_config(...)，且当catalog_class为默认DataCatalog时还会通过compose_classes混入CatalogCommandsMixin。

kedro.framework.hooks：定义扩展点

kedro.framework.hooks 定义了所有可用于扩展 Kedro 的 Hook 规范（specifications），包括节点前后、管线前后、数据集加载前后等执行阶段的钩子，详见 docs/extend/hooks/introduction.md。

kedro.framework.cli：内置命令与插件命令加载

kedro.framework.cli 定义内置 CLI 命令（如kedro run、kedro jupyter等）以及从插件加载自定义 CLI 命令的工具。CLI 入口实现见 kedro/framework/cli/cli.py。

框架层的装配流程

从 kedro/framework/project/init.py 的源码可以还原出框架装配主链路：

1. bootstrap_project定位项目根与包名；
2. configure_project(package_name)将settings指向<package>.settings、将pipelines指向<package>.pipeline_registry，并设置项目日志；
3. KedroSession.create()依据settings中的SESSION_CLASS、HOOKS、CONTEXT_CLASS、CONFIG_LOADER_CLASS、DATA_CATALOG_CLASS等设置装配 Session、Hook Manager 与 Context；
4. session.run()通过 Context 拿到 catalog 与 pipelines，交由 Runner 执行。

其中pipelines是惰性加载的（_ProjectPipelines），目的是加快 CLI 启动速度，并保证管线损坏时 CLI 其余功能（如kedro -h）仍可用。

Kedro starter：快速生成项目骨架

Starter 用于生成包含样板代码的 Kedro 项目。本仓库自带项目与管线两套模板：

• 项目模板：kedro/templates/project，包含cookiecutter.json（默认变量：project_name、repo_name、python_package、kedro_version、tools、example_pipeline）以及生成的目录骨架（conf/、data/、docs/、notebooks/、src/、tests/、pyproject.toml等）；
• 管线模板：kedro/templates/pipeline，提供nodes.py、pipeline.py、config/parameters_<pipeline_name>.yml、tests/test_pipeline.py等管线级样板。

除官方 Starter 外，你也可以使用自定义 Starter，相关机制可参考 docs/create/starters.md。

Kedro library：可独立复用的四大核心单元

Kedro 库由各自独立的单元组成，每个单元负责数据管线计算的一个方面：

• kedro.config.OmegaConfigLoader：解析并加载 Kedro 项目配置的工具。其实现位于 kedro/config/omegaconf_config.py，支持环境分层、模板化（templating）与凭证加载，详见 docs/configure。
• kedro.pipeline：建模数据管线的抽象集合，包括Node、Pipeline以及node构造器（见 kedro/pipeline/node.py 与 kedro/pipeline/pipeline.py）。
• kedro.runner：不同管线执行策略的抽象，默认提供SequentialRunner、ParallelRunner与ThreadRunner（见 kedro/runner 目录）。
• kedro.io：处理项目 I/O 的抽象集合，包括DataCatalog与多种Dataset实现（如MemoryDataset、CachedDataset、SharedMemoryDataset等，见 kedro/io 目录）。

这些单元设计为可独立导入，这正是"在既有代码库中按需引入 Kedro 组件"这一用法的支撑基础。

Kedro extension：扩展 Kedro 行为的四条路径

Kedro 扩展机制允许你以四种形态扩展框架行为：

1. 自定义 Starter：定制项目脚手架；
2. 带额外 Hook 实现的 Python 库：通过HOOKS设置注册自定义 Hook；
3. 额外 CLI 命令（插件）：例如可视化工具 Kedro-Viz 这类以插件形式提供的功能；Kedro 框架的 CLI 模块（kedro/framework/cli）提供了加载插件 CLI 命令的工具；
4. 自定义库组件实现：通过替换CONFIG_LOADER_CLASS、DATA_CATALOG_CLASS、SESSION_CLASS、CONTEXT_CLASS等设置，接入自定义的配置加载器、数据集目录或执行上下文。

其中"数据集（Dataset）"类贡献是最常被接受的类型，因为这类贡献通常只落在kedro.io抽象之上，无需改动框架本身。扩展开发的更多细节可参考 docs/extend/plugins.md 与 docs/extend/how_to_create_a_custom_dataset.md。

架构脉络小结

将上述五部分串起来，Kedro 的运行主线是：

Starter 生成项目骨架（conf/ + src/ + pyproject.toml） │ ▼ CLI/Session（kedro.framework.session）→ bootstrap_project + configure_project │ ▼ Context（kedro.framework.context）持有 config_loader、catalog、params │ ▼ Pipeline（kedro.pipeline）← Runner（kedro.runner）执行 ← DataCatalog（kedro.io）

• 若你端到端采用 Kedro，整套链路开箱即用；
• 若你只想要库组件，直接from kedro.io import DataCatalog、from kedro.pipeline import pipeline即可；
• 若你要扩展 Kedro，在settings.py注册 Hook、开发插件或替换库组件类即可，无需触碰框架内核。

架构文档还特别强调了对扩展贡献的开放态度：任何形式的 Kedro 扩展贡献都受欢迎，其中数据集类贡献最为常见，因为它们不需要修改框架本身。这也从侧面印证了 Kedro 将框架、库与项目解耦的设计意图——五个组成部分各自独立、边界清晰，组合起来则构成一套面向生产环境数据科学的完整工具箱。

【免费下载链接】kedroKedro is a toolbox for production-ready data science. It uses software engineering best practices to help you create data engineering and data science pipelines that are reproducible, maintainable, and modular.项目地址: https://gitcode.com/GitHub_Trending/ke/kedro