Инженерия данных / MLOps
MLOps: создание надежной платформы данных
Спойлер: MLOps для платформ машинного обучения - это то же самое, что DevOps для большинства технологических продуктов. Если вы думаете, что это означает, что MLOps автоматизирует ваши развертывания, эта статья для вас.
Что такое DevOps и чем он намного больше, чем автоматическое развертывание?
Вы знаете, что придуманный вами термин стал популярным, когда люди регулярно используют его в разговорах и редко понимают, что вы имели в виду.
- Мартин Фаулер (перефразировано из личного разговора)
Руан хорошо описывает культуру DevOps в своем посте на блики Мартина. Разработчики могут легко потерять интерес к операционным проблемам. Это работает на моей машине - это была обычная фраза между разработчиками в прошлом. Некоторые операторы могут быть менее обеспокоены проблемами развития. Расширение сотрудничества может помочь преодолеть разрыв между членами команды Dev elopers и Op и, таким образом, улучшить ваш продукт.
Это расширенное сотрудничество сделало соблюдаемые требования, такие как мониторинг использования системы и ресурсов, (централизованное) ведение журнала, автоматическое и повторяемое развертывание, отсутствие медленных серверов и т. Д., Ключевыми частями наших продуктов. Каждый из них улучшает качество жизни вашего продукта, либо принося прямую пользу конечному пользователю, либо делая систему более удобной в обслуживании для разработчиков и пользователей, тем самым сокращая время на устранение проблем для конечных пользователей. Разработчики и операторы также являются первоклассными пользователями вашей системы. Их счастье (простота устранения неполадок, развертывания и т. Д.) Является ключевой частью успеха вашего продукта. Это позволяет им тратить больше времени на улучшение вашего продукта, платя конечным пользователям.
Что такое MLOps?
MLOps - это культура, которая расширяет сотрудничество между людьми, создающими модели машинного обучения (разработчики, специалисты по данным и т. Д.), И людьми, которые следят за этими моделями и следят за тем, чтобы все работало должным образом (операции). Наблюдаемые требования в вашей системе будут частично совпадать с тем, о чем мы уже говорили, например, мониторинг системы и ресурсов, (централизованное) ведение журнала, автоматическое и повторяемое развертывание, автоматическое создание повторяемой (не снежинки) инфраструктуры и т. Д. Он также будет включать несколько наблюдаемых требований, характерных для платформы данных, таких как управление версиями моделей и данных, происхождение данных, мониторинг эффективности вашей модели в течение длительного периода времени, мониторинг дрейфа данных и т. д.
Некоторые инструменты / методы для создания надежной платформы данных
Потребности каждой платформы данных немного различаются в зависимости от задач, которые вы решаете, и масштаба, в котором вы работаете. Одна из платформ, над которой я работал, производит 2 ТБ данных каждую неделю. Не прошло много времени, чтобы расходы на хранение данных стали статьей номер 1 в нашем счете, и мы потратили некоторое время на оптимизацию нашей стратегии хранения и хранения. Другие товарищи по команде снизили объемы данных и сосредоточились на сокращении времени цикла создания модели. Ваш пробег может отличаться.
Основываясь на нашем опыте создания платформ данных за последние несколько лет, вот несколько инструментов, которые мы использовали и за которыми следили.
Хранилище данных
Выберите механизм хранения, обеспечивающий дешевый и надежный доступ к вашим данным, при соблюдении всех юридических требований к вашему набору данных. Если вы находитесь в строго регулируемой среде (финансы, медицина и т. Д.), Возможно, вы не сможете использовать облако для данных о клиентах. Техники по-прежнему остаются похожими. Разделите данные на разделы в зависимости от требований к доступу и времени хранения. Архивируйте данные, когда они вам не нужны. Используйте такие функции, как предикаты push down, для эффективного чтения ваших данных.
Недавно мы писали о хранении данных, управлении версиями и разделении, что очень подробно рассматривает эту тему.
Планировщик заданий / оркестратор рабочего процесса
Ваши конвейеры данных со временем станут сложными. Как и инфраструктура как код, нам нужны конвейеры данных в коде. Apache Airflow - один из инструментов, который позволяет нам делать это довольно легко. Sayan Biswas писал о нашем использовании воздушного потока в 2019 году. За последние несколько лет мы внесли десятки улучшений в то, как мы используем Airflow. В следующей публикации этой серии мы поговорим об этих улучшениях.
Мониторинг и управление затратами на обработку данных
Мы создаем кластеры EMR по запросу и завершаем их работу по завершении работы. Кластер выполняет только 1 искровое задание (и несколько дополнительных задач для очистки и создания отчетов). Если задание не удается из-за ограничений ресурсов, это помогает изолировать, потребляло ли другое «голодное задание» слишком много ресурсов до того, как сработала политика масштабирования.
Каждый кластер EMR имеет узел оркестратора (AWS и Hadoop называют их «главными узлами») и группу основных узлов (Hadoop называет их «рабочими узлами»). Мы запрашиваем узлы по запросу для оркестраторов и резервируем экземпляры для снижения затрат. Мы делаем ставки на спотовые инстансы для ядер, используя стратегию динамического ценообразования, которая зависит от текущей цены. Мы рассмотрели возможность создания системы, которая автоматически меняет типы инстансов в зависимости от доступности, цены и стабильности в AWS, но сбои при спотовых торгах в настоящее время достаточно редки, и это не оправдывает затрат на разработку этой функции.
Мы также отслеживаем использование ресурсов наших искровых заданий с помощью Ganglia on AWS EMR. Это говорит нам об использовании ЦП, памяти, диска и сети для наших кластеров. Поскольку информация о Ganglia теряется при завершении кластера, мы выполняем шаг EMR, чтобы экспортировать моментальный снимок Ganglia до завершения кластера. Это в сочетании с данными постоянного сервера истории искр в AWS позволяет нам настраивать неэффективные искровые задания. В следующем посте мы подробно рассмотрим, как эффективно отслеживать ваши рабочие места и настраивать их.
Мониторинг состояния заданий конвейера данных
Airflow создает кластеры EMR и контролирует каждое задание. Если задание не удается, Airflow уведомляет нас по определенному каналу резервирования со ссылками на журналы Airflow и кластер AWS.
Сложные искровые приложения создают сотни мегабайт журналов. Эти журналы распределяются по кластеру и будут потеряны при завершении работы кластера. AWS EMR имеет возможность автоматически копировать журналы в S3 с задержкой в 2 минуты.
Мы пробовали использовать CloudWatch для индексации и анализа наших журналов искр, но это было слишком дорого. Мы также пытались использовать собственный стек ELK, но стоимость его увеличения для объема отправленных журналов была слишком высокой. Выгрузив его на S3 и проанализировав в автономном режиме, мы получили наилучшее соотношение цены и производительности.
Чтобы сократить время на устранение проблемы, при ее обнаружении кластер EMR анализирует свои журналы из YARN и публикует выдержку в резервной копии в виде вложения. Любой дальнейший подробный анализ можно сделать в журналах в S3.
Мониторинг качества данных и дрейфа данных
Каждый раз, когда мы пишем код, мы запускаем тесты, чтобы убедиться, что код безопасен для развертывания. Почему мы не делаем то же самое с данными каждый раз, когда получаем к ним доступ?
Когда вы впервые просматриваете данные и строите модель, вы убедитесь, что качество данных, используемых для обучения модели, соответствует приемлемым стандартам для вашего решения. Качество данных измеряется путем анализа качественных и количественных частей вашего набора данных. С течением времени эти качественные и количественные атрибуты могут дрейфовать, вызывая неблагоприятные последствия для вашей модели. Таким образом, важно отслеживать качество данных и их дрейф. Дрейф данных может быть достаточно большим, чтобы ваша модель больше не давал правильных результатов, или может быть достаточно малым, чтобы внести искажение в ваши результаты. Мониторинг этих характеристик является ключом к получению точных сведений о вашем бизнесе.
Такие инструменты, как Большие надежды и Deequ, гарантируют, что ваши данные будут структурно и объемно надежными. У Deequ также есть операторы, которые следят за скоростью изменения данных, что является лучшим ожиданием, чем наличие статических пороговых значений для больших объемов данных.
Например, учитывая базу данных о заработной плате сотрудников, в которой значение зарплаты допускает значение NULL, проверка, гарантирующая, что не более 100 сотрудников из 1000, данные о которых у вас в настоящее время есть данные, не имеют отчетной зарплаты, обречена на неудачу при значительном увеличении объема данных. Если эта проверка должна гарантировать, что не более 10% сотрудников не имеют заявленной заработной платы, будет работать, поскольку данные масштабируются, пока они масштабируются равномерно. Переход к проверке, которая отслеживает скорость изменения доли пользователей, не сообщающих о заработной плате, будет более надежным. Если число значительно изменится (вверх или вниз), это может означать, что пришло время настроить вашу модель, поскольку исходные данные отдаляются от того, когда она была обучена.
Существуют более сложные примеры того, как мы наблюдаем за дрейфом данных, которые придется ждать специальной публикации.
Мышление MLOps
Когда наши конечные пользователи чувствуют боль, мы добавляем новые функции, чтобы улучшить их опыт. То же самое должно относиться к разработчикам / опыту эксплуатации (DevEx / OpsEx).
Когда нам требуется больше времени, чтобы отладить проблему или понять, почему модель сделала то, что она сделала, мы улучшаем наши инструменты и возможности наблюдения в нашей системе. Когда он работал медленнее или стоил дороже, мы улучшали наблюдаемость, чтобы быстрее исследовать неэффективность.
Это позволило нам увеличить нашу платформу данных в 10 раз с точки зрения функций и объемов данных, при этом сократив время, необходимое для получения информации для наших конечных пользователей, на 98,75%, а затраты на это - на 35%, а не упомянуть о значительном улучшении качества обслуживания разработчиков и клиентов.
Спасибо Jayant, Priyank, Anay и Trishna за рецензирование черновиков и ранние отзывы. Как всегда, волшебство художественных работ Ники - ключ к успеху!
