Введение

В Netflix у нас есть сотни микросервисов, каждый со своими моделями данных или сущностями. Например, у нас есть служба, в которой хранятся метаданные объекта фильма, или служба, в которой хранятся метаданные об изображениях. Все эти сервисы на более позднем этапе хотят аннотировать свои объекты или сущности. Наша команда, Платформа управления активами, решила создать универсальный сервис под названием Marken, который позволяет любому микросервису в Netflix аннотировать свою сущность.

Аннотации

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

  • Сущность фильма с идентификатором 1234 имеет насилие.

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

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

  • В определенный кадр (время)
  • В какой-то области изображения (пространство)
  • Имя персонажа (данные аннотации)

Голы для Маркена

Мы хотели создать сервис аннотаций, который будет преследовать следующие цели.

  • Позволяет аннотировать любой объект. Команды должны иметь возможность определять свою модель данных для аннотации.
  • Аннотации могут иметь версии.
  • Служба должна иметь возможность обслуживать приложения в режиме реального времени, также называемые пользовательским интерфейсом, поэтому операции CRUD и поиска должны выполняться с малой задержкой.
  • Все данные также должны быть доступны для автономной аналитики в Hive/Iceberg.

Схема

Поскольку сервис аннотаций будет использоваться кем угодно в Netflix, нам необходимо было поддерживать разные модели данных для объекта аннотаций. Модель данных в Marken можно описать с помощью схемы — точно так же, как мы создаем схемы для таблиц базы данных и т. д.

Наша команда, Asset Management Platform, владеет другой службой, которая использует DSL на основе json для описания схемы медиаресурса. Мы расширили этот сервис, чтобы также описать схему объекта аннотации.

{
      "type": "BOUNDING_BOX", ❶
      "version": 0, ❷
      "description": "Schema describing a bounding box",
      "keys": {
        "properties": { ❸
          "boundingBox": {
            "type": "bounding_box",
            "mandatory": true
          },
          "boxTimeRange": {
             "type": "time_range",
             "mandatory": true
          }
      }
    }
}

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

  1. Название схемы: BOUNDING_BOX
  2. Схемы могут иметь версии. Это позволяет пользователям добавлять/удалять свойства в своей модели данных. Мы не допускаем несовместимых изменений, например, пользователи не могут изменить тип данных свойства.
  3. Сохраненные данные представлены в разделе «Свойства». В этом случае есть два свойства
  4. boundingBox с типом «bounding_box». По сути, это прямоугольная площадь.
  5. boxTimeRange с типом «time_range». Это позволяет нам указать время начала и окончания для этой аннотации.

Объекты геометрии

Для представления пространственных данных в аннотации использовался формат Well Known Text (WKT). Мы поддерживаем следующие объекты

  • Точка
  • Линия
  • Многострочный
  • Ограничительная рамка
  • Линейное кольцо

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

Временные объекты

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

Для хранения данных в кадрах клиенты также должны хранить кадры в секунду. Мы называем это SampleData со следующими компонентами:

  • sampleNumber или номер кадра
  • образецЧислитель
  • образецЗнаменатель

Объект аннотации

Как и схема, объект аннотации также представлен в формате JSON. Вот пример аннотации для BOUNDING_BOX, которую мы обсуждали выше.

{  
  "annotationId": { ❶
    "id": "188c5b05-e648-4707-bf85-dada805b8f87",
    "version": "0"
  },
  "associatedId": { ❷
    "entityType": "MOVIE_ID",
    "id": "1234"
  },
  "annotationType": "ANNOTATION_BOUNDINGBOX", ❸
  "annotationTypeVersion": 1,
  "metadata": { ❹
    "fileId": "identityOfSomeFile",
    "boundingBox": {
      "topLeftCoordinates": {
        "x": 20,
        "y": 30
      },
      "bottomRightCoordinates": {
        "x": 40,
        "y": 60
      }
  },
  "boxTimeRange": {
    "startTimeInNanoSec": 566280000000,
    "endTimeInNanoSec": 567680000000
  }
 }
}
  1. Первый компонент — это уникальный идентификатор этой аннотации. Аннотация — это неизменяемый объект, поэтому идентификатор аннотации всегда включает версию. Всякий раз, когда кто-то обновляет эту аннотацию, мы автоматически увеличиваем ее версию.
  2. Аннотация должна быть связана с некоторой сущностью, принадлежащей какому-либо микросервису. В данном случае эта аннотация была создана для фильма с идентификатором «1234».
  3. Затем мы указываем тип схемы аннотации. В данном случае это BOUNDING_BOX.
  4. Фактические данные хранятся в разделе metadata json. Как мы обсуждали выше, существует ограничивающая рамка и диапазон времени в наносекундах.

Базовые схемы

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

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

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

  • Временные (данные, связанные со временем)
  • Пространственные (данные геометрии)

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

  • label (строка)
  • confidenceScore (двойной) — обозначает достоверность сгенерированных данных алгоритма.
  • algorithmVersion (String) — версия алгоритма ML.

При использовании множественного наследования типичная схема алгоритма ML является производной от обеих схем TEMPORAL_SPATIAL_BASE и BASE_ALGORITHM_ANNOTATION.

{
  "type": "BASE_ALGORITHM_ANNOTATION",
  "version": 0,
  "description": "Base Schema for Algorithm based Annotations",
  "keys": {
    "properties": {
      "confidenceScore": {
        "type": "decimal",
        "mandatory": false,
        "description": "Confidence Score",
      },
      "label": {
        "type": "string",
        "mandatory": false,
        "description": "Annotation Tag",
      },
      "algorithmVersion": {
        "type": "string",
        "description": "Algorithm Version"
      }
    }
  }
}

Архитектура

Учитывая цели сервиса, мы должны были помнить о следующем.

  • Наш сервис будет использоваться многими внутренними приложениями пользовательского интерфейса, поэтому задержка для CRUD и операций поиска должна быть низкой.
  • Помимо приложений, у нас будут храниться данные алгоритма ML. Некоторые из этих данных могут быть на уровне кадра для видео. Таким образом, объем хранимых данных может быть большим. Выбранные нами базы данных должны иметь возможность горизонтального масштабирования.
  • Мы также ожидали, что сервис будет иметь высокий RPS.

Некоторые другие цели исходили из поисковых требований.

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

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

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

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

Одна из ключевых инициатив Netflix, Media Search Platform, теперь использует Marken для хранения аннотаций и выполнения различных поисков, описанных ниже. Наша архитектура позволяет легко подключать и получать данные из алгоритмов мультимедиа. Эти данные используются различными командами, например. создателям рекламных материалов (трейлеров, изображений баннеров) для улучшения их рабочих процессов.

Поиск

Успех службы аннотаций (меток данных) зависит от эффективного поиска этих меток без знания деталей входных алгоритмов. Как упоминалось выше, мы используем базовые схемы для каждого нового типа аннотации (в зависимости от алгоритма), проиндексированного в сервисе. Это помогает нашим клиентам последовательно выполнять поиск по различным типам аннотаций. Аннотации можно искать либо просто по меткам данных, либо с дополнительными фильтрами, такими как идентификатор фильма.

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

  • Полнотекстовый поиск. Клиенты могут не знать точные метки, созданные алгоритмами машинного обучения. Например, ярлык может быть «занавеска для душа». При полнотекстовом поиске клиенты могут найти аннотацию по ярлыку "curtain" . Мы также поддерживаем нечеткий поиск по значениям меток. Например, если клиенты хотят выполнить поиск 'curtain', но неправильно набрали 'curtian`, аннотация с меткой 'curtain' будет вернулся.
  • Основной поиск. Поскольку глобальный контент Netflix поддерживается на разных языках, наши клиенты должны поддерживать основной поиск для разных языков. Сервис Marken содержит субтитры для полного каталога заголовков в Netflix, которые могут быть на разных языках. В качестве примера для поиска по основе `clothing` и `clothes` можно получить однокоренное слово `cloth`. Мы используем ElasticSearch для поддержки основного поиска на 34 разных языках.
  • Поиск временных аннотаций. Аннотации для видео более актуальны, если они определены вместе с временной информацией (временной диапазон с временем начала и окончания). Временной диапазон в видео также сопоставляется с номерами кадров. Мы также поддерживаем поиск по меткам для временных аннотаций в пределах предоставленного диапазона времени/номера кадра.
  • Поиск пространственных аннотаций. Аннотации к видео или изображениям также могут включать пространственную информацию. Например, ограничивающая рамка, определяющая положение помеченного объекта в аннотации.
  • Временной и пространственный поиск. Аннотации для видео могут иметь как временной диапазон, так и пространственные координаты. Следовательно, мы поддерживаем запросы, которые могут искать аннотации в пределах предоставленного диапазона времени и диапазона пространственных координат.
  • Семантический поиск. Поиск аннотаций можно выполнять после понимания цели предоставленного пользователем запроса. Этот тип поиска предоставляет результаты на основе концептуально схожих совпадений с текстом в запросе, в отличие от традиционного поиска на основе тегов, который, как ожидается, будет точным совпадением ключевых слов с метками аннотаций. Алгоритмы машинного обучения также принимают аннотации с векторами вместо реальных меток для поддержки этого типа поиска. Предоставленный пользователем текст преобразуется в вектор с использованием той же модели ML, а затем выполняется поиск с преобразованным текстом в вектор, чтобы найти наиболее близкие векторы с искомым вектором. Основываясь на отзывах клиентов, такие поиски дают более релевантные результаты и не возвращают пустые результаты, если нет аннотаций, которые точно соответствуют меткам запроса, предоставленным пользователем. Мы поддерживаем семантический поиск с помощью Open Distro for ElasticSearch. Подробнее о поддержке семантического поиска мы расскажем в следующей статье блога.

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

Задержка поиска

Наши клиентские приложения представляют собой студийные приложения с пользовательским интерфейсом, поэтому они ожидают низкую задержку для поисковых запросов. Как указано выше, мы поддерживаем такие запросы с помощью Elasticsearch. Чтобы поддерживать низкую задержку, мы должны убедиться, что все индексы аннотаций сбалансированы, а хотспоты не создаются с использованием какого-либо алгоритма обратной загрузки данных для старых фильмов. Мы следовали стратегии ролловеров индексов, чтобы избежать таких горячих точек (как описано в нашем блоге для приложения управления активами) в кластере, которые могут вызвать скачки загрузки процессора и замедлить ответ на запрос. Задержка поиска для общих текстовых запросов указана в миллисекундах. Запросы семантического поиска имеют сравнительно большую задержку, чем общие текстовые поиски. На следующем графике показана средняя задержка поиска для общего поиска и семантического поиска (включая задержки поиска KNN и ANN).

Масштабирование

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

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

Серверные базы данных Cassandra и Elasticsearch поддерживают горизонтальное масштабирование службы с ростом размера данных и запросов. Мы начали с кластера cassandra из 12 узлов и увеличили количество узлов до 24, чтобы поддерживать текущий размер данных. В этом году добавлены аннотации примерно для полного каталога Netflix. Некоторые заголовки имеют более 3 млн аннотаций (большинство из них связаны с субтитрами). В настоящее время сервис содержит около 1,9 миллиарда аннотаций с объемом данных 2,6 ТБ.

Аналитика

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

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

Будущая работа

В этой области предстоит много интересных работ.

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

Благодарности

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