Собственные приложения Snowflake позволяют разрабатывать приложения непосредственно на основе ваших данных в облаке Snowflake. С помощью собственных приложений вы можете создавать приложения, которые могут превосходить возможности традиционных инструментов бизнес-аналитики, сохраняя при этом высокие стандарты безопасности Snowflake. Поскольку нативные приложения все еще находятся на ранних стадиях разработки (в настоящее время все еще находятся в закрытой предварительной версии), не существует стандартного способа автоматизации процессов разработки с помощью непрерывной интеграции и непрерывной доставки (CI/CD). CI/CD лежит в основе современной DevOps и гибкой разработки приложений, и ее необходимо внедрить в любом нетривиальном случае использования. В этой статье я расскажу о простой стратегии CI/CD, которую я использовал для развертывания собственных приложений Snowflake, и предоставлю соответствующий код как для приложения, так и для процесса CI/CD.
Для этой настройки CI/CD я сосредоточился на использовании моделей в Sreamlit с собственным приложением Snowflake. Для полноценного приложения ML существует гораздо больше компонентов, которые необходимо учитывать при CI/CD, но уже существует множество хороших справочных материалов для исходных MLOps.
Цели реализации CI/CD:
- Разверните модель машинного обучения в собственном приложении и получите доступ к модели с помощью Streamlit.
- Автоматизируйте выполнение SQL, чтобы мне не приходилось вручную запускать какие-либо отдельные операторы SQL.
- Беспрепятственное перемещение между локальной средой, средой разработки и рабочей средой.
- Непрерывное развертывание с интеграцией действий Github
Весь код этого проекта находится у меня на github: https://github.com/PrestonBlackburn/snowflake-native-apps-ci-cd
Обзор
Прежде чем мы сможем реализовать автоматизацию CI/CD, нам нужно будет создать объект модели и UDF Snowflake, которые будут использоваться для прогнозирования. В реальной настройке это произойдет в отдельном конвейере MLOps, но для простоты мы построим и обучим одну модель, используя хранимые процедуры Snowpark. Это использует вычисления Snowflake для обучения модели и создаст модель, которую мы будем использовать для прогнозов.
Как только модель будет готова к работе, мы можем приступить к разработке приложения. Для нашей локальной настройки тестирования мы хотим разместить Streamlit локально и вызвать UDF Snowflake и таблицы, которые мы создали. Пока пользовательские функции и модель доступны на этапе Snowflake, локальное тестирование не вызывает затруднений. Это тот же процесс, что и при создании приложения Snowflake Streamlit. Это хорошо документировано здесь
Для развертывания собственных приложений Snowflake необходимо выполнить серию SQL-скриптов и определить определенные параметры в файле yaml. Запуск сценариев SQL будет автоматизирован и шаблонизирован с помощью сценариев Python. Это позволяет нам легко изменить сценарий, если мы хотим развернуть его в среде разработки, а не в среде производства. Затем действия Github можно использовать для вызова сценария развертывания, который выполняет все развертывание в Snowflake в одном месте, что значительно упрощает конвейер.
Архитектура CI/CD высокого уровня
Наряду с архитектурой CI/CD нам также необходимо определить рабочий процесс для локального тестирования и последующего развертывания приложения. Поскольку нативные приложения все еще очень новы, в реальной жизни существует не так много примеров этого. Две основные концепции, представленные Snowflake для собственных приложений, — это пакет приложения и приложение. По сути, это просто специальные типы баз данных Snowflake. Для этого рабочего процесса мы будем использовать три базы данных: одну для тестирования нашего локального приложенияstreamlit, одну для пакета приложения и одну для самого приложения. Ниже приведен рабочий процесс, который я использовал для всего процесса от создания модели до развертывания Streamlit на Snowflake.
Обзор рабочего процесса
Общие этапы рабочего процесса
- Настройка и локальное тестирование
Во-первых, нам нужно загрузить данные обучения в Snowflake, чтобы мы могли использовать их для обучения. Данные также следует разделить на маркированный и немаркированный набор данных, который позже будет использоваться для прогнозирования.
Затем создайте и протестируйте модель прогнозирования с помощью Snowpark в блокноте Jupyter.
Сохраните объект модели на сцене «Снежинка».
Создайте и протестируйте пользовательскую функцию для проверки прогнозов с помощью сохраненной модели.
Создайте приложение Streamlit, которое ссылается на объекты Snowflake и использует UDF для прогнозирования.
2. Упаковка приложения
Создайте необходимые исходные файлы для пакета в зависимости от целевой среды развертывания.
Обновите сценарий setup.sql, определяющий способ создания приложения.
Запустите файл Deploy.py, чтобы загрузить локальные файлы в пакет Snowflake.
Запустите любые тесты
3. Развертывание приложения
После того, как модель упакована, нам просто нужно запустить SQL-операторы создания приложения, чтобы сгенерировать приложение.
Ключевой частью этого рабочего процесса является файл Deploy.py, который я создал, чтобы упростить процесс автоматизации. Он автоматически выполняет поиск в папке src и передает эти файлы на этап пакета приложения. Он также использует файл конфигурации to_stage.yml для шаблонирования некоторых параметров SQL. Это упрощает переключение между развертыванием приложения для разработки и производства в зависимости от среды.
Поскольку из файла Deploy.py существует единственная точка входа в приложение, я могу легко настроить рабочий процесс действий Github, который будет запускаться, когда изменения будут отправлены в ветку разработки или продукта, и инициировать соответствующий рабочий процесс.
Практический процесс развертывания
Предполагается, что исходные объекты уже созданы с помощью записных книжек Jupyter, представленных в GitHub, и вы уже клонировали репозиторий GitHub.
Проект локального тестирования и обновления:
- установить зависимости
pip install -r requirements.txt
2. Обновите следующие файлы, указав свою информацию.
- app/deploy/to_stage.yml <- key deployment variables to update (used in deploy.py) - src/* <- this is where you will build out your own app - sf_account.config <- your snowflake credentials used for creating the app
3. Вручную протестируйте развертывание на dev и prod с помощью сценария Deploy.py.
python app/deploy/deploy.py --env dev python app/deploy/deploy.py --env prod
Последовательность развертывания с помощью CI/CD:
Еще раз убедитесь, что файлы приложения обновлены вашей информацией.
- app/deploy/to_stage.yml <- key deployment variables to update (used in deploy.py) - src/* <- this is where you will build out your own app - sf_account.config <- your snowflake credentials used for creating the app
- Преобразуйте файл sf_account.config в строку base64, чтобы его можно было загрузить в секреты действий GitHub.
(если в Linux)
cat sf_account.config | base64
Пример результата: W0RFRkFVTFRdDQphY2NvdW50PWdqemtqb2stdGo1NDkxOA0KdXN
2. Загрузите строку секретов как секрет на GitHub. Убедитесь, что секретное имя совпадает с файлом Deploy.yml рабочего процесса действий GitHub.
3. Отправьте изменения в ветку разработки или основную ветку, чтобы запустить автоматическое развертывание.
Пример после запуска рабочего процесса:
О приложении
Для этого приложения я обучил модель, которую можно использовать на форматированных данных о клиентах для прогнозирования оттока. Само по себе это не требует создания собственного приложения, поэтому я добавил интерактивный анализ «что, если», чтобы помочь конечным пользователям понять модель. Анализ «что если» позволяет пользователю вручную вводить значения и видеть, что модель возвращает для этих значений. Было бы сложнее обеспечить такую интерактивность с помощью традиционного инструмента бизнес-аналитики.
Пользовательский интерфейс приложения
Приложения, работающие в рабочей среде на Snowflake
Пример приложения, работающего на очень небольшом складе
Заключение
Этот рабочий процесс призван стать отправной точкой, которую каждый может клонировать, развивать или изменять. По мере того, как мы ближе знакомимся с нативными приложениями, а нативные приложения со временем становятся более зрелыми, этот процесс развертывания, скорее всего, станет намного проще, но на данный момент может быть сложно управлять всеми различными компонентами без поддержки сценариев.
