ПОЛНЫЙ СТЕК 7-ШАГОВ MLOPS FRAMEWORK

Разблокировка MLOps с помощью Airflow: подробное руководство по оркестровке системы машинного обучения

Урок 4: Частный сервер PyPi. Организуйте все с помощью Airflow.

Этот учебник представляет собой урок 4 из курса из 7 уроков, который шаг за шагом проведет вас через проектирование, реализацию и развертывание системы машинного обучения с помощью >Передовой опыт MLOps. В ходе курса вы создадите готовую к производству модель для прогнозирования уровней энергопотребления на следующие 24 часа для различных типов потребителей из Дании.

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

Этот курс предназначен инженерам машинного обучения среднего/продвинутого уровня, которые хотят повысить уровень своих навыков, создавая собственные комплексные проекты.

Сегодня сертификаты повсюду. Создание продвинутых комплексных проектов, которыми вы сможете потом хвастаться, — лучший способ добиться признания в качестве профессионального инженера.

Оглавление:

  • Введение в курс
  • Уроки курса
  • Источник данных
  • Урок 4: Частный сервер PyPi. Организуйте все с помощью Airflow.
  • Урок 4: Код
  • Заключение
  • Рекомендации

Введение в курс

По окончании этого курса из 7 уроков вы будете знать, как:

  • разработать архитектуру пакетного обслуживания
  • использовать Hopsworks в качестве хранилища функций
  • разработать конвейер разработки функций, который считывает данные из API
  • построить обучающий конвейер с настройкой гиперпараметров
  • используйте W&B в качестве платформы машинного обучения для отслеживания ваших экспериментов, моделей и метаданных
  • реализовать конвейер пакетного предсказания
  • используйте Poetry для создания собственных пакетов Python
  • разверните свой собственный частный сервер PyPi
  • организуйте все с помощью Airflow
  • использовать прогнозы для кодирования веб-приложения с использованием FastAPI и Streamlit
  • используйте Docker для контейнеризации вашего кода
  • использовать Большие надежды для обеспечения проверки и целостности данных
  • следить за эффективностью прогнозов с течением времени
  • развернуть все в GCP
  • построить конвейер CI/CD с помощью GitHub Actions

Если это звучит как много, не волнуйтесь. После того, как вы пройдете этот курс, вы поймете все, что я сказал ранее. Самое главное, вы будете знать, ПОЧЕМУ я использовал все эти инструменты и как они работают вместе как система.

Если вы хотите получить максимальную отдачу от этого курса, я предлагаю вам получить доступ к репозиторию GitHub, содержащему весь код уроков. Этот курс предназначен для быстрого чтения и воспроизведения кода в статьях.

К концу курса вы будете знать, как реализовать приведенную ниже схему. Не волнуйтесь, если что-то не имеет для вас смысла. Я объясню все подробно.

К концу урока 4 вы будете знать, как разместить свой репозиторий PiPy и организовать три конвейера с помощью Airflow. Вы узнаете, как планировать конвейеры для создания почасовых прогнозов.

Уроки курса:

  1. Пакетное обслуживание. Магазины функций. Особенности проектирования трубопроводов.
  2. Обучающие пайплайны. Платформы машинного обучения. Настройка гиперпараметров.
  3. Конвейер пакетного прогнозирования. Упакуйте модули Python с поэзией.
  4. Частный сервер PyPi. Организуйте все с помощью Airflow.
  5. Создайте собственное приложение с помощью FastAPI и Streamlit.
  6. Проверка данных и целостность с использованием GE. Мониторинг производительности модели.
  7. Разверните все в GCP. Создайте конвейер CI/CD с помощью GitHub Actions.

Если вы хотите полностью понять этот урок, мы рекомендуем вам ознакомиться с Уроком 1, Уроком 2 и Уроком 3, в которых подробно объясняется реализация конвейеров, которые вы будете организовывать в этой статье:

  1. Конвейер разработки функций
  2. Учебный пайплайн
  3. Конвейер пакетного прогнозирования

Источник данных

Мы использовали бесплатный и открытый API, который предоставляет значения почасового потребления энергии для всех типов потребителей энергии в Дании [1].

Они предоставляют интуитивно понятный интерфейс, в котором вы можете легко запрашивать и визуализировать данные. Вы можете получить доступ к данным здесь [1].

Данные имеют 4 основных атрибута:

  • Час UTC: дата и время в формате UTC, когда наблюдалась точка данных.
  • Ценовая зона. Дания разделена на две ценовые зоны: DK1 и DK2, разделенные Большим поясом. DK1 находится к западу от Большого пояса, а DK2 — к востоку от Большого пояса.
  • Тип потребителя. Тип потребителя — промышленный код DE35, принадлежащий и поддерживаемый Danish Energy.
  • Общее потребление: общее потребление электроэнергии в кВтч.

Примечание. Наблюдения запаздывают на 15 дней! Но для нашего демонстрационного варианта использования это не проблема, поскольку мы можем моделировать те же шаги, что и в реальном времени.

Точки данных имеют почасовое разрешение. Например: 2023–04–15 21:00 по Гринвичу, 2023–04–15 20:00 по Гринвичу, 2023–04–15 19:00 по Гринвичу и т. д.

Мы будем моделировать данные как несколько временных рядов. Каждый уникальный кортеж ценовой области и типа потребителя представляет свой уникальный временной ряд.

Таким образом, мы построим модель, которая независимо прогнозирует потребление энергии на ближайшие 24 часа для каждого временного ряда.

Посмотрите нашу демо-версию, чтобы лучше понять, как выглядят данные.

Урок 4:

Цель урока 4

Этот урок научит вас, как использовать Airflow для управления тремя конвейерами, которые вы уже реализовали.

Кроме того, чтобы запустить код внутри Airflow, вы научитесь размещать свой репозиторий PiPy и развертывать конвейеры как 3 разных модуля Python. Позже вы установите свои модули внутри Airflow прямо из своего репозитория PiPy.

Организовав все с помощью Airflow, вы автоматизируете весь процесс. Вместо того, чтобы вручную запускать 10 разных скриптов, вы один раз нажмете кнопку «Выполнить», чтобы запустить весь код.

Кроме того, соединение всех шагов вместе программным способом менее подвержено ошибкам.

Почему?

Потому что каждому скрипту нужны свои настройки. Например, для конвейера пакетного прогнозирования в качестве входных данных требуется версия представления объекта (версия данных) и версия модели.

Эта информация генерируется как метаданные из предыдущих сценариев. Когда вы запускаете все вручную, вы можете легко скопировать не ту версию. Но когда вы заворачиваете все в один DAG, вам нужно собрать его один раз, и после этого он будет работать все время.

Кроме того, с помощью Airflow вы можете:

  • запланируйте периодический запуск конвейера (вы будете запускать его каждый час);
  • настроить весь процесс с помощью переменных воздушного потока;
  • отслеживать журналы каждой задачи.

Вот обзор того, что вы будете строить в Airflow 👇

Теоретические концепции и инструменты

Airflow.Airflow — один изсамых популярных инструментов оркестровки. Проект был разработан в Airbnb, но теперь он имеет открытый исходный код под лицензией Apache. Это означает, что вы можете изменять и размещать его самостоятельно бесплатно. Airflow позволяет создавать, планировать и отслеживать DAG.

DAG (направленный ациклический граф):DAG — это граф без петель, что означает, что логический поток может идти только в одном направлении.

Реестр PyPi.Реестр PiPy — это сервер, на котором можно размещать различные модули Python. Когда вы запускаете «pip install ‹your_package›», pip знает, как просмотреть официальный репозиторий PyPi для вашего пакета и установить его. Хостинг собственного реестра PyPi будет вести себя точно так же, но вы должны настроить pip, чтобы узнать, как получить к нему доступ. Только люди, имеющие доступ к вашему серверу PyPi, могут устанавливать с него пакеты.

Урок 4: Код

Вы можете получить доступ к репозиторию GitHub здесь.

Примечание. Все инструкции по установке находятся в файлах README репозитория. Здесь вы перейдете прямо к коду.

Весь код урока 4 находится в папке airflow.

Файлы в папке airflow имеют следующую структуру:

Весь код находится в папке dags. Каждая группа DAG будет иметь собственный файл Python.

Файлы Docker помогут вам быстро разместить Airflow и репозиторий PiPy. Я объясню их подробно позже.

Непосредственное хранение учетных данных в вашем репозитории git представляет собой огромный риск для безопасности. Вот почему вы будете вводить конфиденциальную информацию, используя файл .env.

.env.default является примером всех переменных, которые необходимо настроить. Также полезно хранить значения по умолчанию для атрибутов, которые не являются конфиденциальными (например, имя проекта).

Подготовьте учетные данные

Поскольку в Уроке 4 рассказывается об оркестровке кода из всех других уроков, если вы хотите воспроизвести код, вам нужно проверить, как настроить 3 конвейера из Урока 1, Урока 2 и Урока 3.

Эти три урока покажут вам, как настроить все необходимые инструменты и сервисы. Кроме того, он покажет вам, как создать и заполнить необходимый файл .env, содержащий все учетные данные.

Единственное, с чем нужно быть осторожным, это👇

На этот раз вам нужно поместить файл .env, содержащий ваши учетные данные, в папку airflow/dags.

Мы установили значение по умолчанию /opt/airflow/dags для переменной среды ML_PIPELINE_ROOT_DIR в файле docker-compose.yaml. Таким образом, при запуске конвейеров внутри Airflow он будет знать, что файл .env загружается из /opt/airflow/dags по умолчанию.

Также обратите внимание, что в папке /airflow есть еще один файл .env. Этот не содержит ваших пользовательских учетных данных, но Airflow нуждается в некоторых пользовательских конфигурациях. Вот так это выглядит 👇

Я объяснил, как заполнить этот файл .env в README.md репозитория. Но в качестве примечания, AIRFLOW_UID представляет собой USER ID вашего компьютера, и вы знаете, что такое ML_PIPELINE_ROOT_DIR.

Я просто хотел показать вам, что здесь вы можете переопределить значение по умолчанию для ML_PIPELINE_ROOT_DIR. Обратите внимание, что этот путь будет использоваться внутри контейнера Docker, поэтому путь начинается с /opt/.

# Move to the airflow directory.
cd airflow

# Make expected directories and environment variables
mkdir -p ./logs ./plugins
sudo chmod 777 ./logs ./plugins

# It will be used by Airflow to identify your user.
echo -e "AIRFLOW_UID=$(id -u)" > .env
# This shows where the project root directory is located.
echo "ML_PIPELINE_ROOT_DIR=/opt/airflow/dags" >> .env

Настроить частный сервер PyPi

Вы можете легко разместить сервер PiPy, используя этот репозиторий. Но позвольте мне объяснить, как мы сделали это в нашей установке.

Первый шаг — создать набор учетных данных, которые вам понадобятся для подключения к серверу PyPi.

# Install dependencies.
sudo apt install -y apache2-utils
pip install passlib

# Create the credentials under the energy-forecasting name.
mkdir ~/.htpasswd
htpasswd -sc ~/.htpasswd/htpasswd.txt energy-forecasting

Репозиторий PyPi будет знать, что нужно загрузить учетные данные из файла ~/.htpasswd/htpasswd.txt.

Теперь вы добавите новый частный репозиторий PyPi в Poetry. Чтобы настроить Poetry, вам нужно указать URL-адрес сервера, имя сервера, а также имя пользователя и пароль для аутентификации (это те, которые вы настроили одним шагом ранее):

poetry config repositories.my-pypi http://localhost
poetry config http-basic.my-pypi energy-forecasting <password>

В нашем примере:

  • имя сервера: my-pypy
  • URL: http://localhost
  • имя пользователя: прогнозирование энергопотребления
  • пароль: ‹пароль›

Проверьте, правильно ли указаны ваши учетные данные в файле Poetry auth.toml :

cat ~/.config/pypoetry/auth.toml

Итак, вы закончили подготовку имени пользователя и пароля, которые будут загружены вашим репозиторием PyPi для аутентификации. Кроме того, вы настроили Poetry, чтобы он знал о вашем сервере PyPi.

Теперь давайте посмотрим, как запустить сервер PyPi.

Код pyserver, который вы будете использовать, уже докеризован.

Для упрощения мы добавили сервер PyPi в качестве дополнительной службы в файл docker-compose.yaml, который запускает приложение Airflow.

Чтобы лучше понять файл docker-compose.yaml, ознакомьтесь с официальной документацией Airflow [2] и нашим README.md. Но будьте осторожны, используя файл docker-compose.yaml из нашего репозитория, так как мы изменили исходный файл, как вы увидите ниже.

Прокрутите вниз файл airflow/docker-compose.yaml, и вы увидите:

  my-private-pypi:
    image: pypiserver/pypiserver:latest
    restart: always
    ports:
      - "80:8080"
    volumes:
      - ~/.htpasswd:/data/.htpasswd
    command:
      - run
      - -P
      - .htpasswd/htpasswd.txt
      - --overwrite

Этот код использует последнее изображение сервера PyPi, предоставляет доступ к серверу через порт 80, загружает папку ~/.htpasswd, содержащую ваши учетные данные, как том и запускает сервер с помощью следующей команды:

run -P .htpasswd/htpasswd.txt --overwrite
  • -P .htpasswd/htpasswd.txt явно сообщает серверу, какие учетные данные использовать.
  • — перезапись указывает, что если будет развернут новый модуль той же версии, он перезапишет последний.

Вот и все! Когда вы запускаете приложение Airflow, вы автоматически запускаете сервер PyPi.

Примечание. В производственной среде вы, скорее всего, разместите сервер PyPi на сервере, отличном от сервера Airflow. Шаги идентичны, за исключением добавления всего в один файл docker-compose.yaml. В этом уроке мы хотели, чтобы все было легко запускать.

Настроить файл Docker Airflow

Так как вам нужно запускать весь код в Python 3.9, вы должны унаследовать образ по умолчанию apache/airflow:2.5.2Airflow Docker и добавить некоторые дополнительные зависимости.

Вот что происходит в файле Docker ниже:

  • наследовать apache/airflow:2.5.2
  • переключитесь на пользователя root для установки системных зависимостей
  • установить зависимости Python 3.9, необходимые для установки пакетов с частного сервера PyPi
  • вернуться к пользователю по умолчанию

Потому что мы перешли:

x-airflow-common:
  &airflow-common
  image: ${AIRFLOW_IMAGE_NAME:-apache/airflow:2.5.2}

To:

version: '3.8'
x-airflow-common:
  &airflow-common
#  image: ${AIRFLOW_IMAGE_NAME:-apache/airflow:2.5.2}
  build: .

Docker будет знать, что нужно использовать ваш собственный образ вместо apache/airflow:2.5.2 при запуске docker-compose.

Запустить воздушный поток

Теперь, когда вы понимаете, как подготовить учетные данные и как работают файлы Docker, перейдите в каталог ./airflow и запустите:

# Go to the ./airflow directory.
cd ./airflow

# Initialize the Airflow database
docker compose up airflow-init

# Start up all services
# Note: You should set up the private PyPi server credentials before running this command.
docker compose --env-file .env up --build -d

Дополнительную информацию см. в разделе Использование репозитория GitHub.

После завершения настройки Airflow вы можете получить доступ к Airflow по адресу 127.0.0.1:8080 с учетными данными по умолчанию:

  • имя пользователя: воздушный поток
  • пароль: поток воздуха

Развертывание модулей на частном сервере PyPi

Помните, что вы добавили в Poetry свой новый сервер PyPi, используя следующие команды:

poetry config repositories.my-pypi http://localhost
poetry config http-basic.my-pypi energy-forecasting <password>

Теперь, используя my-pypi в качестве идентификатора, вы можете быстро отправлять новые пакеты в свой репозиторий PyPi.

Используя сценарий оболочки deploy/ml-pipeline.sh, вы можете собрать и развернуть все 3 конвейера, используя исключительно Poetry:

!/bin/bash

# Build and publish the feature-pipeline, training-pipeline, and batch-prediction-pipeline packages.
# This is done so that the pipelines can be run from the CLI.
# The pipelines are executed in the feature-pipeline, training-pipeline, and batch-prediction-pipeline
# directories, so we must change directories before building and publishing the packages.
# The my-pypi repository must be defined in the project's poetry.toml file.

cd feature-pipeline
poetry build
poetry publish -r my-pypi

cd ../training-pipeline
poetry build
poetry publish -r my-pypi

cd ../batch-prediction-pipeline
poetry build
poetry publish -r my-pypi

Как видите, мы итеративно заходим в папки 3-х пайплайнов и запускаем:

poetry build
poetry publish -r my-pypi

Poetry использует эти две команды для поиска файлов pyproject.toml и poetry.lock внутри папок и знает, как собрать пакет.

Затем, на основе сгенерированного файла wheel, запустив 'poetry publish -r my-pypi',вы отправляете егов свой my -pipy репозиторий.

Помните, что вы пометили свой сервер PyPi как my-pipy.

Вы сделали. У вас есть собственный репозиторий PyPi.

В следующих разделах я покажу вам, как устанавливать пакеты из вашего частного репозитория PyPi.

Примечание. Вы использовали Poetry только для создания и развертывания модулей. Airflow будет использовать pip для их установки из вашего репозитория PiPy.

Определить объект DAG

Ваш даг определяется в файле airflow/dags/ml_pipeline_dag.py.

Используя API Airflow 2.0, вы можете определить DAG с помощью декоратора dag()Python.

Ваш даг будет определен внутри функции ml_pipeline(), которая вызывается в конце файла. Кроме того, Airflow знает, что нужно загружать все DAG, определенные в каталоге airflow/dags.

DAG обладает следующими свойствами:

  • dag_id: идентификатор группы обеспечения доступности баз данных.
  • расписание:оноопределяет, как часто запускается группа обеспечения доступности баз данных.
  • start_date:когда должна начать работу группа обеспечения доступности баз данных в соответствии с заданным расписанием.
  • наверстывание:автоматическое заполнение между [дата_начала, настоящее время]
  • теги:теги 😄
  • max_active_runs:сколько экземпляров этой DAG может работать параллельно.

Определите задачи

Приведенный ниже код может показаться длинным, но вы легко сможете его прочитать, как только поймете основные идеи.

Внутри DAG вы определили несколько задач. Задача — это отдельная логическая единица/шаг, выполняющая определенную операцию.

Задачи определяются аналогично DAG: функция + декоратор. У каждой задачи есть своя функция и декоратор.

Примечание. Это простое напоминание о том, что мы использовали API для Airflow 2.0, а не 1.0.

В нашем случае задача будет представлять собой сценарий основного конвейера. Например, конвейер разработки функций будет выполняться внутри одной задачи.

Вы будете использовать DAG для объединения всех ваших скриптов в одну программу, где каждый скрипт имеет представление 1:1 с задачей.

Как вы можете видеть внутри каждой задачи, вы просто импортируете и вызываете функцию из ее собственного модуля… и, возможно, добавляете какие-то дополнительные журналы.

Ключевым шагом в определении задачи являются аргументы декоратора Python task.virtualenv().

Для каждой задачи этот конкретный декоратор создаст другую виртуальную среду Python, внутри которой будут установлены все заданные требования.

Примечание. 172.17.0.1 — это IP-адрес вашего частного репозитория PyPi. Помните, что вы размещаете свой репозиторий PyPi с помощью docker-compose в той же сети, что и Airflow. 172.17.0.1 — это IP-адрес моста, доступный для каждого контейнера Docker в по умолчанию сети Docker. Таким образом, контейнер Airflow может получить доступ к контейнеру сервера PyPi, используя IP-адрес моста.

Как видно из аргумента requirements, мы определили следующее:

  • '— trust-host 172.17.0.1': поскольку сервер PyPi не защищен с помощью HTTPS, вы должны явно указать, что доверяете этому источнику.
  • '— extra-index-url http://172.17.0.1': скажите Pip, чтобы он также обращался к этому репозиторию PyPi при поиске пакета Python. Обратите внимание, что Pip по-прежнему будет искать в официальном репозитории PyPi в дополнение к вашему.
  • '‹your_python_packages›': после двух строк, описанных выше, вы можете добавить любой пакет Python. Но обратите внимание, что вы установили feature_pipeline, training_pipeline и batch_prediction_pipelineкакпакеты Python, созданные и развернутые с помощью Poetry.

Другие аргументы не так интересны, но позвольте мне объяснить их:

  • task_id=' ‹task_id›':уникальный идентификатор задачи.
  • python_version=' 3.9': Когда я писал этот курс, Hopsworks работал только с Python 3.9, поэтому нам пришлось применить эту версию Python.
  • multiple_outputs=True: задача возвращает словарь Python.
  • system_site_packages=True:установить системные пакеты по умолчанию.

Важно

Обратите внимание,что почти каждая задача возвращает словарь метаданных, который содержит такую ​​информацию, как:

  • диапазон дат, когда были извлечены данные,
  • версия группы функций, представление функций и т. д.
  • версия развертки,
  • версия модели и т.д.

Эта информация необходима для передачи между задачами. Например, задача create_feature_view должна знать, какую версию feature_group использовать для создания следующего представления функций. Кроме того, при запуске batch_predict необходимо знать версию представления функций и модели, которые следует использовать для создания прогнозов.

Одной интересной задачей является task.branch(task_id=' if_run_hyperparameter_tuning_branching'), которая определяет логику if-else между тем, следует ли запускать логику настройки гиперпараметров или нет.

Этот особый тип задачи возвращает список task_id, которые будут выполняться следующими. Например, если он возвращает ['branch_run_hyperparameter_tuning'], будет запущена только задача с task_id = branch_run_hyperparameter_tuning.

Как вы можете видеть ниже, два пустых оператора (задачи) определены с идентификаторами задач, используемыми внутри логики task.branch(). Airflow предлагает распространенный шаблон для использования набора пустых операторов (без операции) при выборе между несколькими ветвями.

Соедините задачи в DAG

Теперь, когда вы определили все задачи, последний шаг — соединить их в DAG. Вы должны выполнить этот шаг, чтобы Airflow знал, в каком порядке запускать каждую задачу.

По сути, здесь вы определите логический граф.

№1. Первым шагом является определение набора переменных, которые вы будете использовать для настройки группы обеспечения доступности баз данных, таких как days_delay, days_export, feature_group_version и т. д. Вы можете получить доступ к этим переменным на панели «Администратор -> Переменные» в Airflow.

Обратите внимание, что вы должны добавить их с помощью синей кнопки плюс явно.

№2. Второй шаг – вызов задач с правильными параметрами. Как видите, из-за API Airflow 2.0 этот шаг аналогичен вызову набора функций Python в определенном порядке.

Примечание. Зависимость на графике создается автоматически, если выходные данные функции добавляются в качестве входных данных для другой функции.

Важно подчеркнуть, как мы передавали метаданные каждого элемента конвейера следующим. При этом мы применяем следующие сценарии для использования правильных данных и версий модели.

Я также хочу подчеркнуть следующий фрагмент кода:

 feature_pipeline_metadata = run_feature_pipeline(
        export_end_reference_datetime="{{ dag_run.logical_date }}",
    )

«{{ dag_run.logical_date }}' — это переменная шаблона, введенная Airflow, которая отражает логическую дату запуска группы обеспечения доступности баз данных. Не текущая дата. Таким образом, используя функции обратной засыпки Airflow, вы можете легко использовать это как ссылку на дату и время для обратной засыпки в заданном временном окне. Теперь вы можете легко манипулировать начальной и конечной точками окна извлечения.

Например, если вы хотите запустить группу обеспечения доступности баз данных для заполнения прогнозов энергопотребления между 10 и 11 мая 2023 года, вы запустите логику заполнения Airflow с датой 10 мая 2023 года, 00:00.

#3. Последний шаг — принудительное применение определенной структуры DAG с помощью оператора '››'.

«A ›› B ›› C» означает запуск A, затем B, затем C.

Единственный более хитрый фрагмент кода:

>> if_run_hyperparameter_tuning_branch
>> [
    if_run_hyperparameter_tuning_branch
    >> Label("Run HPO")
    >> branch_run_hyperparameter_tuning_operator
    >> last_sweep_metadata
    >> upload_best_model_step,
    if_run_hyperparameter_tuning_branch
    >> Label("Skip HPO")
    >> branch_skip_hyperparameter_tuning_operator,
]

, где в зависимости от оператора ветки группа обеспечения доступности баз данных будет запускать ветви branch_run_hyperparameter_tuning_operator или branch_skip_hyperparameter_tuning_operator группы обеспечения доступности баз данных.

Подробнее о ветвлении в Airflow читайте здесь [3].

На английском языке он запустит настройку гипероптимизации или пропустит ее, как показано на изображении ниже — я знаю, что изображение довольно маленькое. Посмотрите видео для лучшего обзора. 👇

Вот оно! Вы организовали все 3 конвейера с помощью Airflow. Поздравляю!

Запустите конвейер машинного обучения DAG

Этот шаг прост.

Просто перейдите в свою группу DAG ml_pipeline и нажмите кнопку воспроизведения.

Обратная засыпка с помощью Airflow

Найдите идентификатор док-контейнера airflow-webserver:

docker ps

Запустите оболочку внутри контейнера airflow-webserver и запустите заполнение dags airflow следующим образом:

docker exec -it <container-id-of-airflow-webserver> sh
# In this example, you did a backfill between 2023/04/11 00:00:00 and 2023/04/13 23:59:59.
airflow dags backfill --start-date "2023/04/11 00:00:00" --end-date "2023/04/13 23:59:59" ml_pipeline

Если вы хотите очистить задачи и запустить их повторно, выполните следующие команды:

docker exec -it <container-id-of-airflow-airflow-webserver> sh
airflow tasks clear --start-date "2023/04/11 00:00:00" --end-date "2023/04/13 23:59:59" ml_pipeline

Заключение

Поздравляем! Вы прошли четвертый урок курса Full Stack 7-Steps MLOps Framework.

Если вы зашли так далеко, вы знаете, как:

  • Разместите свой собственный сервер PyPi
  • Создавайте и развертывайте свои модули Python с помощью Poetry
  • Организуйте несколько конвейеров с помощью Airflow

Теперь, когда вы понимаете возможности использования оркестратора, такого как Airflow, вы можете создавать надежные, готовые к работе конвейеры, которые можно быстро планировать, настраивать и отслеживать.

Ознакомьтесь с уроком 5, чтобы узнать, как использовать прогнозы сегментов GCS и создавать веб-приложения с помощью FastAPI и Streamlit.

Кроме того, вы можете получить доступ к репозиторию GitHub здесь.

💡 Моя цель — помочь инженерам по машинному обучению повысить свой уровень в разработке и производстве систем машинного обучения. Подпишитесь на меня в LinkedIn или подпишитесь на мою еженедельную рассылку, чтобы получать больше информации!



Присоединяйтесь к Medium по моей реферальной ссылке — Paul Iusztin
🤖 Присоединяйтесь, чтобы получить эксклюзивный контент о проектировании и создании готовых к производству систем машинного обучения 🚀 Разблокируйте полный доступ к…pauliusztin .medium.com



Рекомендации

[1] Потребление энергии в соответствии с отраслевым кодексом DE35 от API Дании, Denmark Energy Data Service

[2] Запуск Airflow в Docker, Документация по Airflow

[3] Ветвление в воздушном потоке, Документация по воздушному потоку на Astronomer.