О себе Реферат Научные труды Индивидуальный раздел

Назад в библиотеку

---

Телеметрические данные для прогнозирования отказов жёстких дисков

Лука Де Мартини, Джавад Тахир, Кристоф Добландер, Себастьян Фришбир

Политехнический университет Милана, Технический университет Мюнхена, Allianz Global Investors GmbH Germany

АННОТАЦИЯ

DEBS Grand Challenge (GC) — это конкурс программирования, интегрированный в ежегодную ACM Международную конференцию по распределенным и событийно-ориентированным системам (DEBS) начиная с DEBS 2011. Выпуск DEBS GC 2024 посвящен анализу реальных телеметрических данных о более чем 200 тыс. жестких дисках в дата-центрах. Цель конкурса — непрерывно вычислять кластеры схожих дисков по мере поступления новых данных. Такой анализ может быть полезен для быстрого выявления групп дисков с высокой вероятностью отказа и реализации стратегий предиктивного обслуживания. Представленные решения оцениваются на основе их дизайна, производительности, эффективности, простоты повторного использования, отказоустойчивости и адаптации к различным проблемам. В этой статье описывается область телеметрических данных для жестких дисков, набор данных, используемый в конкурсе, конкретная формулировка задачи и платформа Challenger, используемая для оценки заявок.

CCS КОНЦЕПЦИИ

- Методологии вычислений > Распределенные алгоритмы; • Информационные системы > Управление потоками данных; • Общие и справочные материалы > Общие материалы конференций.

КЛЮЧЕВЫЕ СЛОВА

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

1 ВВЕДЕНИЕ

DEBS Grand Challenge (GC) — это конкурс программирования, интегрированный в ежегодную ACM Международную конференцию по распределенным и событийно-ориентированным системам (DEBS) начиная с DEBS 2011. Гранд-челлендж мотивирует участников как из академической, так и из промышленной среды решать практические задачи путем создания хорошо спроектированных и эффективных решений. Представленные решения проходят оценку с использованием реальных данных, оцениваясь на основе их дизайна, производительности, эффективности, простоты повторного использования, отказоустойчивости и адаптации к различным проблемам.

В этом году выпуск DEBS GC посвящен анализу реальных телеметрических данных, предоставленных Backblaze?. Набор данных, используемый для Гранд-челленджа, содержит детальные телеметрические данные о более чем 200 тыс. жестких дисках в дата-центрах, управляемых Backblaze. Цель конкурса — непрерывно вычислять кластеры схожих дисков по мере поступления новых данных. Такой анализ может быть полезен для быстрого выявления групп дисков с высокой вероятностью отказа и реализации стратегий предиктивного обслуживания.

Более конкретно, от участников требуется: (1) Преобразовать входные данные путем нормализации значений атрибутов жестких дисков в сопоставимые диапазоны; (2) Вычислить статистику, основанную на времени, об отказах групп дисков; (3) Использовать нормализованные значения и статистику, основанную на времени, для вычисления кластеров дисков. Статистику и кластеры необходимо возвращать заинтересованным подписчикам, имитируемым платформой оценки Гранд-челленджа. Подписчики динамически меняют свои интересы, что требует от решений готовности предоставлять информацию об определенных дисках по запросу.

Решения участников размещаются на инфраструктуре оценки DEBS для обеспечения справедливой оценки. Мы предоставляем всем участникам одинаковые вычислительные ресурсы для оценок. Более того, отказоустойчивость решений была введена как строгое нефункциональное требование (NFR) в DEBS GC 21 [8]. Мы вводим новый тип оценки с внедрением сбоев в Challenger, который внедряет сбои инфраструктуры для оценки отказоустойчивости решений. Наконец, мы впервые с момента введения Challenger перешли на новую инфраструктуру оценки. Мы документируем наш опыт в этой статье.

Остальная часть статьи структурирована следующим образом: Раздел 2 предоставляет справочную информацию о телеметрических данных для жестких дисков. Раздел 3 представляет набор данных телеметрии о жестких дисках, управляемых Backblaze. Раздел 4 обсуждает, как мы анализировали, очищали и готовили данные для конкурса. Раздел 5 формулирует проблему, определенную для DEBS 2024 Grand Challenge. Раздел 6 описывает улучшения в Challenger в этом году и документирует наш опыт перехода на новую инфраструктуру [5, 8]. Наконец, Раздел 7 завершает статью, также предоставляя статистику об участии в DEBS 2024 Grand Challenge.

2 ПРЕДЫСТОРИЯ

Жесткие диски являются одними из наиболее часто выходящих из строя компонентов в современных дата-центрах и облачных инфраструктурах [7]. Чтобы предвидеть отказы и избежать недоступности и потери данных, в литературе было предложено несколько моделей прогнозирования отказов [2, 4, 6, 10]. Большинство этих моделей полагаются на данные технологии Self-Monitoring Analysis and Reporting Technology (SMART) [1], которая является стандартной технологией для автоматического мониторинга состояния жестких дисков и сообщения о потенциальных проблемах.

Как отмечено в литературе [2], реализации SMART могут различаться в зависимости от конкретного производителя диска. Таким образом, важно определять модели, учитывая большое количество дисков. Следуя этому руководству, DEBS GC 2024 использует большой набор данных, предоставленный Backblaze (см. Раздел 3).

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

3 НАБОР ДАННЫХ

Данные, предоставленные для DEBS Grand Challenge 2024, основаны на данных SMART и дополнительных атрибутах, собираемых Backblaze ежедневно в течение шести месяцев (начиная со второго квартала 2023 года). Набор данных содержит события, охватывающие более 200 тыс. жестких дисков, с ежедневными обновлениями об их статусе.

События предоставляются через gRPC2 API, используя определение Protocol Buffers3 ниже.

Входные данные предоставляются партиями (Batches) из DriveState. Каждый DriveState представляет состояние жесткого диска в данный момент времени. Он содержит метку времени считывания (атрибут date), серийный номер и модель жесткого диска, флаг failure, который устанавливается в true, если диск вышел из строя, и идентификатор хранилища (vault), где находится диск (атрибут vault_id). Наконец, атрибут readings — это список значений для 34 атрибутов SMART. Мы приводим их в Таблице 1 вместе с кратким описанием.

Каждая партия содержит порядковый номер seq_id, флаг last, который устанавливается в true только для последней партии, чтобы указать, что тест завершен. Каждая партия содержит события, которые все принадлежат одному дню: флаг day_end устанавливается в true в последней партии дня. Атрибуты vault_ids и cluster_ids используются для запроса ответов на запросы (см. Раздел 5).

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

4 АНАЛИЗ ДАННЫХ

На основе исходных данных в наборе данных BackBlaze мы провели некоторый анализ данных для создания входных данных для DEBS GC, так как исходные данные не были пригодны для непосредственного использования в качестве источника для алгоритма кластеризации. Таким образом, мы выполнили следующие шаги очистки и подготовки данных: (1) мы выбрали атрибуты SMART, наиболее relevant для текущей задачи; (2) мы проанализировали их распределение, чтобы (3) применить незначительные преобразования данных для улучшения качества кластеризации; (4) мы экспериментально вывели хорошие начальные кластеры для алгоритма.

4.1 Выбор атрибутов

Чтобы выбрать наиболее relevant атрибуты SMART, мы работали с уменьшенной частью данных (от 1 до 10 дней данных в зависимости от задачи). В наборе данных BackBlaze большинство дисков сообщают значения только для небольшого подмножества доступных атрибутов SMART. По этой причине мы решили оставить только атрибуты SMART, которые присутствуют как минимум в 1% дисков в наборе данных. Мы установили это значение экспериментально, чтобы сбалансировать две силы: (i) сохранить атрибуты, которые присутствуют не на всех дисках, но присутствуют в большом классе дисков, например, атрибуты, которые relevant для всех (и только для) SSD; (ii) отбросить атрибуты, которые присутствуют только в конкретных моделях. Сохранение последних негативно повлияло бы на качество алгоритма кластеризации. В результате этого процесса мы выбрали 34 атрибута SMART, перечисленных в Таблице 1.

4.2 Анализ распределения

После выбора набора relevant атрибутов SMART мы провели статистический анализ, чтобы направить шаги предварительной обработки данных. Для каждого атрибута SMART в наборе данных BackBlaze были доступны как исходные, так и нормализованные значения. Нормализованные значения закодированы как дискретные числа от 0 до 100, которые не представляют физическое измерение, а являются интерпретацией исходного значения качественным образом. Таким образом, нормализованные значения всегда предоставляют меньше информации о фактическом состоянии дисков, поэтому мы решили использовать только исходные измерения для всех атрибутов.

После этого решения мы изучили распределение значений атрибутов, рассматривая две стратегии нормализации. Обозначим \( f_{k}^{i} \) как \( i^{\text{th}} \) показание признака \( f_{k} \), \(\min(f_{k}) \) как минимальное значение \( f_{k} \) во всех показаниях, и \(\max(f_{k})\) как максимальное значение \( f_{k} \) во всех показаниях.

(1) Линейная: начинается с исходных показаний SMART и вычисляет norm\( (f_{k}^{i}) = \frac{f_{k}^{i}-\min(f_{k})}{\max(f_{k})-\min(f_{k})} \)

(2) Логарифмическая: начинается с исходных показаний SMART и вычисляет lognorm\( (f_{k}^{i}) = \frac{\ln(f_{k}^{i+1})}{\ln(\max(f_{k}))} \)

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

В результате нашей оценки мы решили применить логарифмическую нормализацию к атрибутам SMART 4, 7, 12, 174, 183, 191, 192, 193 и линейную нормализацию для всех остальных атрибутов (см. Таблицу 1).

4.3 Подготовка данных

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

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

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

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

4.4 Параметры алгоритма кластеризации

Алгоритм кластеризации, используемый в конкурсе, является потоковой версией K-Means. Соответственно, чтобы определить количество и начальный набор центроидов для этого алгоритма, мы выполнили автономный алгоритм K-Means, используя реализацию Parallel K-Means++, как описано в [3].

Мы провели несколько экспериментов, изменяя количество K центроидов. Для каждого значения K мы выполнили 20 запусков с максимумом 100 итераций и допуском 0.001, и мы рассмотрели запуск, который минимизирует сумму квадратов евклидовых расстояний до ближайшего центроида для всех наблюдений. Чтобы выбрать K, мы затем качественно оценили результаты кластеризации, используя стохастическое вложение соседей с t-распределением (t-SNE) [9]. Мы присвоили каждому показанию цвет на основе его ближайшего центроида, затем мы посмотрели на 2D проекцию t-SNE, чтобы оценить качество кластеров. В результате этого процесса мы остановились на инициализации с использованием 50 центроидов, так как это давало кластеры хорошего качества и также позволяло захватывать небольшие кластеры, как показано на Рисунке 1.

Начальные центроиды, предоставляемые участникам, являются результатом лучшего выполнения автономного алгоритма K-Means с использованием 50 центроидов.

5 ОПРЕДЕЛЕНИЕ ПРОБЛЕМЫ

DEBS GC 2024 просит участников анализировать данные жестких дисков для определения кластеров схожих дисков. Информация о кластеризации может использоваться для идентификации дисков, которые более склонны к отказам, и подразумевает стратегии предиктивного обслуживания. Конкретно, конкурс состоит из двух шагов, или *запросов*:

* Q1. Вычислить ежемесячную статистику об отказах жестких дисков; * Q2. Использовать нормализованные данные SMART и статистику отказов для объединения схожих дисков в кластеры.

5.1 Запрос Q1: ежемесячные отказы

Запрос Q1 включает вычисление количества отказов, произошедших в каждом хранилище за последний месяц.

Более формально, обозначим \(V\) множество хранилищ и \(D_{v}\) множество жестких дисков, принадлежащих хранилищу \(v\in V\). Мы говорим, что отказ происходит в хранилище \(v\in V\) всякий раз, когда мы получаем событие состояния о диске \(d\in D_{v}\), в котором флаг failure установлен в true.

Обозначим \(\omega\) скользящее окно размером 30 дней и шагом 1 день. Запрос Q1 требует вычисления для каждого хранилища \(v\in V\) количества отказов \(NF_{v}^{\omega}\), произошедших в хранилище \(v\) в пределах окна \(\omega\). Таким образом, в данный день \(i\), \(NF_{v}^{\omega(i)}\) — это количество отказов для хранилища \(v\) в окне, которое начинается в день \(i-31\) (включительно) и заканчивается в \(i-1\) (включительно).

Как обсуждалось в Разделе 3, участники получают данные партиями, где каждая партия \(b\) содержит события жестких дисков, которые происходят в один и тот же день \(i\). Каждая партия \(b\) дополнительно содержит набор \(V_{b}\) из 5 хранилищ.

При получении партии \(b\) для дня \(i\) участники должны вернуть количество отказов \(NF_{v}^{\omega(i)}\) для каждого хранилища \(v\in V_{b}\).

Заметим, что, поскольку \(\omega(i)\) относится к показаниям до дня \(i-1\), результаты для каждой партии могут быть вычислены исключительно на основе прошлых данных, не дожидаясь всех партий, содержащих информацию о дне \(i\). Участники могут предположить, что первое окно \(\omega(0)\) закрывается в день \(i=0\) и что нет отказов ни для какого дня \(i<0\).

5.2 Запрос Q2: алгоритм кластеризации

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

Более формально, обозначим \(C\) множество кластеров. Каждый кластер \(c\in C\) включает набор жестких дисков \(D_{c}\).

Состояние каждого диска \(d\in D_{c}\) идентифицируется значениями \(\langle v_{0},\ldots,v_{n}\rangle\), связанными с признаками \(F=\langle f_{0},\ldots,f_{n}\rangle\). Мы рассматриваем \(n=35\) признаков: для диска \(d\), принадлежащего хранилищу \(v\in V\), мы рассматриваем 34 значения SMART (см. Таблицу 1) и количество отказов \(NF_{v}^{\omega(i)}\), произошедших в хранилище \(v\) (как вычислено в запросе Q1). В любой момент времени диск \(d\) идентифицируется последними полученными значениями SMART и количеством отказов \(NF_{v}^{\omega(i)}\), произошедших за последние 30 дней.

Значения SMART нормализуются в диапазоне \([0,1]\). В зависимости от конкретных атрибутов нормализация выполняется с использованием либо линейного масштабирования, либо логарифмического масштабирования. Нормализацию необходимо вычислять участникам, в то время как исходные диапазоны (минимальное и максимальное значение) и тип нормализации (линейный или логарифмический) для каждого атрибута задаются и получены с помощью процедуры, обсуждаемой в Разделе 4.3.

Значения, связанные с признаками, размещают диски в многомерном пространстве, где каждый признак представляет собой измерение в пространстве. Мы обозначаем как *центроид* \(\mu_{c}\) кластера \(c\in C\) среднюю позицию всех дисков \(d\in D_{c}\). Мы вычисляем среднюю позицию, используя евклидово расстояние в 35-мерном пространстве признаков.

При получении новой партии \(b\), содержащей обновления о состоянии набора дисков \(D_{b}\), участникам необходимо выполнить следующие вычисления для каждого диска \(d \in D_{b}\), принадлежащего хранилищу \(v\).

(1) Получить количество отказов \(NF_{v}^{\omega(i)}\) в его хранилище.

(2) Нормализовать значения 35 признаков — 34 показаний SMART плюс количество отказов в хранилище.

(3) Назначить диск ближайшему кластеру \(c \in C\), то есть кластеру с ближайшим центроидом к \(d\).

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

Напомним, что если партия \(b\) является последней для данного дня \(i\), ее флаг day_end установлен в true (см. Раздел 3). Это работает как водяной знак и указывает, что любые будущие партии будут содержать информацию только о днях после \(i\). При получении партии \(b\) с установленным флагом day_end в true участники должны обновить позиции центроидов для каждого кластера \(c \in C\) средними координатами всех дисков, в настоящее время назначенных на \(c\).

Каждая партия \(b\) входных данных будет содержать набор идентификаторов кластеров (кластеры идентифицируются порядковым номером) \(C_{b}\). Участники должны вернуть количество дисков, связанных с каждым кластером \(c \in C_{b}\).

6 ИНФРАСТРУКТУРА ОЦЕНКИ

Мы использовали Challenger для оценки решений участников. Сообщество DEBS использует Challenger для оценки решений с DEBS GC 21 [8]. Его архитектура и технические детали задокументированы в предыдущих статьях DEBS GC [5, 8]. Вкратце, Challenger состоит из веб-портала и gRPC API. Участники используют веб-портал для доступа к своей личной информации, такой как токены API, ключи доступа к инфраструктуре и контактные данные. Веб-портал также отображает текущую таблицу лидеров наиболее производительных решений, а также полную историю оценок вошедшего пользователя. Участники используют gRPC API для получения данных и тестирования своих решений. Кроме того, мы предоставляем инфраструктуру оценки для обеспечения справедливой оценки. Мы предоставляем участникам виртуальные машины (ВМ) для запуска их решений. Это обеспечивает одинаковую задержку передачи по сети и одинаковое количество ресурсов для всех участников. Несколько ВМ способствуют разработке распределенных решений.

В этом году мы предоставили две ВМ для каждого участника, где каждая ВМ содержит 4 ядра ЦП, 8 ГБ оперативной памяти и 10 ГБ дискового пространства. Мы использовали libvirt и QEMU для виртуализации ресурсов хост-машины. Хост-машина имеет 2 процессора Intel Xeon Silver 4110 2.10 ГГц, 142 ГБ оперативной памяти и 11 ТБ дискового пространства. На ней работает Ubuntu 24.04, Azul Zulu OpenJDK 21 и Python 3.10. Машина подключена к интернету по каналу 15 Гбит/с.

Миграция инфраструктуры. С момента своего введения инфраструктура оценки размещалась на вычислительном кластере Кафедры распределенных информационных систем и управления данными Технического университета Мюнхена. В этом году мы перенесли инфраструктуру оценки на частную вычислительную инфраструктуру. Мы используем netplan? для настройки сетевых конфигураций ВМ. Из-за изменения сетевой инфраструктуры нам пришлось перенастроить сетевые скрипты, что привело к увеличению рабочей нагрузки. Кроме того, ВМ предоставляются вручную для всех участников. Независимое от сети автоматическое развертывание ресурсов значительно сократит рабочую нагрузку организаторов в будущем.

6.1 Оценка отказоустойчивости

В этом году сообщество DEBS сделало первый шаг к оценке отказоустойчивости (FTE) решений. Отказоустойчивость (FT) была введена как строгое нефункциональное требование в DEBS GC 21 [8]. Отказоустойчивость решений поощрялась путем акцента на использовании фреймворков, разработанных признанными фондами открытого исходного кода?. Однако эмпирическая проверка FT не проводилась. С этой целью мы вводим новый тип оценки, FTE.

Мы оснастили Challenger сервисом внедрения сбоев. Он внедряет сетевые сбои в инфраструктуру оценки. Если участник запускает FTE, Challenger делит оценку на три фазы, каждая из которых состоит из одной трети всех партий. В контрольной фазе в инфраструктуру оценки не внедряется ошибка. В фазе сбоя Challenger внедряет сетевую задержку на одну из ВМ участника. Challenger знает соответствие ВМ, назначенных участникам. Он случайным образом выбирает одну из ВМ участника и создает SSH-соединение с ВМ. После входа в систему он выполняет утилиту? для имитации сетевой задержки в 500 мс на исходящем трафике сети ВМ. В идеале система должна продолжать обработку партий, и сервис удаляет сбой из инфраструктуры после получения двух третей партий, чтобы начать фазу восстановления. Однако может случиться так, что решение невосстановимо аварийно завершится при внедрении сбоя, оставляя инфраструктуру в фазе сбоя. Для этого сервис создает службу таймера для каждого внедрения сбоя и удаляет сбой из инфраструктуры по истечении тайм-аута, если он еще не был удален. Challenger записывает и отображает пропускную способность и задержку решения отдельно для каждой фазы. Измерения позволяют участникам и организаторам оценить оптимальную, отказоустойчивую производительность решения и производительность восстановления. FTE был представлен как бонус для участников в качестве бета-релиза сервиса.

Статистика. Всего на инфраструктуре было выполнено 1290 тестов, отправлено 2,7 млн отдельных партий и результатов для оценки. Для оценки отказоустойчивости было отправлено 75 тыс. отдельных результатов. Challenger обработал 780 ГБ трафика за последние два месяца конкурса.

Уроки. Процесс внедрения сбоев медленный, так как требует создания SSH-соединения и выполнения команд на виртуальных машинах участников. Наши измерения показывают, что внедрение сбоя может занять до двух секунд. Более быстрый процесс внедрения сбоев улучшил бы пропускную способность системы. Наконец, мы внедряли сбои в одну из ВМ, чтобы изолировать падение производительности отдельных компонентов распределенного решения. Однако несколько участников реализовали нераспределенные решения, что снижает доступность FTE до 50%. Сервис внедрения сбоев должен быть улучшен для внедрения сбоев только в используемые ВМ.

7 ЗАКЛЮЧЕНИЕ

В этой статье представлен выпуск 2024 года DEBS Grand Challenge (GC), конкурса программирования, который оценивает решения на основе их дизайна, производительности и нефункциональных характеристик. DEBS GC 2024 посвящен анализу реальных телеметрических данных. Мы обсудили, как мы подготовили данные, запросы и как мы анализировали представленные решения в рамках платформы оценки Challenger.

БЛАГОДАРНОСТИ

Авторы хотели бы поблагодарить Эндрю Клейна из Backblaze, Inc. за его поддержку в максимальном использовании телеметрических данных Backblaze и Арне Хёрманна из Infront Quant AG за его помощь в определении рамок конкурса этого года. Мы также признательны Кафедре децентрализованных информационных систем и управления данными Технического университета Мюнхена и Кристофу Добландеру за предоставление нам ресурсов для размещения Challenger. Авторы несут полную ответственность за содержание этой статьи. Мнения, высказанные в данной статье, принадлежат исключительно авторам и не обязательно отражают позицию организаций, с которыми они связаны.

Список литературы

1. Bruce Allen. 2004. Monitoring hard disks with smart. *Linux Journal* 2004, 117 (2004), 9.
2. Nicolas Aussel, Samuel Jaulin, Guillaume Gandon, Yohan Peierlin, Erica Faoili, and Sophie Chabridon. 2017. Predictive Models of Hard Drive Failures Based on Operational Data. In *IEEE International Conference on Machine Learning and Applications (ICMLA '17)*. 619-625. https://doi.org/10.1109/ICMLA.2017.00-92
3. Bahman Bahmani, Benjamin Moseley, Andrea Vattani, Ravi Kumar, and Sergei Vassilvitskii. 2012. Scalable k-means++. *Proc. VLDB Endow.* 5, 7, 622-633. https://doi.org/10.14778/2180912.2180915
4. Anhui Bai, Mingjin Chen, Siyuan Peng, Guojun Han, and Zhijing Yang. 2022. Attention-Based Bidirectional LSTM With Differential Features For Disk RUL Prediction. In *International Conference on Electronic Information and Communication Technology (ICEICT '22)*. 684-689. https://doi.org/10.1109/ICEICT55736.2022.906829
5. Sebastian Frischbier, Jawad Tahir, Christoph Doblander, Arne Hormann, Ruben Mayer, and Hans-Arno Jacobsen. 2022. Detecting trading trends in financial tick data: the DEBS 2022 grand challenge. In *Proceedings of the 16th ACM International Conference on Distributed and Event-Based Systems* (Copenhagen, Denmark) *(DEBS '22)*. ACM, New York, NY, USA, 132-138. https://doi.org/10.1145/3524860.3539645
6. Qinda Hai, Shuangwang Zhang, Chang Liu, and Guojun Han. 2022. Hard Disk Drive Failure Prediction Based on GRI Neural Network. In *IEEE/CIC International Conference on Communications in China (ICCC '22)*. 696-701. https://doi.org/10.1109/ICCC5548.2022.9880716
7. Bianca Schroeder and Garth A. Gibson. 2007. Disk failures in the real world: what does an MTTF of 1,000,000 hours mean to you?. In *Proceedings of the 5th USENIX Conference on File and Storage Technologies* (San Jose, CA) *(FAST '07)*. USENIX Association, USA, 1-es.
8. Jawad Tahir, Christoph Doblander, Ruben Mayer, Sebastian Frischbier, and Hans-Arno Jacobsen. 2021. The DEBS 2021 grand challenge: analyzing environmental impact of worldwide lockdowns. In *Proceedings of the 15th ACM International Conference on Distributed and Event-Based Systems* (Virtual Event, Italy) *(DEBS '21)*. ACM, New York, NY, USA, 136-141. https://doi.org/10.1145/3465480.346536
9. Laurens van der Maaten and Geoffrey Hinton. 2008. Visualizing Data using t-SNE. *Journal of Machine Learning Research* 9, 86 (2008), 2579-2605. http://jmlr.org/papers/v9/vandermaaten08a.html
10. Yang Zhou, Fang Wang, and Dan Feng. 2022. A Disk Failure Prediction Method Based on Active Semi-supervised Learning. *ACM Trans. Storage* 18, 4, Article 35 (nov 2022), 33 pages. https://doi.org/10.1145/3523699

О себе Реферат Индивидуальный раздел