Пакетная оценка с помощью моделей R для прогнозирования продаж

Пакетная служба
Хранилище BLOB-объектов
Экземпляры контейнеров
Logic Apps
Машинное обучение

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

Architecture diagram showing batch scoring with R models on Azure.

Рабочий процесс

Архитектура состоит из следующих компонентов.

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

Хранилище BLOB-объектов Azure хранятся входные данные, предварительно обученные модели машинного обучения и результаты прогнозирования. Она обеспечивает экономичное хранилище для производительности, необходимой для этой рабочей нагрузки.

Экземпляры контейнеров Azure предоставляет бессерверные вычисления по запросу. В этом случае экземпляр контейнера развертывается по расписанию для запуска заданий пакетной службы, создающих прогнозы. Задания пакетной службы активируются из скрипта R с помощью пакета doAzureParallel . Экземпляр контейнера автоматически завершает работу после завершения заданий.

Azure Logic Apps активирует весь рабочий процесс, развернув экземпляры контейнера по расписанию. Соединитель Экземпляры контейнеров Azure в Logic Apps позволяет развертывать экземпляр в диапазоне событий триггера.

Компоненты

Сведения о решении

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

Потенциальные варианты использования

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

Обработка предусматривает указанные ниже действия.

  1. Приложение логики Azure запускает процесс создания прогноза один раз в неделю.

  2. Приложение логики запускает экземпляр контейнера Azure с контейнером Docker планировщика, который активирует задания оценки в кластере пакетной службы.

  3. Задания оценки выполняются параллельно на узлах кластера пакетной службы. Каждый узел:

    1. Извлекает образ Docker рабочей роли и запускает контейнер.

    2. Считывает входные данные и предварительно обученные модели R из хранилища BLOB-объектов Azure.

    3. Оценивает данные для создания прогнозов.

    4. Записывает результаты прогнозирования в хранилище BLOB-объектов.

На следующем рисунке показан прогнозируемый объем продаж для четырех продуктов (SKU) в одном магазине. Черная линия является историей продаж, пунктирная линия является медианом (q50) прогноз, розовая полоса представляет 25-й и 75-й процентиль, а синяя полоса представляет 50-й и 95-й процентили.

Sales forecasts from batch scoring with R models.

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

Эти рекомендации реализуют основы платформы Azure Well-Architected Framework, которая представляет собой набор руководящих принципов, которые можно использовать для повышения качества рабочей нагрузки. Дополнительные сведения см. в разделе Microsoft Azure Well-Architected Framework.

Производительность

Контейнерное развертывание

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

Экземпляры контейнеров Azure предоставляет бессерверную среду для запуска контейнера планировщика. Контейнер планировщика запускает скрипт R, который запускает отдельные задания оценки, выполняемые в кластере пакетная служба Azure.

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

Параллелизация рабочей нагрузки

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

  • Сколько данных можно загрузить и обработать в памяти одного узла.
  • Затраты на запуск каждого пакетного задания.
  • Издержки загрузки моделей R.

В сценарии, используемом в этом примере, объекты модели большие, и для создания прогноза отдельных продуктов требуется всего несколько секунд. По этой причине можно сгруппировать продукты и выполнить одно задание пакетной службы на узел. Цикл в каждом задании создает прогнозы для продуктов последовательно. Этот метод является наиболее эффективным способом параллелизации конкретной рабочей нагрузки. Это позволяет избежать дополнительных затрат на запуск множества небольших пакетных заданий и многократной загрузки моделей R.

Альтернативным подходом является активация одного задания пакетной службы на продукт. пакетная служба Azure автоматически формирует очередь заданий и отправляет их для выполнения в кластере по мере того, как узлы становятся доступными. Используйте автоматическое масштабирование , чтобы настроить количество узлов в кластере в зависимости от количества заданий. Этот подход полезен, если выполнение каждой операции оценки занимает относительно много времени, что оправдывает затраты на запуск заданий и перезагрузку объектов модели. Этот подход также проще реализовать и обеспечивает гибкость использования автоматического масштабирования, важно учитывать, если размер общей рабочей нагрузки неизвестен заранее.

Мониторинг заданий пакетная служба Azure

Мониторинг и завершение пакетных заданий на панели "Задания" учетной записи пакетной службы в портал Azure. Отслеживайте пакетный кластер, включая состояние отдельных узлов, на панели "Пулы ".

Журнал с помощью doAzureParallel

Пакет doAzureParallel автоматически собирает журналы всех stdout/stderr для каждого задания, отправленного на пакетная служба Azure. Эти журналы можно найти в учетной записи хранения, созданной при настройке. Чтобы просмотреть их, используйте средство навигации по хранилищу, например Обозреватель службы хранилища Azure или портал Azure.

Чтобы быстро выполнить отладку заданий пакетной службы во время разработки, просмотрите журналы в локальном сеансе R. Дополнительные сведения см. в разделе " Настройка и отправка запусков обучения".

Оптимизация затрат

Оптимизация затрат заключается в поиске способов уменьшения ненужных расходов и повышения эффективности работы. Дополнительные сведения см. в разделе Обзор критерия "Оптимизация затрат".

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

В сценариях, когда объем вычислительных ресурсов, необходимых для выполнения задания, неизвестен заранее, может оказаться более подходящим для использования автоматического масштабирования. При таком подходе размер кластера масштабируется вверх или вниз в зависимости от размера задания. пакетная служба Azure поддерживает ряд формул автомасштабирования, которые можно задать при определении кластера с помощью API doAzureParallel.

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

пакетная служба Azure и doAzureParallel поддерживают использование низкоприоритетных виртуальных машин. Эти виртуальные машины предоставляют значительную скидку, но риск, соответствующий другим рабочим нагрузкам с более высоким приоритетом. Поэтому для критически важных рабочих нагрузок не рекомендуется использовать низкоприоритетные виртуальные машины. Однако они полезны для экспериментальных рабочих нагрузок или рабочих нагрузок разработки.

Развертывание этого сценария

Чтобы развернуть эту эталонную архитектуру, выполните действия, описанные в репозитории GitHub.

Дальнейшие действия