Kedro
Kedro
https://kedro.org/#why-kedro
https://github.com/kedro-org/kedro
Kedro is a toolbox for production-ready data engineering and data science pipelines. It uses software engineering best practices to help you create data engineering and data science pipelines that are reproducible, maintainable, and modular. You can find out more at kedro.org.
Kedro is an open-source Python framework hosted by the LF AI & Data Foundation.
| Feature | What is this? |
|---|---|
| Project Template | A standard, modifiable and easy-to-use project template based on Cookiecutter Data Science. |
| Data Catalog | A series of lightweight data connectors used to save and load data across many different file formats and file systems, including local and network file systems, cloud object stores, and HDFS. The Data Catalog also includes data and model versioning for file-based systems. |
| Pipeline Abstraction | Automatic resolution of dependencies between pure Python functions and data pipeline visualisation using Kedro-Viz. |
| Coding Standards | Test-driven development using pytest, produce well-documented code using Sphinx, create linted code with support for ruff and make use of the standard Python logging library. |
| Flexible Deployment | Deployment strategies that include single or distributed-machine deployment as well as additional support for deploying on Argo, Prefect, Kubeflow, AWS Batch, and Databricks. |
Kedro is built upon our collective best-practice (and mistakes) trying to deliver real-world ML applications that have vast amounts of raw unvetted data. We developed Kedro to achieve the following:
- To address the main shortcomings of Jupyter notebooks, one-off scripts, and glue-code because there is a focus on creating maintainable data engineering and data science code
- To enhance team collaboration when different team members have varied exposure to software engineering concepts
- To increase efficiency, because applied concepts like modularity and separation of concerns inspire the creation of reusable analytics code
Find out more about how Kedro can answer your use cases from the product FAQs on the Kedro website.
kedro如何解决notebook hell的？
“Notebook Hell（笔记本地狱）”是数据科学界的一个著名痛点，通常表现为：代码执行顺序混乱（随意跳跃执行 Cell）、全局变量泛滥、中间状态难以追踪、代码难以复用以及团队协作时环境不一致。
Kedro 通过一套严谨的软件工程架构，从根源上解决了这些问题。具体机制如下：
1. 强制代码模块化与无状态化（消除全局变量与顺序混乱）
在 Notebook 中，开发者经常依赖全局变量传递数据，且必须严格按照从上到下的顺序执行 Cell，一旦跳步就会导致报错。
Kedro 强制要求将探索性的代码重构为独立的、无状态的纯函数（Node 节点）。每个函数只接收显式的参数并返回结果，不依赖任何外部全局变量。随后，这些函数被组装成有向无环图（Pipeline 管道）。Kedro 的引擎会根据数据依赖关系自动解析出正确的执行拓扑，开发者完全不需要（也无法）手动控制执行顺序，彻底消除了“跳步执行”带来的隐患。
2. Data Catalog 实现关注点分离（消除硬编码路径）
Notebook 中常常充斥着大量的文件读写代码（如 pd.read_csv("../data/raw.csv")），导致业务逻辑与物理存储高度耦合。一旦更换环境或路径，需要修改大量代码。
Kedro 引入了 Data Catalog（数据目录），将所有数据的物理路径、格式和读写方式集中配置在 YAML 文件中。业务代码中只使用逻辑名称（如 raw_data）进行交互。这不仅让代码极其干净，还保证了代码在不同环境（本地、测试、生产）下的无缝切换。
3. 标准化的项目骨架（消除协作混乱）
Notebook 项目通常缺乏统一的目录结构，每个人的文件组织方式都不一样，接手他人的项目如同“考古”。
Kedro 通过脚手架工具（kedro new）强制生成了一套业界公认的最佳实践目录结构。它将代码（src/）、配置（conf/）、数据（data/）和测试（tests/）严格分层。这种强制性的工程规范，确保了无论团队规模多大，所有人都能在统一的契约下高效协作。
4. 极致的可重现性（Reproducibility）
Notebook 的输出（Out[1]）是易失的，且难以保证每次运行结果一致。
Kedro 实现了“代码 + 配置 + 数据”的三位一体管理。只要这三者保持不变，无论在谁的电脑上，Kedro 都能 100% 复现相同的数据处理结果和模型训练过程，彻底告别了“在我电脑上明明能跑”的尴尬局面。
5. 原生支持测试与 CI/CD（提升代码质量）
Notebook 中的代码极难进行单元测试。
Kedro 将数据处理逻辑剥离为标准 Python 包（Package），这使得开发者可以像开发传统后端软件一样，使用 pytest 等工具对每一个 Node 函数编写单元测试，并无缝接入 Git 和 CI/CD 流水线，保障了生产级代码的质量。
总结来说：
Kedro 并不是禁止使用 Notebook，而是将 Notebook 重新定位为**“探索与原型验证的工具”**。当实验验证成功后，Kedro 提供了一套标准化的“生产线”，将散乱的实验代码转化为模块化、可测试、可部署的工业级数据管道。
假设你正在处理一份包含原始订单数据的 CSV 文件，我们需要清洗数据并计算利润。
1. 强制代码模块化与无状态化
🚫 Notebook Hell 的痛点：
在 Notebook 中，你可能在一个 Cell 里读取数据，在另一个 Cell 里用全局变量 df 进行清洗，再在下一个 Cell 里计算利润。如果不小心漏执行了某个 Cell，或者变量名写错，整个流程就会崩溃，且极难排查。
✅ Kedro 的解法：
Kedro 强制将逻辑拆分为独立的纯函数（Node），它们只认输入参数，不依赖外部全局变量。
# 纯函数：只处理传入的数据，不关心数据从哪来
def clean_data(raw_orders):
return raw_orders.dropna(subset=['amount'])
def calculate_profit(clean_orders):
clean_orders['profit'] = clean_orders['amount'] - clean_orders['cost']
return clean_orders
# 组装成管道（Pipeline）：Kedro 会根据数据依赖自动决定执行顺序
pipeline = Pipeline([
node(clean_data, inputs="raw_orders", outputs="clean_orders"),
node(calculate_profit, inputs="clean_orders", outputs="profitable_orders"),
])
2. Data Catalog 实现关注点分离
🚫 Notebook Hell 的痛点：
你的 Notebook 里到处都是这样的硬编码：pd.read_csv("C:/Users/Admin/Desktop/2023_raw_orders.csv")
一旦文件换了路径，或者你要把代码部署到 Linux 服务器上，你需要挨个修改这些路径。
✅ Kedro 的解法：
物理路径全部写在 catalog.yml 配置文件中，代码里只写逻辑名称。
# catalog.yml
raw_orders:
type: pandas.CSVDataset
filepath: data/01_raw/2023_raw_orders.csv # 换环境只需改这里
profitable_orders:
type: pandas.ParquetDataset
filepath: data/03_primary/profitable_orders.parquet
# Python 代码中极其干净，只关心业务逻辑
def calculate_profit(clean_orders):
# 直接使用逻辑名称，Kedro 会自动从 Catalog 注入数据
clean_orders['profit'] = clean_orders['amount'] - clean_orders['cost']
return clean_orders
3. 标准化的项目骨架
🚫 Notebook Hell 的痛点：
同事发给你的项目文件夹里，混杂着 data.csv、model_v1.ipynb、utils.py、test.ipynb、temp.txt，你根本不知道哪个是主程序，哪个是测试数据。
✅ Kedro 的解法：
运行 kedro new 后，Kedro 会强制生成极其规范的目录结构：
my-project/
├── conf/ # 所有的 YAML 配置文件（参数、数据路径）
├── data/ # 原始数据、中间数据、输出数据严格分层
├── src/ # 纯 Python 业务代码（Nodes, Pipelines）
└── tests/ # 自动化测试代码
任何人接手这个项目，都能在一分钟内知道该去哪里改代码、去哪里改配置。
4. 极致的可重现性（Reproducibility）
🚫 Notebook Hell 的痛点：
三个月后，老板问你：“上个月那个利润报表是怎么算出来的？” 你打开旧的 Notebook，发现有些 Cell 的输出还在，有些被清空了，你完全不知道当时改了哪个参数才得出那个结果。
✅ Kedro 的解法：
在 Kedro 中，代码、数据路径、超参数（如利润率计算规则）是严格分离且版本化的。
# parameters.yml
tax_rate: 0.05
只要这三者（代码逻辑 + Catalog路径 + parameters.yml）被 Git 记录下来，无论过多久，运行 kedro run，Kedro 都能 100% 完美复现当时的计算结果。
5. 原生支持测试与 CI/CD
🚫 Notebook Hell 的痛点：
你修改了利润计算公式，但不知道有没有破坏其他逻辑。在 Notebook 里，你只能手动往下跑一遍看看有没有报错，极其低效且容易漏测。
✅ Kedro 的解法：
因为 Kedro 的 Node 都是标准的 Python 函数，你可以像写后端代码一样写单元测试：
# tests/test_nodes.py
import pandas as pd
from my_project.pipelines.sales.nodes import calculate_profit
def test_calculate_profit():
# 构造假数据
dummy_data = pd.DataFrame({"amount": [100], "cost": [80]})
result = calculate_profit(dummy_data)
# 断言结果是否正确
assert result["profit"].iloc[0] == 20
每次提交代码到 Git，CI/CD 流水线会自动运行这些测试，确保你的数据管道坚如磐石。
总结：
Kedro 并没有剥夺数据科学家探索数据的自由，它只是帮你把探索阶段（Notebook）验证成功的逻辑，用一套**工业级的流水线（Kedro）**固化了下来。
浙公网安备 33010602011771号