Учебное пособие 2238

Информация об авторах

Голиков Александр Сергеевич – студент, 4 курс, Воронежский государственный технических университет (394006, Россия, г. Во-

ронеж, ул. 20-летия Октября, 84), e-mail: sanor.2000@gmail.com

Минакова Ольга Владимировна - кандидат технических наук,

доцент кафедры систем управления и информационных технологий в строительстве, Воронежский государственный технических университет (394006, Россия, г. Воронеж, ул. 20-летия Октября, 84), e-mail: olgmina@gmail.com

Information about the authors

Alexander S. Golikov, student, 4th year, Voronezh State Technical University, (394006, Russia, Voronezh, 20 let Oktyabrya st., 84),

e-mail: sanor.2000@gmail.com

Olga V. Minakova, Candidate of Technical Sciences, Associate Professor of the Department of Control Systems and Information Technologies in Construction, Voronezh State Technical University (394006, Russia, Voronezh, 20 Let Oktyabrya St., 84), e-mail: olgmina@gmail.com

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

ных может помочь решить множество профессиональных задач. Наука о данных занимается большим спектром вопросов. Данные и их интеллектуальный анализ нужны всем. Компании и госорганизации строят стратегии работы с данными, видят в данных свой ключевой актив, а в умении извлекать из них ценность – залог роста и развития в цифровой экономике [1].

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

Когда говорят о Big Data, упоминают правило VVV – три признака, которыми большие данные должны обладать:

1.Volume – объем (данные измеряются по величине физического объема документов).

2.Velocity – данные регулярно обновляются, что требует их постоянной обработки.

3.Variety – разнообразные данные могут иметь неоднородные форматы, быть неструктурированными или структурированными частично.

В России под Big Data подразумевают также технологии обработки, а в мире – лишь сам объект исследования.

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

количество раз [2].

В работе использована программная платформа Node.js, основанная на движке Google Chrome -V8, который умеет компилировать JavaScript код в машинный код.. Node.js предназначена для создания масштабируемых распределѐнных сетевых приложений, таких как веб-сервер [3].

Для сбора данных была написана программа на Node.js, которая в автоматическом режиме каждую минуту отправляла запросы на API биржи и в течение заданного времени собирала данные о новых сделках валютных пар.

Для исследований выбраны следующие валютные пары: BNB/BTC, ETH/BTC,

LTC/BTC, DAS/HBTC, XMR/BNB.

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

Дальнейший анализ массива из 5000 данных выполнен в ПО Statistica.12 по алгоритму - C&RT (Общие деревья). Деревья решений являются одним из наиболее эффективных инструментов интеллектуального анализа данных и предсказательной аналитики, которые позволяют решать задачи классификации и регрессии [4].

Алгоритм C&RT (Общие деревья) предназначен для построения бинарного дерева решений. Бинарные деревья также

называют двоичными, значит, что каждый узел дерева при разбиении имеет только двух потомков. Для алгоритма C&RT (Общие деревья) «поведение» объектов выделенной группы означает долю модального значения выходного признака. Выделенные группы – те, для которых эта доля достаточно высока. На каждом шаге построения дерева правило, формируемое в узле, делит заданное множество примеров на две части — часть, в которой выполняется правило (по-

каждого приложения в центре обработки данных в будущем, что поможет разумно распределять виртуальные машины по аппаратным платформам, исходя из прогнозируемых потребностей в аппаратных ресурсах [8, 9]. Данный подход позволит эффективно распределять поступающие ВМ по узлам ЦОДа, а также превентивно управлять активностью серверов, отключая простаивающие и включая те, которые соответствуют определенным требованиям.

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

Можно выделить три направления моделирования нагрузки: использование графов [11, 12], нейросетевой подход [13] и моделирование на основе шаблонов нагрузки

[14].

Реализация модели рабочей нагрузки ЦОДа, основанная на понятии графов, предполагает, что входная рабочая нагрузка может быть обработана любым вычислительным узлом (ИТ-оборудованием) [11, 12]. Пусть узлы (N) – общее число вычислительных узлов, но в любой момент времени для обработки рабочей нагрузки доступны толь-

ко активные узлы (n). Свободные узлы (nidle) представляют собой ИТ-ресурсы, имеющие-

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

временем j и обозначается Win,DC(j). Она распределяется между активными узлами через

коэффициент распределения. Процент или относительный объем рабочей нагрузки, распределенной для каждого активного узла i во время j, представляется как S(i,j). Скорость поступления рабочей нагрузки в любой активный узел является произведением Win,DC(j) и S(i,j). Скорость отправки рабочей нагрузки зависит от скорости обработки PR(i) и длины очереди (количества задач, ожидающих обработки). Скорость обработки (PR) – это максимальное количество заданий, которое ИТ-оборудование может выполнить за единицу времени.

поступления рабочей нагрузки на узел i в момент времени j.

( ) ( ) – скорость отправки рабочей нагрузки в узел i в момент времени j.

нейронных сетей. Так, в [13] описан метод, заключающийся в классификации типовых задач ЦОДа с использованием k-средних (kM) с последующим построением искусственной нейронной сети (ANN) для каждой категории. Конфигурация ANN включает Q входов, обозначенных [N(xjq)], q=Q, а также нормализованные атрибуты и параметры задачи моделирования j. Используется один скрытый слой, что позволяет улучшить запоминание обучающих данных. Кроме того, общие параметры обучения нейронной сети, включая количество скрытых слоев и их единиц, скорость обучения и время обучения, определяются методом проб и ошибок.

Еще один способ – выделение профилей рабочей нагрузки. Данная методология разделяется на два отдельных этапа: первый

– это определение модели, которая будет использоваться для симуляции рабочей нагрузки облака на основе анализа производного набора данных (трассировки). Три важные характеристики, которые определяют поведение пользователя в журнале трассировки: скорость отправки запроса , запрошенный объем ресурсов ЦП и оперативной памяти. Скорость отправки – это частное от деления количества отправок на временной интервал журнала трассировки. Запрашиваемые объемы ЦП и памяти представляются как нормализованный вектор значений, взятых непосредственно из журнала событий задачи в журнале трассировки.

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

дачи, которые выполняют пользователи, являются длина x и среднее использование ресурсов ЦП и памяти . Хотя длина определяется как общий объем работы, которую необходимо вычислить, среднее использование ресурсов – это среднее значение всех измерений потребления, записанных в журнале трассировки для каждой задачи.

Для этой модели предлагаются следующие переменные:

пользователя, которое задается вероятностью его появления P(ui).

профиля задачи, которое задается ее вероятностью P(ti), обусловленной вероятностью

P(uj).

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

пользователей, * ( ) ( ) ( )+ – каждый про-

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

* ( ) ( ) ( )+ – каждый профиль задачи, определенный из анализа трассировки.

бранным параметрам и группируются вокруг центроидов кластеров.

В качестве гибкого шаблона для проведения численного эксперимента предлагается использовать программную платформу CloudSim. На рисунке 1 показана ее структура.

Datacenter, DatacenterCharacteristics и VmAllocationPolicy содержит набор физиче-

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

DatacenterCharacteristics. Для каждого со-

зданного Центра обработки данных должен быть определен экземпляр

VmAllocationPolicy. Этот объект определяет,

какой хост будет принимать каждую виртуальную машину. Фреймворк предоставляет реализацию VmAllocationPolicySimple-

политику наихудшего соответствия, которая выделяет виртуальные машины на Хост с наиболее доступными процессорными ядра-

ми (Pes).

Host, Pe и VmScheduler. Хост представ-

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

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

VmSchedulers, такие как time - и space-shared,

которые могут быть использованы. DatacenterBroker представляет собой

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

Vm и CloudletScheduler. объект Vm

представляет собой виртуальную машину, которая работает внутри хоста и будет исполнять приложения (Cloudlets). CloudletScheduler определяет, как планируется одновременное выполнение нескольких приложений внутри виртуальной машины.

Cloudlet и UtilizationModel: Cloudlet