Обзор Kedro: структура проекта и конвейер данных

Обзор Kedro: структура проекта и конвейер данных показывает фреймворк для организации Python-проектов обработки данных. Узлы описывают преобразования, конвейер связывает их по именам наборов, Data Catalog отвечает за загрузку и сохранение, а запуск идёт одной командой из корня проекта.

Для чего нужен Kedro

Kedro — открытый Python-фреймворк под лицензией Apache 2.0, который переносит практики программной инженерии на конвейеры данных и машинного обучения. В статье AWS Open Source Blog перечислены задачи, которые решает инструмент: стандартизация делает проекты понятнее и проще в обновлении, абстракция конвейера позволяет переиспользовать части, а встроенные практики помогают командам с разным опытом работать согласованно. Там же названа цель — быстрее переходить от эксперимента к продакшену.

Практический смысл для читателя: преобразования данных отделяются от кода загрузки. Функция считает строки и суммы, а откуда пришли данные и куда ушёл результат, решает конфигурация. Это разделение упрощает тесты и повторные запуски.

Структура проекта создаётся командой kedro new. Документация проекта описывает интерактивный поток: сначала запрашивается имя проекта, затем набор инструментов, затем решение о включении примера конвейера. Имя проекта задаёт значения project_name, repo_name и python_package; имена, чей производный пакет совпадает с ключевым словом Python или модулем стандартной библиотеки, отклоняются, чтобы избежать конфликтов импорта.

Инструменты выбираются по номерам или флагами. В списке документации: линтинг с ruff, тесты с pytest, расширенное логирование, документация Sphinx, структура папок для данных и конфигурация PySpark. Флаг --tools принимает имена через запятую, значения all или none.

Каркас проекта раскладывает файлы по назначению. В разборе AWS показана типовая раскладка: conf с подпапками base и local, data с уровнями от 01_raw до 08_reporting, docs, logs, notebooks и src с пакетом проекта, узлами, конвейерами и тестами. Такая раскладка задаёт место каждому артефакту.

Node и именованные входы

Узел — строительный блок конвейера, который представляет задачу. В документации проекта узел создаётся указанием функции, имён входных переменных и имён выходных переменных. Пример из документации: функция add(x, y) с двумя входами и одним выходом превращается в Node(func=add, inputs=["a", "b"], outputs="sum").

Имена входов и выходов обозначают наборы данных. Аргументы функции сопоставляются с ними при описании узла. Связь между ними задаёт синтаксис узла. Документация приводит таблицу: None означает отсутствие входа, строка 'a' — один вход, список ['a', 'b'] — несколько, словарь вида dict(arg1='x', arg2='y') — именованные входы. Для выходов действует та же логика: строка, список или словарь.

Узел можно пометить. Аргумент name даёт читаемую подпись в логах, аргумент tags позволяет запускать часть конвейера командой kedro run --tags=ds. Документация отмечает, что имена узлов и тегов содержат буквы, цифры, дефисы, подчёркивания и точки.

Запустить узел отдельно можно методом run, передав словарь значений: adder_node.run(dict(a=2, b=3)) вернёт {'sum': 5}. Тот же узел вызывается как обычная функция Python.

Отдельный случай — генераторные функции. Документация предупреждает: генераторные узлы не работают с асинхронной загрузкой и сохранением, при флаге --async Kedro поднимает ValueError. Декоратор над генератором обязан вернуть генератор без обхода; если декоратор вызывает list(), Kedro сохранит результат одним значением.

Для читателя важна проверяемая граница: узел получает данные по имени набора. Путь к файлу живёт в конфигурации каталога.

Pipeline и зависимости

Конвейер объединяет узлы в workflow. Зависимости выводятся из совпадения имён: если один узел объявляет выход paid_orders, а другой объявляет вход paid_orders, порядок устанавливается автоматически. Явное описание рёбер не требуется.

В примере AWS конвейер data_science собран из трёх узлов: split_data принимает master_table и parameters и отдаёт четыре набора, train_model принимает X_train и y_train и отдаёт regressor, evaluate_model принимает regressor, X_test и y_test и не имеет выходов. Такая запись читается как граф.

Теги можно ставить на весь конвейер. Если в определении Pipeline передан аргумент tags=, документация проекта сообщает, что Kedro прикрепит соответствующий тег к каждому узлу внутри конвейера. Запуск kedro run --tags=pipeline_tag выполнит узлы этого конвейера.

Проверка зависимостей полезна до запуска. Kedro-Viz строит интерактивное представление конвейера: узлы, зависимости, выходы и наборы данных. В разборе AWS визуализация запускается командой kedro viz и открывает локальный веб-сервер по адресу http://127.0.0.1:4141/. Документация проекта уточняет, что пакет kedro-viz ставится отдельно, а начиная с версии 12.0.0 доступен режим Workflow, который показывает, какие узлы завершились успешно, какие упали и какие пропущены в последнем запуске.

Граф показывает структуру связей. Правильность бизнес-определения суммы он не проверяет, поэтому арифметику стоит закрывать тестом.

Data Catalog и конфигурация

Data Catalog — реестр источников данных проекта. Он задаётся YAML-файлом, который сопоставляет имена входов и выходов узлов с ключами класса DataCatalog. Документация проекта описывает минимальную запись: имя набора, ключ type с классом набора и ключ filepath с расположением файла.

С версии 0.19.0 наборы данных вынесены из ядра Kedro в пакет kedro-datasets. С версии 2.0.0 этого пакета имена классов изменились: заглавная S в DataSet заменена на строчную s, поэтому CSVDataSet стал CSVDataset. Это объясняет расхождения между старыми руководствами и текущей документацией.

Расположение файла задаётся через fsspec. Документация проекта перечисляет поддерживаемые протоколы: file:// для локальной и сетевой файловой системы, hdfs:// для Hadoop, s3:// для Amazon S3 и совместимых хранилищ, gcs:// для Google Cloud Storage, abfs:// для Azure, а также http:// и https:// для чтения напрямую с веб-серверов. Без протокола подразумевается локальная файловая система.

Настройки набора делятся на группы. load_args и save_args передаются в стороннюю библиотеку: для pandas.ExcelDataset аргументы load_args уходят в pandas.read_excel. fs_args управляет работой с файловой системой. Ключ validator проверяет данные по схеме или правилу при каждой загрузке и сохранении.

Учётные данные хранятся отдельно. Документация проекта сообщает, что каталог читает их из credentials.yml, обычно в conf/local/, и передаёт в конструктор набора; запись в catalog.yml ссылается на блок по имени через ключ credentials.

Версионирование включается флагом versioned: True. Документация проекта описывает результат: filepath становится основой папки, каждая новая версия сохраняется по пути <filepath>/<version>/<filename>, где <version> — отметка времени в формате YYYY-MM-DDThh.mm.ss.sssZ. По умолчанию kedro run загружает последнюю версию. Набор поддерживает версионирование, если наследуется от kedro.io.AbstractVersionedDataset.

Окружения разделяются папками. Документация проекта описывает порядок: загрузчик конфигурации сканирует conf/base, затем conf/local как переопределяющее окружение, и объединяет результат. Практический приём — держать в conf/base/catalog.yml продакшен-расположения, а в conf/local/catalog.yml — пути к выборкам для прототипирования.

Учебный поток двух функций

Ниже — самостоятельный учебный пример. Вход условный: три заказа, из которых два оплачены. Ожидаемая сумма — 170.

from kedro.pipeline import node, Pipeline

orders = [
    {"id": 1, "amount": 100, "status": "paid"},
    {"id": 2, "amount": 40, "status": "refund"},
    {"id": 3, "amount": 70, "status": "paid"},
]


def paid_rows(orders):
    return [row for row in orders if row["status"] == "paid"]


def total_amount(paid):
    return sum(row["amount"] for row in paid)


def create_pipeline(**kwargs):
    return Pipeline(
        [
            node(func=paid_rows, inputs="orders", outputs="paid_orders"),
            node(func=total_amount, inputs="paid_orders", outputs="paid_total"),
        ]
    )


if __name__ == "__main__":
    paid = paid_rows(orders)
    assert [row["id"] for row in paid] == [1, 3]
    assert total_amount(paid) == 170

Разбор по шагам. Первая функция оставляет строки со статусом paid и возвращает два заказа с идентификаторами 1 и 3. Вторая функция складывает суммы и возвращает 170. Имена orders, paid_orders и paid_total — это имена наборов, которые связывают узлы в цепочку orders → paid_orders → paid_total.

Функции остаются чистыми: внутри нет обращений к сети и файлам. В полноценном проекте загрузка orders и сохранение paid_total настраиваются через Data Catalog. Приведённый скрипт проверяет функции напрямую и описывает граф; выполнение всего графа и файловый ввод-вывод в нём не запускаются.

Граница примера обозначена явно. Строка со статусом NULL не попадает в выборку оплаченных, потому что сравнение с paid даёт ложь. Если бизнес-правило требует другого поведения, условие меняется в одном месте — внутри paid_rows.

Локальный запуск и развёртывание

Создание проекта начинается с команды. Документация проекта приводит вариант uvx kedro new, который запускает Kedro в чистом временном окружении без установки в систему. Альтернатива — обычная установка в виртуальное окружение. Для потока kedro new требуется установленный Git.

Быстрый неинтерактивный запуск выглядит так: uvx kedro new --name=My-Project --tools=none --example=n. Документация проекта приводит и другие сочетания, например --tools=lint,docs,pyspark для проекта с линтингом, документацией и PySpark без примера кода.

После создания проекта нужно перейти в его папку и установить зависимости: uv pip install -r requirements.txt. Затем проект запускается командой kedro run. Документация проекта напоминает: команда требует хотя бы одного конвейера с узлами, зарегистрированного в pipeline_registry.py.

Визуализация ставится отдельно: uv pip install kedro-viz, запуск — kedro viz run. Браузер открывает вкладку с адресом http://127.0.0.1:4141/. Выход из визуализации — закрытие вкладки, возврат управления терминалом — сочетание Ctrl+C.

Развёртывание в облаке выходит за рамки учебного примера. В разборе AWS показано, как конвейер обучает модель на Amazon SageMaker: данные выкладываются в S3, добавляется окружение conf/sagemaker, обучение запускается командой kedro run --env sagemaker. Тот материал написан для Kedro 0.16.5 и Python 3.7 и использует устаревшие хуки, поэтому из него берут устройство потока, а команды установки сверяют с текущей документацией.

Сравнение двух подходов к запуску:

Границы инструмента

Kedro организует Python-проект. Он задаёт раскладку файлов, связывает узлы по именам наборов и выносит загрузку в конфигурацию. Планировщиком по умолчанию он не является: расписанием и оркестрацией занимаются внешние системы.

Data Catalog в Kedro — абстракция загрузки именованных наборов внутри проекта. Корпоративный каталог метаданных с происхождением и правами доступа решается отдельным классом задач.

Kedro-Viz показывает граф конвейера. Он не проверяет, верно ли определена бизнес-сумма, поэтому арифметику закрывают тестами.

Исторические интеграции требуют осторожности. Документация Neptune для Kedro размещена на домене docs-legacy и описывает завершённый пример подключения: плагин kedro-neptune, инициализация командой kedro neptune init, специальный вход neptune_run в узле и запись метрик в пространство имён kedro. Этот исторический материал показывает устройство интеграции. Доступность сервиса для нового проекта нужно проверять отдельно.

Выбор между инструментами стоит делать по задаче. Если нужна организация Python-кода с явными зависимостями между шагами и отдельной конфигурацией загрузки, Kedro закрывает эту потребность. Если требуется встроенное расписание, его ищут в другом слое.

Частые вопросы

Что такое kedro python?
Kedro — открытый Python-фреймворк под лицензией Apache 2.0 для организации конвейеров данных и машинного обучения. Он задаёт структуру проекта, связывает узлы по именам наборов и выносит загрузку данных в YAML-конфигурацию. Работает как библиотека внутри обычного Python-проекта.

Какую версию Python поддерживает kedro python version?
Документация проекта не фиксирует одну версию в разобранных материалах. Разбор AWS написан для Python 3.7 и Kedro 0.16.5, поэтому его команды установки устарели. Актуальные требования к версии Python стоит сверять в текущей документации и в файле зависимостей созданного проекта.

Работает ли kedro python 3.14?
Подтверждения для этой версии в разобранных материалах нет. Практический путь — создать проект командой kedro new и посмотреть, какие версии пакетов подтянутся в requirements.txt. Если установка зависимостей проходит, проект запускается командой kedro run.

Как выглядит kedro python example?
Минимальный пример — две функции и два узла. Первая оставляет оплаченные заказы, вторая складывает суммы. Узлы связываются именами orders, paid_orders и paid_total, а проверка результата укладывается в assert total_amount(paid) == 170.

Чем kedro framework python отличается от библиотеки?
Kedro поставляется как Python-пакет и используется как библиотека. Дополнительно он приносит командную строку kedro, каркас проекта и конвенции раскладки файлов. Наборы данных при этом живут в отдельном пакете kedro-datasets, начиная с версии 0.19.0.