Внедрение конвейера данных и облегченного озера данных глубокого обучения с использованием ClearML на AWS.

Введение

Hour One — это стартап, ориентированный на ИИ, и его основной продукт преобразует текст в видео виртуальных докладчиков.

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

В этом посте описывается проектирование и реализация конвейера данных и решения по управлению данными, которое я создал для Hour One с использованием ClearML и AWS.

Решение основано на облегченной версии
архитектурного шаблона Deep Lake.

Примечание. Я не имею отношения ни к проекту ClearML, ни к его покровителям.

От видео к готовым наборам данных

Модели искусственного интеллекта Hour One должны принимать текст в качестве входных данных и генерировать реалистичные видеоролики в качестве выходных данных.

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

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

С точки зрения подготовки данных и управления ими требуется:

Преобразование видеоданных в полезные представления — чтобы позволить механике обучения сосредоточиться на правильных «функциях» входных данных.

Например. представление звука в формате, используемом для анализа спектра, или кодирование пикселей видео в компактный формат, который можно передать в модель.

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

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

Эти слои могут быть созданы либо программно, либо аннотаторами-людьми, либо и тем, и другим.

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

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

Метаданные могут описывать все видео, его части или очень короткие эпизоды внутри видео, например. уровень кадра.

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

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

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

Предоставление данных с возможностью поиска. Решение должно позволять исследователям быстро составлять наборы данных путем поиска данных для экземпляров с желаемой комбинацией свойств/размеров/метаданных, например. «выберите 100 тренировочных экземпляров, до 40% из них должны иметь мерцание персонажа».

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

Давайте углубимся в требования каждой части решения.

Требования

Трубопровод

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

Входные данные и триггеры

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

Конвейер обычно запускается после получения новых данных и обрабатывает только новое приращение данных.

Иногда мы можем запустить его для всех данных с нуля или для определенного подмножества входных данных.

Обработка

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

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

Расширяемость и развитие

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

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

Выполнение подчиненной DAG и обратное заполнение

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

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

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

Кэширование результатов

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

Семантика обработки вывода

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

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

При работе в этом режиме конвейер должен вызываться через пользовательский интерфейс или планировщик.

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

ЦП и ГП

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

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

Управление данными

Целями подсистемы управления данными является долгосрочное хранение данных и метаданных. Кроме того, следует:

  1. Сделайте данные доступными для поиска и создания наборов данных
  2. Поддержка создания новых наборов данных с контролем версий
  3. Разрешить пользователям загружать наборы данных для обучения

Хранилище

Для долговременного хранения нам требовалась масштабируемая технология хранения объектов, такая как S3.

Форматы хранения мультимедиа

Мы хотим хранить большие медиафайлы — как необработанные, так и предварительно обработанные — в стандартном формате, который позволял бы просматривать их с помощью стандартных инструментов везде, где это возможно (например, .mp4, .wav и .png).

Хранение и схема метаданных
Следуя архитектурному шаблону Deep Lake, метаданные должны храниться в формате, который предлагает структуру и доступен для запросов.

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

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

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

Учебные наборы данных должны контролироваться версиями.

Клирмл 101

ClearML — это проект MLOps с открытым исходным кодом, который сочетает в себе отслеживание экспериментов, управление наборами данных, удаленное выполнение кода и конвейеры заданий, написанные на Python.

Задачи и отслеживание экспериментов

На высоком уровне вы можете настроить программу Python с помощью нескольких строк кода, чтобы подключить ее к ClearML. Инструментированная программа Python называется задачей.

Когда выполняется задача, например. на вашем локальном компьютере код инструментария автоматически собирает такую ​​информацию, как аргументы командной строки, git diff и последний коммит, список пакетов Python, которые были доступны интерпретатору, и даже состояние, характерное для инструмента ML, например метрики PyTorch.

Затем отслеживаемые метаданные отправляются на сервер ClearML и хранятся там, доступны через пользовательский интерфейс и API.

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

Удаленное исполнение

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

Чтобы выполнить задачу на удаленном компьютере, вы «клонируете» ее (через пользовательский интерфейс или вызов API) и помещаете в очередь.

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

Трубопроводы

Группа DAG задач называется конвейером.
Поток конвейера состоит из контроллераtask — еще одна функция Python, которая запускает выполнение задачи и передает между ними параметры и информацию.

Контроллер обычно выполняет задачи, отправляя их в очередь, откуда их получает рабочие.

Наборы данных

Набор данных – это особый вид задачи, в которой пользователь сообщает "данные" вместо, например, метрики, как в обычном эксперименте.

Данные могут быть любыми, но обычно это файлы, хранящиеся в какой-либо файловой системе, такой как смонтированный диск, NFS или объектное хранилище.

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

Метаданные о наборе данных хранятся на сервере ClearML, в то время как фактические данные (например, файлы, содержащиеся в наборе данных) могут храниться на устройстве хранения по вашему выбору, например. S3 или NFS-сервер, если он доступен для рабочих компьютеров, которым необходимо его загрузить и использовать.

Почему ClearML

Функциональная пригодность

ClearML поддерживает все основные функциональные требования:

  • Определение и запуск конвейера обработки мультимедиа в Python
  • Запуск пайплайна в удаленном/распределенном исполнении на CPU и GPU.
  • Хранение большого количества двоичных или полуструктурированных файлов в течение длительного времени, управление ими и их преобразование в наборы данных.
  • Благодаря последующим этапам обработки и процессам обучения можно легко использовать наборы данных.

ClearML может выполнять все эти задачи.

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

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

Плюсы

Хотя существует множество инструментов, с помощью которых можно реализовать эту функциональность, команда Hour One AI уже внедрила ClearML для отслеживания экспериментов.

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

В качестве более общего преимущества инструмент имеет открытый исходный код и активное сообщество.

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

Минусы

Автоматический характер инструмента имеет свою цену — требуется время, чтобы понять, что происходит, когда что-то работает не так, как ожидалось.

Отладка кода ClearML, который не работает должным образом, требует открытия кода инструмента, его отладки, задавания вопросов в Slack и часто наличия практических знаний в области распределенных вычислений, облачных API, управления зависимостями Python, внутреннего устройства докера и многого другого.

Документация может быть, мягко говоря, неоднородной.

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

Системный дизайн

Высокий уровень

  • Рабочий процесс реализован в виде конвейера ClearML (конкретно — с помощью PipelineDecorator).
  • Каждая задача в конвейере принимает в качестве входных данных идентификатор набора данных и создает один или несколько наборы данных в качестве выходных данных.
  • Метаданные о произведенных данных, включая происхождение, хранятся в течение длительного времени в наборах данных . Сами данные находятся на S3 в различных форматах.
  • Масштабирование конвейера достигается с помощью ClearML Queues и Autoscaler.
  • Большинство других требований (кэширование, выполнение подгруппы DAG, локальный и удаленный запуск с одной и той же кодовой базой) выполняются путем тщательного разделения задач, а также с помощью низкоуровневого API ClearML.

Логический поток

Следуйте схеме слева направо:

  • Конвейер запускается с параметром, указывающим на файл, содержащий ссылки на необработанные видео.
    Файл добавляется в набор данных, представляющий «все необработанные данные».
  • Первая задача — разбить необработанные видео на основе метаданных, которые существуют в файле, на более короткие части («сегменты»).
    В результате получается разделенное видео и файлы метаданных, каждый из которых хранится в виде наборов данных ClearML.
  • Следующим шагом является базовая предварительная обработка видео- и аудиоданных из разделенных видео.
    Каждый из них сохраняется в наборах данных ClearML.
  • Дальнейшее обогащение и очистка звуковых и визуальных сигналов — дополнительные ~10 заданий.

Управление данными

  • При каждом выполнении каждой задачи создается один или несколько независимых наборов данных ClearML.
  • Каждый объект набор данных содержит указатель на задачу, создавшую его (и наоборот) для происхождения.
    Это позволяет нам, например. извлекать все различные наборы данных, созданные при выполнении определенного конвейера.
  • Каждый набор данных содержит индекс видеосегментов, которые он содержит.
  • Большие медиафайлы хранятся в своем стандартном формате на S3, а наборы данных ClearML содержат ссылку на их расположение на S3 — с использованием механизма внешних файлов.
  • Файлы меньшего размера клонируются и сохраняются в формате ClearML (также на S3).

Схема метаданных и обработка запросов

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

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

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

Мы решили не добавлять в решение еще одну движущуюся часть и оставить его исключительно на основе ClearML. Вот как мы реализуем запросы:

  1. Исследователь получает список идентификаторов наборов данных, которые он хочет запросить.
    Обычно они включают метаданные или аннотации (не медиаданные).
  2. Используя инструмент ClearML, пользователь загружает и объединяет эти наборы данных в локальную копию набора данных.
    Например, извлеките наборы данных, представляющие ограничивающие рамки и ориентиры лиц.
  3. Исследователь выполняет «запрос», используя стандартные инструменты, такие как numpy или код Pandas, чтобы выбрать данные, на которых он хочет тренироваться.
    Например, перебрать массив Numpy, представляющий ограничивающие рамки лица, и отфильтровать только элементы, у которых общая площадь ограничительной рамки больше X и где все ориентиры попадают в ограничительную рамку.
    Каждый элемент в результате этого «запроса» будет содержать указатель на кадры и видео, из которых он является производным.
  4. Исследователь программно создает новый набор данных, содержащий отфильтрованные видео в ClearML.
  5. Позже обучающий код загружает набор данных из (4) на локальный диск и начинает обучение.

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

Удаленное и кластерное выполнение

Процесс работает следующим образом:

  1. Пользователь инициирует выполнение конвейера — либо запустив конвейер на своем компьютере, либо через пользовательский интерфейс.
  2. Сервер ClearML принимает вызов
  3. Сервер ClearML помещает выполнение задачи, представляющей логику конвейера (контроллер)в очередь
  4. агент, работающий на каком-то компьютере, выполняет эту задачу.
  5. агент начинает выполнять код конвейерного метода.
  6. Контроллер создает задачи ClearML для каждого шага конвейера и помещает их в очередь
  7. Дополнительные рабочие машины берут эти задачи и запускают их локально.
  8. Каждая логика задач вызывает API наборов данных ClearML для создания своих выходных наборов данных, где метаданные сохраняются на сервере ClearML, а фактические данные — на S3.

Автомасштабирование

Нет смысла держать десятки машин непрерывно работающими в ожидании постановки задач в очередь.

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

Поток автомасштабирования весьма сложен:

  1. «Логика автомасштабирования» на самом деле является задачей ClearML, которая помещается в выделенную очередь (например, очередь «DevOps»).
  2. На выделенной машине (которая всегда включена) работает агент, который прослушивает эту очередь.
  3. Агент берет на себя задачу автоматического масштабирования, которая, по сути, выполняется вечно.
  4. Логика задачи включает в себя опрос очередей и, используя конфигурацию, запуск различных типов машин для каждой очереди.
  5. Раскрутка машин осуществляется с помощью API облачного провайдера (например, Boto3 на AWS).
  6. Порожденные машины имеют сценарий запуска Данные пользователя, который устанавливает для них учетные данные и запускает агент ClearML в режиме демона.
  7. После завершения сценария запуска агент прослушивает очередь

Мелкий шрифт:

  • Управление секретами лежит на вас.
    ClearML ожидает, что вы введете учетные данные AWS и учетные данные git .ssh в файл конфигурации и сохраните его на сервере ClearML, что недопустимо с точки зрения основных методов обеспечения безопасности.
  • Агентам нужен доступ к S3, поэтому новые машины должны иметь возможность взять на себя роль с соответствующими разрешениями.
  • Сценарий пользовательских данных генерируется очень косвенным образом — от конфигурации до кода автомасштабирования, вызовов AWS API и т. д.
    Любые ошибки сложно исправить/проверить.

Нам пришлось искать альтернативные решения — т.е. использование соответствующего профиля экземпляра и хранение секретов в решении для управления секретами.

Поддержка задач GPU и CPU

Это достигается наличием двух очередей: одной для задач ЦП и одной для задач ГП.

Каждая задача (функция Python) аннотируется именем очереди, в которую она должна быть отправлена.

Примечания к дизайну на уровне кода

Кодовая база конвейера довольно проста. Ниже приведены псевдопримеры того, как мы построили конвейер.

Строки 7–8.Основная логика контроллера имеет декоратор PipelineDecorator.pipeline(). Кроме того, его параметры (обычно анализируемые из аргументов командной строки) должны сериализоваться с использованием json или pickle.

Строка 9 — любой импорт должен выполняться внутри функции (необходим для удаленного запуска).

Строка 13 — мы используем фабрику для создания объекта «трекер». Большая часть волшебства происходит в объекте трекера. У него есть две реализации — локальный трекер (который более или менее не работает) и трекер ClearML (который фактически выполняет вызовы ClearML.

Правильный класс создается на основе флага командной строки.

Строки 15–19 — поток достигается путем передачи идентификаторов набора данных между методами (задачами).

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

Теперь давайте посмотрим на анатомию задачи:

Строка 1. Задача представляет собой чистую функцию Python с декоратором ClearML.

Строки 3–5 — функция выполняет импорт, который необходим, если мы хотим иметь возможность запускать ее удаленно, а затем инициализирует свой собственный экземпляр tracker.

Строки 7–9. Затем объект трекера отвечает за извлечение кэшированных результатов, если они существуют, или, если их нет, загрузку входного набора данных в локальную папку.

Строки 14–15. С помощью трекера мы загружаем данные, сгенерированные в строках 11–12, в набор данных ClearML под названием «split_videos_media».

Локальный запуск

Чтобы включить локальные запуски, нам нужно вызвать PipelineDecorator.run_locally() перед методом конвейера.

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

Выполняется только в подгруппах DAG

Это также обрабатывается объектом отслеживания, который может проходить через DAG и автоматически пропускать все ненужные задачи.

Отслеживание происхождения

Объект отслеживания помечает все задачи идентификаторами запуска конвейера и помечает каждую задачу списком созданных им наборов данных, которые сохраняются как артефакты внутри ClearML.

Дополнительные функции

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

Краткое содержание

Подготовка крупномасштабных мультимедийных данных для обучения моделей глубокого обучения требует выполнения нескольких этапов обработки и обогащения необработанных данных.

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

ClearML можно использовать для достижения всего вышеперечисленного.

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

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