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

Архитектура

Микросервисная архитектура. Наша система содержит микросервис Flask для различных приложений в кластере и использует TensorFlow Serving для прогнозирования в режиме реального времени. Каждый микросервис контейнеризирован с помощью Docker.

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

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

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

Celery worker: Celery является асинхронным рабочим процессом в нашей системе. Рабочие выполняют все задачи рабочего процесса. Каждый воркер берет следующую задачу для выполнения из очереди, в нашем случае Redis, и выполняет задачу локально. (Исполняемая задача идентифицируется по идентификатору задачи и дате выполнения). В будущем Celery можно будет использовать для дальнейшего масштабирования нашей системы, запустив больше воркеров Celery.

Redis. Redis действует как очередь сообщений и как хранилище данных в памяти для нашей системы. В будущем Redis также можно будет использовать в качестве слоя распределенного кеша в нашем кластере. Инвалидация кеша в Redis выполняется путем периодического извлечения из нашей распределенной базы данных Elasticsearch для достижения окончательной согласованности.

База данных:Elasticsearch для постоянства модели. Возможный цикл обновления модели происходит каждый определенный период, в то время как несколько процессов в каждом узле. Все обновления модели будут записаны в Elasticsearch и заменят старые. Каждый процесс запрашивает у Elasticsearch все модели и отфильтровывает все обновленные модели на основе созданной метки времени.

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

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

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

Доступность. Мы поддерживаем высокую доступность при обновлении модели и версии, запуская новый обслуживающий контейнер Tensorflow с обновленной моделью, а затем закрывая старый.

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

Контейнеризация.Чтобы оптимизировать Docker Container, мы могли бы разделить код тестирования и требования в развертываниях, разделить разные приложения на отдельные контейнеры меньшего размера, например создать один небольшой контейнер для каждого приложения вместо одного контейнера для всех приложений. Мы также можем создавать из нескольких базовых образов, что означает, что вместо создания образа с нуля можно использовать оптимизированный образ докера, созданный другими, который содержит TensorFlow. Модель идентифицируется своим UUID, который указывается во время развертывания при обслуживании.

3. Конвейер машинного обучения:

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

Конвейер машинного обучения в Интернете:

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

Онлайн-конвейер загружает модель из кеша или Elasticsearch и выполняет обновление модели.

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

Постобработка в режиме онлайн использует загруженные параметры и средства масштабирования для преобразования значений прогноза в фактические результаты и возврата клиентам для завершения HTTP-вызова.

Конвейер автономного машинного обучения:

Предварительная обработка данных в автономном режиме выполняет проектирование признаков с помощью необработанного набора данных и сохраняет признаки в хранилище данных.

Офлайн-обучение модели инициируется событиями или по запросу. Затем обновленная модель сохраняется в кэше и записывается в Elasticsearch.

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

Управление конвейером моделей:

Диспетчер моделейотвечает за операции CRUD в моделях машинного обучения. Менеджер будет использовать Elasticsearch для хранения моделей в целях аудита, а также для резервного копирования и сохранения моделей в памяти для доставки для прогнозирования.
Model Pipeline Manager создан дляданных, которые необходимо преобразовать перед подачей в моделей и управлять преобразованием признаков (масштабированием) для моделей машинного обучения. Этот менеджер конвейера будет использовать Elasticsearch для хранения конвейера модели в целях аудита и резервного копирования, хранить конвейер модели в памяти для доставки для прогнозирования, может сочетаться с менеджером модели.

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

4. Система мониторинга:

Планировщик:

Отвечает за планирование задач. Планировщик периодически планирует задачи в разные интервалы расписания. Как только ресурсы будут доступны, он поставит задачу в очередь для выполнения в Celery.

Оценка модели:

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

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

Проверка модели:

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

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

Служба очереди задач:

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

И собрать все это вместе

Готовая к производству система машинного обучения:

Использованная литература:

  1. Джереми Херманн и Майк Дель Бальсо (ноябрь 2018 г.), Масштабирование машинного обучения в Uber с Микеланджело. Убер Инжиниринг. Получено с https://eng.uber.com/scaling-michelangelo/
  2. Франциска Белл и Славек Смил (сентябрь 2018 г.), Прогнозирование в Uber: введение. . Убер Инжиниринг. Получено с https://eng.uber.com/forecasting-introduction/
  3. Джереми Херманн и Майк Дель Бальсо (сентябрь 2017 г.), Знакомьтесь, Микеланджело: платформа машинного обучения Uber. Убер Инжиниринг. Получено с https://eng.uber.com/michelangelo-machine-learning-platform/
  4. Алекс Кира (февраль 2019 г.), Управление рабочими процессами обработки данных Uber в масштабе. Убер Инжиниринг. Получено с https://eng.uber.com/managing-data-workflows-at-scale/
  5. Algorithmia (май 2018 г.), Развертывание моделей машинного обучения в масштабе. Получено с https://blog.algorithmia.com/deploying-machine-learning-at-scale/
  6. Семи Коэн (апрель 2019 г.), Создание конвейера машинного обучения. Получить с https://towardsdatascience.com/architecting-a-machine-learning-pipeline-a847f094d1c7