В соавторстве с Сиддхант Шривастава. Наконечник шляпы Свигги квасцу Пратюш Шарма

В Swiggy мы стремимся быть гиперлокальной удобной платформой на основе ИИ, которая создает беспроблемные и приятные впечатления для наших клиентов. С этой целью мы постоянно инвестируем в наши возможности AI / ML, включая, помимо прочего, людей, процессы и инфраструктуру. В частности, мы создали внутреннюю платформу для развертывания и оркестровки машинного обучения, которая позволяет специалистам по данным легко выполнять итерацию, развертывать и экспериментировать с несколькими моделями и абстрагироваться от интеграции с функциональными группами до простых одноразовых контрактов API. Мы называем это Data Science Platform (DSP).

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

DSP работает с февраля 2018 года и теперь поддерживает сотни моделей в реальном времени и пакетных моделей, которые генерируют более 1 млрд прогнозов в день и обслуживают некоторые из сценариев использования с максимальной пропускной способностью и минимальной задержкой в ​​Swiggy.

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

Принципы DSP

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

Поскольку экосистема для построения моделей разнообразна и достаточно хорошо налажена, и каждый специалист / инженер по данным предпочитает свою среду, язык и т. Д., Было принято решение сосредоточиться на «последней миле», а именно на этапах развертывания и после развертывания. рабочий процесс машинного обучения. С этой целью один из вариантов, который мы должны были сделать, заключался в том, какой формат сериализации / десериализации / времени выполнения использовать, который: 1) будет совместим с нашим стеком машинного обучения Spark / Scikit-Heavy, 2) широко поддерживается, 3) имеет открытый исходный код. , 4) - это не каркас, а библиотека. Эти требования привели нас к тому, что мы остановились на MLeap. MLeap написан на Scala и может быть расширен за счет написания наших преобразователей, настроенных для наших конвейеров скоринга.

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

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

Архитектура DSP

Схема высокого уровня рабочего процесса DSP изображена на рисунке 1. Автономные (исторические) функции создаются запланированными заданиями Spark. Функции, близкие к реальному времени, создаются запросами Flink SQL, настроенными для чтения и управления потоками. Оба набора функций передаются Kafka в потоковом режиме и сохраняются в магазине функций (обсуждается далее). Model Control Tower предоставляет репозиторий для обученных моделей, загружаемых в виде zip-файлов. Он также содержит дополнительные метаданные, такие как имя, версия, функции, результаты и т. Д. Для каждой модели. При загрузке модели одновременно регистрируется модель в среде выполнения прогнозирования и создается конечная точка API, которую затем можно интегрировать с другими службами.

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

На макроуровне DSP является частью более крупной платформы внутри Swiggy. Группа платформ создает и поддерживает другие основные компоненты, которые DSP широко использует. Подразделение Data Platform (DP) платформы управляет озером данных (на базе AWS), в котором хранятся все транзакционные данные и данные журнала Swiggy, а также управляет брокерами данных, которые передают сообщения в / из различных сервисов. Модели, работающие на DSP, имеют собственный доступ к функциям, созданным на основе этих данных. Точно так же подразделение «Мониторинг и оповещение» (Klaxon) платформы предоставляет DSP возможности на основе Grafana для настройки оповещений о проблемах с данными, функциях и прогнозах. DSP выдает статистику, такую ​​как количество, нулевое количество, среднее значение, дисперсию, гистограмму для всех функций в магазине функций. Специалисты по обработке данных / инженеры могут настраивать оповещения с использованием настраиваемых пороговых значений на Grafana и получать оповещения по различным каналам.

Для лучшего времени безотказной работы и разделения задач DSP следует мульти-кластерному подходу, когда вариант использования может быть развернут в его кластере. У каждого кластера есть свой балансировщик нагрузки, среда выполнения и изолированный экземпляр Feature Store. Потребители могут решить, использовать ли многопользовательский / общий кластер или, если того требует вариант использования, развернуть в изолированном / автономном кластере.

Магазин функций

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

DSP предоставляет унифицированный способ (пользовательский интерфейс на рисунке 2) для настройки конвейеров данных для создания функций. Ниже приведены 4 категории функций, которые мы выделяем: 1) записные книжки на основе PySpark, которые манипулируют данными (несколько таблиц, используют UDF и т. Д.) Для создания функций, 2) записные книжки на основе PySpark, которые приводят к оценке модели (которые могут быть функциями для других варианты использования), 3) запросы Flink SQL, которые приводят к функциям, полученным из потоковых данных (например, количество заказов за последние 30 секунд), 4) Запросы Hive / SparkQL, которые приводят к функциям, полученным из данных, которые были записаны в Hive (старше 5+ минут).

Все четыре типа запланированы (первые два используют кластеры Qubole) для работы с частотами, которые соответствуют соответствующим функциям, как определено владельцами модели. Выходные данные всех запланированных заданий записываются в Kafka, который направляет их в два пункта назначения - в S3 (затем в Hive и Snowflake) для постоянных функций и Redis для онлайн-функций. Процесс продажи билетов на основе JIRA гарантирует, что в Redis будут включены только необходимые и подходящие функции. Кроме того, DSP отслеживает проблемы в потоке данных, качестве данных и регрессиях и отправляет предупреждения по различным каналам.

Учитывая, что у нас есть 700+ функций и (быстро) подсчет, DSP создала интерфейс, упрощающий обнаружение и совместное использование функций между моделями и командами. Все функции и их метаданные доступны прозрачно. Магазин функций помог продвинуть парадигму создания функций один раз и использовать в любом месте. Это было особенно полезно для сокращения избыточных усилий, затрачиваемых специалистами по обработке данных при создании общих / канонических функций (например, количества заказов на одного покупателя за последний период X), которые в противном случае создавались бы повторно с небольшими вариациями. Кроме того, поскольку запрос / блокнот, который создает любую данную функцию, прозрачно каталогизируется, любой, кто хочет создать вариант этой функции, может сделать это.

Этапы развертывания модели и после развертывания

Автономные / пакетные модели производятся в виде ноутбуков, запланированных на Qubole с функциями DSP для ограничения формата вывода. Они могут быть запущены или запланированы для выдачи прогнозов.

Для онлайн-моделей специалисты по данным используют пользовательский интерфейс Model Control Tower (рисунок 3) для ввода метаданных и загрузки модели в виде zip-файла (S3 / Zookeeper). Первичные метаданные включают имя и версию модели, а также флаг, который сообщает, является ли это версией модели по умолчанию. Затем модель реплицируется в определенном или во всех кластерах, как определено потребителем. Когда поступает запрос (REST или GRPC), уровень выполнения извлекает необходимые функции из Redis, делает логические выводы для модели и возвращает выходные данные по сетевому вызову.

DSP позволяет одновременно развертывать несколько моделей для конкретного варианта использования, чтобы облегчить A / B-тестирование (с использованием собственной платформы XP) и переход от одной версии к другой. Входящие запросы могут либо специально запрашивать версию модели, либо не указывать версию и обслуживать версию по умолчанию. В принципе, DSP следует за неизменностью как первоклассной концепцией. Это означает, что мы не позволяем перезаписывать модели, любые изменения существующих моделей или совершенно новые модели должны быть настроены как новые версии.

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

Наконец, A / B-тестирование между несколькими моделями является тривиальным, учитывая поддержку параллельных моделей и интеграцию с платформой XP, которая обрабатывает рандомизацию трафика и отслеживание показателей.

DSP обеспечивает плавное масштабирование для удовлетворения требований потребителей к задержке и пропускной способности. Автономные модели масштабируются с помощью автоматического масштабирования кластеров Qubole. Задержка онлайн-моделей зависит от того, сколько функций Redis используется. Например, в случае модели CTR рекламы, которая поддерживает рекламу на нашей домашней странице, мы извлекаем ~ 20 функций в реальном времени и можем поддерживать задержку P95 в 20–25 мс. Что касается нагрузки, DSP обслуживает наши модели ранжирования каналов (пакетная предварительно вычисленная оценка модели с легковесным модификатором) при пиковых нагрузках в 300 000 запросов в секунду.

Наконец, независимо от онлайн- или офлайн-моделей, все прогнозы, функции и метаданные модели (используемая версия) записываются обратно в Hive для последующей аналитики и отслеживания метрик модели (для этого специалисты по данным должны выполнять встроенные запросы для получения «фактических данных»). В то время как мониторинг и оповещение о функциях осуществляются в режиме реального времени, показатели модели отслеживания в настоящее время являются пакетным процессом.

Что готовится

За последние пару месяцев мы добавили следующие новые функции.

  1. Возможность мульти-логической оркестрации / DAG для объединения нескольких моделей и / или правил в один конечный результат. До этого нам требовалось несколько контрактов API с командами разработчиков, если мы хотели иметь возможность объединять логику из нескольких моделей / правил (например, средневзвешенное значение баллов из модели GBT и модели LR и скользящее среднее потребовало бы нескольких звонки). Для этого DSP использует Zeppelin (для составления запросов) и Airflow (для оркестровки).
  2. Прокси-сервис для внешних платформ машинного обучения. DSP осознает необходимость дать возможность специалистам по обработке данных использовать любой алгоритм, который лучше всего подходит для данной задачи. Однако, поскольку большинство внешних платформ машинного обучения не имеют состояния (в том смысле, что вызывающая служба должна отправлять все необходимые функции вместе с запросом), и у нас нет желания переписывать существующие контракты API, мы создали прокси-службу. Проще говоря, он перехватывает запрос, украшает его необходимыми функциями, отправляет его внешнему алгоритму и получает обратно вывод. В настоящее время мы поддерживаем такой способ вывода на основе SageMaker.

В настоящее время мы работаем над добавлением следующих функций.

  1. Более прозрачная атрибуция затрат. В настоящее время мы можем предоставить калькуляцию на уровне модели, но мы хотим иметь возможность детализации до калькуляции на уровне функций. Это поможет нам выявить и оценить функции с низкой рентабельностью инвестиций.
  2. Поддержка TFX и контейнерных моделей.
  3. Единый UX, который связывает воедино различные части рабочего процесса. В настоящее время мы используем сочетание пользовательского интерфейса и командной строки, и наличие общего пользовательского интерфейса во всех направлениях уменьшит количество ошибок.
  4. Модель коляски для развертывания. Мы хотим перейти к размещению моделей вместе с потребляющими услугами. Это поможет нам достичь большей эффективности за счет сокращения сетевых вызовов, меньших задержек и более низких затрат.

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

MLeap. Https://mleap-docs.combust.ml/

Куболе. Https://www.qubole.com/

Библиотека против фреймворка. Https://www.programcreek.com/2011/09/what-is-the-difference-between-a-java-library-and-a-framework/