О чем: Управление бюджетом, запуск динамических Data Proc кластеров через Airflow и YAML-конфиги.

Когда компания переносит обработку данных в облако, первая серьезная проблема, с которой сталкивается бизнес, — это стремительно растущие счета за инфраструктуру. Держать постоянно запущенный кластер Yandex Data Proc (Apache Spark) ради пакетных (Batch) задач, которые запускаются несколько раз в сутки, — непозволительная роскошь.

В этой части мы разберем подход Cloud FinOps на практике: как с помощью Apache Airflow организовать полностью динамическое управление ресурсами, вынести переменные среды в декларативные YAML-конфигурации в S3 и платить только за чистое время вычислений.

Концепция Ephemeral-кластеров: Платим только за результат

Идея эфемерных (временных) кластеров проста: кластер создается оркестратором непосредственно перед выполнением тяжелой PySpark-задачи и гарантированно удаляется сразу после ее завершения.

В инфраструктуре Yandex Cloud этот процесс автоматизируется с помощью связки операторов в Apache Airflow DAG. Типичный жизненный цикл такой джобы выглядит так: 1. Инициализация: Специальный оператор (например, DataprocCreateClusterOperator) отправляет запрос к API Yandex Cloud на создание вычислительного кластера заданной конфигурации. 2. Выполнение: После того как воркеры поднялись, Airflow запускает DataprocCreatePysparkJobOperator, который передает исполняемый скрипт на кластер. 3. Уничтожение: Оператор DataprocDeleteClusterOperator освобождает ресурсы.

Архитектурный лайфхак: Гарантированное удаление ресурса

Самая частая ошибка новичков — кластер не удаляется, если шаг вычислений PySpark упал с ошибкой. В итоге «сирота» (Orphaned cluster) продолжает работать и жечь бюджет.

Чтобы этого избежать, в Airflow необходимо настраивать оператор удаления с триггером TriggerRule.ALL_DONE. Независимо от того, завершилась ли Spark-джоба успешно или упала по таймауту/OOM, Airflow в любом случае вызовет API-метод на удаление виртуальных машин.

Декларативный подход: Вынос инфраструктурных настроек в YAML

Хардкодить параметры кластера (количество воркеров, тип дисков, объемы RAM) внутри Python-кода DAG — плохой тон, затрудняющий разделение сред (Dev/Prod) и поддержку кода.

Мы реализовали декларативный подход: все конфигурации сред описываются в YAML-файлах и хранятся централизованно в изолированных бакетах Yandex Object Storage (S3).

Как это работает: - При старте DAG специальный легковесный шаг считывает нужный YAML-конфиг из S3 (используя boto3 или S3Hook). - Файл парсится, и его параметры динамически подставляются в конструктор оператора создания кластера

Вынос инфраструктурных настроек в YAML позволяет DevOps-инженерам или системным аналитикам изменять конфигурацию вычислительных мощностей (например, увеличивать количество хостов перед днями распродаж или тяжелым закрытием месяца), просто поправив файл в S3, без изменения и передеплоя самого кода Airflow.

Экономический эффект

Переход от постоянно активной инфраструктуры к модели Ephemeral-кластеров позволяет сократить затраты на облачные вычисления в 3–5 раз (в зависимости от частоты и длительности ваших пакетных окон). Платформа данных начинает потреблять ресурсы облака ровно тогда, когда данные реально обрабатываются, переводя фиксированные затраты в гибкие и контролируемые.

В финальной, четвертой части серии мы опустимся на уровень аналитики и CI/CD: настроим инкрементальный захват дельты данных из Gold-слоя с помощью dbt, построим быстрые витрины в ClickHouse.

GitHub проекта: https://github.com/VasinDK/spark_med_analytics