от Aryan Mehra
с Farnaz Karimdady Sharifabad, Prasanna Vijayanathan, Chaina Wade, Vishal Sharma и Mike Schassberger

Цель и назначение — постановка задачи

Цель этой статьи — дать представление об анализе и прогнозировании «нехватки памяти» или убийств OOM в приложении Netflix. В отличие от мощных вычислительных устройств, телевизоры и телевизионные приставки обычно имеют более жесткие ограничения памяти. Что еще более важно, низкая доступность ресурсов или сценарий «недостаточно памяти» являются одной из распространенных причин сбоев/убийств. Мы в Netflix, как служба потоковой передачи, работающая на миллионах устройств, располагаем огромным объемом данных о возможностях/характеристиках устройств, а также данных о времени выполнения на нашей платформе больших данных. С большими данными появляется возможность использовать данные для прогнозного и классификационного анализа. В частности, если мы можем предсказать или проанализировать убийства из-за нехватки памяти, мы можем предпринять действия для конкретного устройства, чтобы упреждающе снизить производительность в пользу предотвращения сбоя — с целью предоставить пользователю максимальный опыт работы с Netflix в рамках «производительности по сравнению с предварительным». ограничения компромисса «эмпективное действие». Основным преимуществом прогнозирования и упреждающих действий является тот факт, что мы можем предпринимать действия для улучшения взаимодействия с пользователем.

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

Проблемы курирования и маркировки наборов данных

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

Во-вторых, и это более важно, объем данных среды выполнения очень велик. Несколько устройств под управлением Netflix будут регистрировать использование памяти через фиксированные промежутки времени. Поскольку приложение Netflix не очень часто уничтожается (к счастью!), это означает, что большинство этих записей представляют собой нормальные/идеальные/как и ожидалось состояния времени выполнения. Таким образом, набор данных будет очень предвзятым/перекошенным. Вскоре мы увидим, как мы на самом деле помечаем, какие записи ошибочны, а какие нет.

Функции и компоненты набора данных

На приведенном выше рисунке схемы описаны два компонента набора данных — возможности/характеристики устройства и данные оперативной памяти. При объединении на основе атрибутов, которые могут однозначно сопоставить запись в памяти с возможностями устройства. Эти атрибуты могут быть разными для разных потоковых сервисов — для нас в Netflix это комбинация типа устройства, идентификатора сеанса приложения и версии комплекта разработки программного обеспечения (версия SDK). Теперь мы исследуем каждый из этих компонентов по отдельности, выделяя при этом нюансы конвейера данных и предварительной обработки.

Возможности устройства

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

Основные вехи в разработке данных для характеристик устройств

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

Работа с неоднозначностями и отсутствующими данными. Иногда записи в BDP загрязнены проверочными записями и значениями NULL, а также неоднозначными значениями, которые не имеют смысла или просто противоречат друг другу из-за нереальных тестовых сред. Со всем этим мы справляемся простым большинством голосов (статистический режим) по представлению, которое индексируется по идентификатору типа устройства и версии SDK из пользовательского запроса. Таким образом, мы проверяем гипотезу о том, что фактические характеристики устройства всегда составляют большинство в озере данных.

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

Память времени выполнения, OOM Kill Data и маркировка наземной правды

Данные во время выполнения постоянно увеличиваются и постоянно развиваются. Таблицы и представления, которые мы используем, обновляются каждые 24 часа, и объединение любых двух таких таблиц потребует огромных вычислительных и временных ресурсов. Чтобы курировать эту часть набора данных, мы предлагаем несколько советов, приведенных ниже (написанных с точки зрения SparkSQL-подобных процессоров распределенных запросов):

  • Фильтрация записей (условий) перед JOIN и для этой цели тщательное использование предложений WHERE и LEFT JOIN. Условия, исключающие записи после операции соединения, обходятся гораздо дороже, чем когда удаление происходит до объединения. Это также предотвращает нехватку памяти во время выполнения запроса.
  • Ограничение тестирования и анализа одним днем ​​и устройством за раз. Всегда полезно выбрать один день с высокой частотой, например Новый год, День поминовения и т. д., чтобы увеличить количество частот и получить нормализованное распределение по различным функциям.
  • Достижение баланса между конфигурациями памяти драйвера и исполнителя в системах, подобных SparkSQL. Слишком большие выделения могут привести к сбою и ограничению системных процессов. Слишком маленькое выделение памяти может привести к сбою во время локального сбора или когда драйвер пытается накопить результаты.

Маркировка данных — Ground Truth

Важным аспектом набора данных является понимание того, какие функции будут доступны нам во время вывода. Таким образом, данные памяти (которые содержат навигационный уровень и чтение памяти) могут быть помечены с помощью данных уничтожения OOM, но последние не могут быть отражены во входных функциях. Лучший способ сделать это — использовать подход со скользящим окном, когда мы помечаем показания памяти сеансов в фиксированном окне до уничтожения OOM как ошибочные, а остальные записи — как не ошибочные. Чтобы сделать маркировку более детализированной и внести больше вариаций в модель бинарной классификации, мы предлагаем подход с градуированными окнами, как показано на изображении ниже. По сути, он присваивает более высокие уровни чтениям памяти ближе к уничтожению OOM, что делает проблему классификации нескольких классов. Уровень 4 наиболее близок к убийству OOM (диапазон 2 минуты), тогда как уровень 0 находится за пределами 5 минут любого убийства OOM перед ним. Здесь мы отмечаем, что устройство и сеанс экземпляра уничтожения OOM и чтение памяти должны совпадать для корректности маркировки. Позже матрица путаницы и результаты модели могут быть преобразованы в бинарные, если это необходимо.

Резюме прогнозирования OOM — формулировка проблемы

Набор данных теперь состоит из нескольких записей, каждая из которых имеет определенные функции времени выполнения (уровень навигации и чтение памяти в нашем случае) и характеристики устройства (сочетание из более чем 15 функций, которые могут быть числовыми, логическими или категориальными). Выходная переменная — это оцененная или неоцененная классификационная переменная, которая помечена в соответствии с приведенным выше разделом — в первую очередь на основе близости штампа чтения памяти к уничтожению OOM. Теперь мы можем использовать любой мультиклассовый алгоритм классификации — ANN, XGBoost, AdaBoost, ElasticNet с softmax и т. д. Таким образом, мы успешно сформулировали задачу предсказания уничтожения OOM для устройства, транслирующего Netflix.

Анализ данных и наблюдения

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

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

Разработка функций, меры точности и направления будущей работы

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

  • Мы могли бы вручную создавать функции в памяти, чтобы использовать характер временных рядов значения памяти при агрегировании по сеансу пользователя. Предложения включают скользящее среднее последних 3 значений или разницу между текущим входом и скользящим экспоненциальным средним. Анализ увеличения памяти пользователем может дать представление о том, было ли убийство вызвано спросом на потоковую передачу в приложении или внешними факторами.
  • Еще одной особенностью может быть время, проведенное на разных навигационных уровнях. Внутри приложение кэширует несколько предварительно загруженных данных, изображений, описаний и т. д., и время, проведенное на уровне, может указывать, очищены ли эти кэши.
  • При принятии решения о мерах точности для проблемы важно проанализировать различие между ложными положительными и ложными отрицательными результатами. Набор данных (к счастью для Netflix!) будет сильно необъективным — например, более 99,1% записей не связаны с убийствами. В общем, ложные срабатывания (непредсказывающие уничтожение, когда на самом деле приложение было уничтожено) более вредны, чем ложные срабатывания (предсказывающие уничтожение, даже если приложение могло выжить). Это связано с тем, что, поскольку уничтожение происходит редко (0,9 % в этом примере), даже если мы в конечном итоге снизим память и производительность на 2 % времени и поймаем почти все 0,9 % убийств OOM, мы примерно устраним. все убийства OOM с компромиссом в виде снижения производительности/очистки кеша на дополнительные 1,1% времени (ложные срабатывания).

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

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

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

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

Благодарности
Я хотел бы поблагодарить членов различных команд — Partner Engineering (Михир Дафтари, Акшай Гарг), команду TVUI (Эндрю Эйхакер, Джейсон Маннинг) , Группу потоковых данных, Группу платформы больших данных, Группу экосистемы устройств и Группу инженеров по анализу данных (Крис Фам) за всю их поддержку.