CC BY
42
Оценка оперативности передачи больших данных на примере базы данных PostgreSQL, платформы На^ор и системы 8доор
магистр О. В. Баданина, к.т.н. С. И. Гиндин Петербургский государственный университет путей сообщения Императора Александра I
Санкт-Петербург, Россия olgagaykova@gmail.com, sgindin@gmail.com
Аннотация. Рассматривается оценка характеристик оперативности передачи больших данных. Для этого используются демонстрационная база данных PostgreSQL как источник данных, платформа Hadoop как инструмент хранения данных, а также инструмент передачи данных Sqoop. Результаты экспериментов демонстрируют изменение параметров, характеризующих оперативность передачи данных при импорте, в зависимости от их объема и типа. Полученные результаты экспериментов могут быть использованы для прогнозного расчета характеристик оперативности обработки больших данных. Такой прогноз можно провести на основе использования полученных характеристик оперативности в качестве обучающей выборки для нейронной сети. Кроме того, прогноз оперативности обработки больших данных целесообразно проводить с помощью моделей многоканальных систем массового обслуживания с разогревом и охлаждением, а также сетей массового обслуживания. Расчет показателей оперативности перемещения больших данных в различных режимах функционирования информационной инфраструктуры целесообразно выполнять для оптимального аварийного восстановления хранилищ данных и обеспечения требуемой киберустойчивости цифровых платформ в целом.
Ключевые слова: большие данные, оперативность передачи данных, СУБД PostgreSQL, платформа Hadoop, инструмент передачи данных Sqoop, программная платформа Map-Reduce.
Введение
В современном мире каждый день увеличивается количество разработок в сфере информационных технологий, которые интегрируются в различные направления деятельности общества. В результате возрастают требования для решения новых задач, которые предполагают выработку огромных объемов данных.
Согласно прогнозу международной исследовательской консалтинговой компании IDC (International Data Corporation) [1], общий объем всех данных в мире изменится от 33 зеттабайт в 2018 году до 175 зеттабайт к 2025 году. Такой рост показателей связывают с увеличением количества умных гаджетов, роботов и устройств, окружающих нас каждый день, которые будут производить значительное количество данных.
С увеличением объема генерируемых человечеством данных увеличивается потребность в хранилищах для большого объема информации, а также в методах и средствах их обработки и анализа. Большая часть глобальных данных является неструктурированной или частично
д.т.н. А. Д. Хомоненко Петербургский государственный университет путей сообщения императора Александра I,
Военно-космическая академия им. А. Ф. Можайского Санкт-Петербург, Россия khomon@mail.ru
структурированной. Они могут быть представлены в различных форматах, например, это могут быть веб-журналы, видеозаписи, текстовые документы, машинный код, геопространственные данные и многое другое. Источники хранения этих данных также многообразны и могут располагаться как в организации, так и за ее пределами. В результате компании имеют огромные наборы данных, которые необходимо анализировать, получать результаты и делать выводы на их основе, но не имеют инструментов для проведения всех необходимых работ. Проблематика анализа больших данных представлена в работе [2].
Традиционные методы анализа информации не позволяют обеспечивать эффективную работу с очень большим объемом неструктурированных данных. Это связанно с тем, что часто большая часть генерируемой информации не представляет значительной важности для исследования и практического использования. Поэтому необходимо сначала извлечь ценную информацию, поскольку традиционные системы изначально разрабатывались для хранения релевантных данных и имеют ограничения масштабируемости. Традиционные решения обеспечивают работу со структурированными данными и позволяют структурировать пакеты исходных данных небольшого объема, затем выполняются обработка, хранение и анализ уже структурированных данных.
Указанные факторы, связанные с необходимостью качественной обработки огромных объемов неструктурированных данных, неэффективности традиционных методов, увеличением масштабности задач на предприятиях, привели к появлению и развитию технологий больших данных. В настоящее время с понятием «Big Data» тесно связывается характеристика технологий для их сбора, хранения, обработки, анализа, визуализации и использования.
Большие данные характеризуются следующими признаками:
- Volume — объем; означает, что анализируются большие массивы информации;
- Velocity — скорость; скорость накопления данных постоянно увеличивается;
- Variety — многообразие; данные могут быть представлены в разных форматах и взяты из разных источников.
Компании в области технологий больших данных
В настоящее время все большее число компаний используют технологии больших данных, поскольку с их
помощью анализ, обработка данных и прогнозирование становятся гораздо эффективнее, что позволяет корпорациям увеличивать свои доходы, оптимизировать работу и добиваться лучших результатов.
Существенный вклад в изучение технологий для больших данных вносят крупные мировые компании, они также занимаются обработкой и анализом данных и создают программно-аппаратные комплексы. Их можно разделить на несколько групп:
1. Поставщики инфраструктуры. Решают задачи хранения и предобработки данных, например: IBM, Microsoft, Oracle, SAP и другие.
2. Датамайнеры — разработчики алгоритмов, которые помогают заказчикам извлекать ценные сведения. Среди них Yandex Data Factory, «Алгомост», Glowbyte Consulting, CleverData и др.
3. Системные интеграторы — компании, которые внедряют системы анализа больших данных на стороне клиента: «Форс», «Крок» и др.
4. Потребители — компании, которые покупают программно-аппаратные комплексы и заказывают алгоритмы у консультантов. Это «Сбербанк», «Газпром», МТС, «Мегафон» и другие компании из отраслей финансов, телекоммуникаций, ритейла.
5. Разработчики готовых сервисов. Предлагают готовые решения на основе доступа к большим данным. Они открывают возможности Big Data для широкого круга пользователей.
Характеристика инструментальных средств
и технологий больших данных
Технологии, которые используются для сбора, обработки больших данных делятся на следующие группы: технологическое оборудование, сервисные услуги, программное обеспечение.
Для проведения исследования выбран инструмент обработки, относящийся к последней из перечисленных групп, а именно Hadoop — свободно распространяемый набор утилит, библиотек и фреймворк для разработки и выполнения распределенных программ, работающих на кластерах из сотен и тысяч узлов. Платформа Hadoop является основополагающей технологией, предназначенной для хранения и обработки больших данных. Описание принципов работы и преимуществ Hadoop представлено в работе [3].
В качестве среды подготовки данных для Hadoop рассматривается база данных PostgreSQL [4]. При работе с большими данными также рассматриваются NoSQL базы данных, в статье [5] проведено сравнение работы СУБД PostgreSQL и MongoDB. Основные различия заключаются в том, что PostgreSQL является свободным программным обеспечением, а то время как СУБД MongoDB тщательно разработана и имеет хорошую поддержку. При этом СУБД MongoDB опережает PostgreSQL для операций обновления и поиска неиндексированных данных. Но в то же время PostgreSQL имеет преимущество на операциях вставки данных. Применение СУБД MongoDB является оправданным решением для хранения редко изменяющихся и часто читаемых данных. Более подробный обзор технологий NoSQL приведен в работе [6].
Для исследования оперативности импорта данных в Hadoop источником передаваемых данных выбрана СУБД PostgreSQL, так как она является наиболее подходящей для проводимого исследования.
Для передачи данных на платформу Hadoop выбран Sqoop [7] — инструмент, предназначенный для передачи данных между Hadoop и реляционными базами данных. Sqoop действует как промежуточный уровень между Ha-doop и системами реляционных баз данных. Этот инструмент позволяет импортировать данные из реляционных СУБД в Hadoop, а затем экспортировать обработанные данные обратно в СУБД. Sqoop достаточно прост в использовании, он автоматизирует большую часть рассматриваемого процесса, обеспечивает отказоустойчивость, а также предоставляет интерфейс командной строки.
Исследование характеристик оперативности
передачи данных Исследование характеристик оперативности передачи данных производилось на примере демонстрационной базы данных [8], предоставляемой компанией Postgres Professional. Предметной областью выбранной базы данных являются авиаперевозки по России. Эта база данных представлена в трех версиях: данные по полетам за один месяц (small-database, обозначена как S-база), данные за три месяца (medium-database, обозначена как M-база), данные за год (big-database, обозначена как B-база). Состав базы и размерность можно проследить по таблице 1.
Таблица 1
Сводные данные о размерах БД и таблиц
Размеры БД и таблиц Назначение таблиц и БД
S-база M-база B-база
DataBase 300 МВ 700 МВ 2,5 GB БД в целом
Aircrafts 16 KB 16 KB 16 KB Самолеты
Airports 48 KB 48 KB 48 KB Аэропорты
Boarding_passes 31 MB 102 MB 427 MB Посадочные талоны
Booking 13 MB 30 MB 105 MB Бронирования
Flights 3 MB 6 MB 19 MB Рейсы
Seats 88 KB 88 KB 88 KB Места
Ticket_flights 64 MB 145 MB 516 MB Перелеты
В рамках исследования проведен единовременный импорт всех таблиц базы данных, каждой из трех версий, а также выполнен отдельный импорт каждой из таблиц базы данных. Несмотря на то, что таблицы Aircrafts, Airports, Seats одинаковы во всех вариантах, они, как и остальные таблицы, размер которых увеличивается в зависимости от размера базы, импортированы три раза для сравнения показателей [8].
Импорт данных исследовался с использованием парадигмы выполнения распределенных вычислений Map-Reduce [9]. Для импорта таблиц использовалась стандартная команда Sqoop [10]:
sqoop import -connect jdbc:postgresql://<имя хо-ста>/<имя базы данных>
--username<пользователь, под которым идет подключение к базе данных>
-password<пароль от пользователя> --taЫe<имя таблицы> -m 1
Для упрощения анализа по результатам импорта таблиц составлены сводные таблицы результатов. Первым параметром для сравнения является время передачи данных из таблиц (см. табл. 2). При этом можно увидеть, что показатели для таблиц S-базы и M-базы примерно одинаковы. Причиной этого является сравнительно небольшой объем данных, а также незначительная разница в объемах данных. В то же время для B-базы время передачи в 1,5 раза
Сводная таблица
больше, что является следствием того, что объем передаваемых данных вырос в 3-4 раза.
Таблица 2
Время передачи данных
S-база M-база B-база
Все таблицы 227 s 247 s 301 s
Aircrafts 44 s 50 s 32 s
Airports 34 s 31 s 66 s
Boarding_passes 34 s 34 s 52 s
Booking 36 s 34 s 69 s
Flights 32 s 33 s 40 s
Seats 31 s 30 s 38 s
Ticket_flights 36 s 37 s 57 s
Следующий показатель — Aggregate resource allocation (Совокупное распределение ресурсов), где MB-sec — совокупный объем памяти (в мегабайтах), выделенное приложением, умноженное на число секунд, в течение которого приложение выполнялось. Очередной показатель — vcore-seconds — агрегированное число vcores (виртуальных ядер), выделенных приложением, умноженное на число секунд, в течение которых приложение работало (см. табл. 3). При сравнении определяется та же закономерность, что и для времени передачи данных. Распределения ресурсов для таблиц S- и M-базы примерно равны, для В-базы показатели возрастают в 1,5-2 раза.
Таблица 3
о распределения ресурсов
S-база М-база В-база
Aircrafts 87 533 MB-sec / 59 vcore-sec 95 607 MB-sec / 64 vcore-sec 67 176 MB-sec /46 vcore-sec
Airports 71 092 MB-sec / 49 vcore-sec 64 187 MB-sec / 43 vcore-sec 124 551 MB-sec /84 vcore-sec
Boarding passes 72 255 MB-sec / 50 vcore-sec 74 437 MB-sec / 51 vcore-sec 118 027 MB-sec / 85 vcore-sec
Booking 75 056 MB-sec / 52 vcore-sec 71 981 MB-sec / 49 vcore-sec 140 808 MB-sec / 99 vcore-sec
Flights 68 304 MB-sec / 46 vcore-sec 69 303 MB-sec / 48 vcore-sec 83 870 MB-sec / 58 vcore-sec
Seats 65 145 MB-sec / 44 vcore-sec 63 916 MB-sec / 43 vcore-sec 81 566 MB-sec / 56 vcore-sec
Ticket flights 79 008 MB-sec / 55 vcore-sec 81 686 MB-sec /57 vcore-sec 130 015 MB-sec / 95 vcore-sec
В ходе экспериментов рассматривались группы показателей. Первая из них — File system counters (Метрики операций файловой системы). Из этой группы были рассмотрены следующие два показателя. File: Number of bytes written — общее количество байтов, записанных в локальную файловую систему; для всех операций импорта он примерно одинаков, идеального ожидаемого значения
Число запи
параметра нет, так как оно зависит от логики маппера (функция map). HDFS: Number of bytes written — общее количество байтов, записанных в определенную файловую систему. Так как параметр зависит от объема данных, то очевидно, что с возрастанием количества обрабатываемых данных увеличивается значение показателя. Результаты эксперимента отображены в таблице 4.
Таблица 4
ных байтов
БД aircrafts airports Boarding_passes Bookings flights seats ticket_flights
File system counters
File: Number of bytes written S-база 208 088 208 292 208 294 208 255 208 379 208 254 208 293
M-база 208 088 208 292 208 294 208 255 208 379 208 254 208 293
В-база 207 330 207 660 207 798 207 881 208 129 208 120 208 293
HDFS: Number of bytes written S-база 233 7 605 15 146 303 10 042 404 3 471 389 21 254 37 943 723
M-база 233 7 605 50 032 241 22 678 839 7 409 102 21 254 86 219 771
B-база 233 7 605 213 846 934 80 679 926 25 577 549 21 254 311 249 367
Следующие рассмотренные параметры принадлежат к группе Job Counters (Счетчики задачи). К ним относятся:
1. Total time spent by all maps in occupied slots (ms) — время выполнения map задач в миллисекундах. По полученным результатам для таблиц aircrafts, airports, seats (табл. 5) можно сказать, что время выполнения изменяется для каждой операции импорта, разница в интервале 5-7 тысяч миллисекунд. Такую погрешность можно объяснить выполнением операционной системой фоновых задач. Для оставшихся таблиц (boarding_passes, booking, flights, ticket_flights) прослеживается незначительное увеличение результатов при сравнении таблиц S-базы и M-базы, в то время как показатель для таблиц B-базы увеличивается в 2-2,5 раза.
2. Total time spend by all map task (ms) — общее время выполнения всех задач в миллисекундах, включая спекулятивные задачи. Согласно таблице 5 значение этого показателя имеет результаты, аналогичные предыдущему рассматриваемому параметру.
3. Total vcore-milliseconds taken by all map task. Этот счетчик измеряет ресурсы процессора, используемые всеми map-задачами. А именно: это агрегированное количество vcores, которое было назначено каждой map-задаче, умноженное на количество секунд, которое проработал mapper (картопостроитель).
4. Total megabyte-milliseconds taken by all map tasks — это счетчик, который измеряет ресурсы памяти, используемые всеми map-задачами. А именно: это совокупный объем памяти в мегабайтах, который был выделен каждой map-задаче, умноженное на количество секунд, которое проработал mapper.
Оба перечисленных параметра показывают схожие результаты (см. табл. 5). Для таблиц, размер которых изменяется, величина показателя увеличивается в 2,5-3 раза, в то время как для таблиц, размер которых не изменялся, значение колеблется, но разница является незначительной.
Таблица 5
задач
БД aircrafts airports Boarding_passes Bookings flights seats ticket_flights
Job Counters
Total time spent by all maps in occupied slots (ms) S-база 62 784 64 544 69 312 70 320 61 568 54 688 90 248
M-база 53 120 55 000 86 688 76 216 65 176 55 624 108 032
B-база 56 056 87 120 212 864 195 896 84 680 62 544 246 088
Total time spent by all map tasks (ms) S-база 7 848 8 068 8 664 8 790 7 696 6 836 11 281
M-база 6 640 6 875 10 836 9 527 8 147 6 953 13 504
B-база 7 257 10 890 26 608 24 487 10 585 11 568 30 761
Total vcore-milliseconds taken by all map tasks S-база 7 848 8 068 8 664 8 790 7 696 6 836 11 281
M-база 6 640 6 875 10 836 9 527 8 147 6 953 13 504
B-база 7 257 10 890 26 608 24 487 10 585 11 568 30 761
Total mega-byte-milliseconds taken by all map tasks S-база 8 036 352 8 261 632 8 871 936 9 000 960 7 880 704 7 000 064 11 551 744
M-база 6 799 360 7 040 000 11 096 064 9 755 648 8 342 528 7 119 872 13 828 096
B-база 7 431 168 9 151 360 27 246 592 25 074 688 10 839 040 11 845 632 31 499 264
Следующая группа — Map-Reduce Framework (метрики, управляемые Map Reduce Framework) — является наиболее обширной. Рассмотрим более подробно входящие в нее показатели.
Параметр Map input records обозначает количество входных записей, потребляемых всеми картами в задании. Он увеличивается для каждой успешной записи, прочитанной из RecordReader, и передается методу картографа. Записи, которые не удалось прочитать задачам карты, не включены в эти счетчики.
Параметр Map output records — это количество выходных записей карт, созданных всеми картами в задании. Он увеличивается для каждой успешной записи, записанной картографами. Записи, которые не удалось записать задачам карты, не включены в эти счетчики.
Значение этих двух параметров (при успешном импорте таблицы) равняется количеству строк в таблице. Сравнив исходные и полученные значения (табл. 6), можно сказать, что все данные таблиц были импортированы успешно.
Параметр GC time elapsed характеризует общее время, в миллисекундах, потраченное на сборку мусора. Выполняется в Java путем поиска неиспользуемых объектов (на которые больше нет ссылок) и освобождения памяти.
CPU time spent (ms) характеризует накопленное процессорное время для задачи в миллисекундах. Как и для других параметров, связанных со временем, для таблиц S-базы и M-базы разница в значениях незначительна и наблюдается увеличение времени в 1,1-1,3 раза, в то время как для B-базы этот показатель увеличивается в 2-2,5 раза.
Таблица 6
Число записей Map-Reduce Framework
БД aircrafts airports Boarding_passes Bookings flights seats ticket_flights
MAP-REDUCE Framework
Map input records S-база 9 104 579 686 262 788 33 121 1 339 1 045 726
M-база 9 104 1 894 295 593 433 65 664 1 339 2 360 335
B-база 9 104 7 925 812 2 111 110 214 867 1 339 8 391 852
Map output records S-база 9 104 579 686 262 788 33 121 1 339 1 045 726
M-база 9 104 1 894 295 593 433 65 664 1 339 2 360 335
B-база 9 104 7 925 812 2 111 110 214 867 1 339 8 391 852
GC time elapsed (ms) S-база 67 65 95 129 97 70 117
M-база 78 85 130 109 115 68 146
B-база 68 80 274 186 126 84 314
CPU time spent (ms) S-база 1 468 951 2 577 4 623 3 482 1 076 5 217
M-база 1 233 1 123 6 249 4 186 4 107 1 045 8 171
B-база 1 451 1 468 16 731 10 839 5 968 1 405 18 433
Параметр Bytes Written группы File output counters обозначает число байтов, записанное каждой задачей. Из приведенных в таблице 7 результатов видно, что число записанных байтов напрямую зависит от размера таблиц. Таким образом, мы видим, что для таблиц, имеющих одинаковый
Число запи
размер, число байтов не изменяется (таблицы aircrafts, airports, seats), в то время как для других таблиц с увеличением размерности увеличивается число записанных байтов в тех же пропорциях, в которых увеличивается размер таблиц.
Таблица 7
ных байтов
БД aircrafts airports Boarding_passes Bookings flights seats ticket_flights
File output counters
Bytes Written S-база 233 7 605 15146 303 10 042 404 3 471 369 21 254 37 943 723
M-база 233 7 605 50 032 241 22 678 839 7409 102 21 254 86 219 771
B-база 233 7 605 213 846 934 80 679 926 25 577 549 21 254 311 249 367
Таблица 8
Скорость передачи данных
БД aircrafts airports Boarding_passes Bookings flights seats ticket_flights
Import Job Base
Transferred S-база 233 bytes in 50,941 sec (4,5739 bytes/sec) 7,4268 KB in 40,7748 sec (186,5122 bytes/sec) 14,4446 MB in 40,005 sec (369,7368 KB/sec) 9,5772 MB in 44,4965 sec (220,4002 KB/sec) 3,3106MB in 38,7671 sec (87,4455 KB/sec) 20,7559 KB in 37,18 sec (571,6515 bytes/sec) 36,186 MB in 42,4297 sec (873,3128 KB/sec)
M-база 233 bytes in 56,5832 sec (4,1178 bytes/sec) 7,4268 KB in 36,655 sec (207,4753 bytes/sec) 47,7145 MB in 40,6875 sec (1,1727 MB/sec) 21,6282 MB in 40,8707 sec (541,8872 KB/sec) 7,0659 MB in 39,5649 sec (182,8757 KB/sec) 20,7559 KB in 35,3561 sec (601,1412 bytes/sec) 82,2256 MB in 43,0105 sec (1,9118 MB/sec)
B-база 233 bytes in 41,9235 sec (5,5577 bytes/sec) 7,4268 KB in 76,6164 sec (99,2608 bytes/sec) 203,9403 MB in 59,5601 sec (3,4241 MB/sec) 76,9424 MB in 80,4052 sec (979,8994 KB/sec) 24,3927 MB in 47,7911 sec 9522,6507 KB/sec) 20,7559 KB in 44,8828 sec (473,5443 bytes/sec) 296,8305 MB in 66,1472 sec (4,4874 MB/sec)
Зависимость скорости передачи данных от размера импортируемых данных
5,000000
со 4,000000
3,000000
2,000000
^ 1,000000 ф
а.
■= 0,000000
о о и
0,00 100,00 200,00 300,00 400,00
Размер таблицы MB
500,00
600,00
Рис. 1. Зависимость скорости передачи данных от размера импортируемых данных
В таблице 8 приведены значения скорости передачи данных для разных таблиц демонстрационной базы данных. По данным таблицы построен сводный график (рис. 1). По оси X располагается значение размера таблицы в MB, по оси Y располагается скорость передачи данных, измеряемая в MB в секунду. На основе анализа полученного графика сделаны следующие выводы:
- при увеличении размера импортируемых данных, скорость передачи данных возрастает;
- график зависимости схож с графиком зависимости степенной функции y = x Л (1/2);
- значительный рост скорости наблюдается при импорте данных размером от 105 до 516 МВ, скорость возрастает от 2 до 4,5 MB/sec. Для таблиц меньшего размера скорость передачи колеблется в промежутке между 0,000005 и 2 MB/sec;
- предполагается, что при передаче данных большего размера, скорость передачи будет расти, но с меньшей интенсивностью; для определения точных данных, необходимо большее количество экспериментов.
Выводы
По результатам исследования сделаны следующие общие выводы:
- для сравнительно малых размеров данных (таких как в S-базе и M-базе) время передачи меняется незначительно, в то время как для B-базы время передачи в 1,5 раза больше, что является следствием того, что объем передаваемых данных вырос в 3-4 раза по сравнению с M-базой;
- распределение ресурсов для таблиц S-базы и M-базы примерно равны, для В-базы показатели возрастают в 1,52 раза;
- значение параметров, относящихся к группе Job Counters, для таблиц S- и M-базы примерно равны, для В-базы показатели возрастают в 2-3 раза;
- из группы Map-Reduce Framework рассмотрен параметр CPU-time spent. Значение параметра для таблиц S- и M-базы примерно равны, для В-базы показатели возрастают в 2-2,5 раза;
- при увеличении размера импортируемых данных, скорость передачи данных возрастает. График зависимости схож с графиком зависимости степенной функции у = х Л (1/2). Значительный рост скорости наблюдается при импорте данных размером от 105 до 516 МВ, для данных меньшего размера скорость передачи данных изменяется незначительно.
Просуммировав результаты, можно сказать, что для данных небольших размеров (до 100 МВ) значение параметров оперативности импорта примерно одинаковы, но при возрастании размеров импортированных данных показатели возрастают. При увеличении размера данных в 3-4 раза, значения параметров вырастают в 2-3 раза. Такая зависимость прослеживается для всех выбранных параметров оперативности передачи данных.
Для более точных выводов и прогнозирования результатов необходимо провести исследования на наборах данных большего размера.
О прогнозном расчете оперативности обработки больших данных
Полученные результаты экспериментов могут быть использованы для прогнозного расчета характеристик оперативности обработки больших данных. В частности, такой прогноз можно провести на основе использования полученных в настоящей статье характеристик оперативности в качестве обучающей выборки для нейронной сети по аналогии с [11].
В качестве еще одного широко распространенного способа получения прогнозных оценок оперативности обработки больших данных можно отметить численные модели и методы теории массового обслуживания [12, 13]. Среди них можно выделить численные методы, основанные на применении распределений фазового типа для исследования многоканальных моделей систем массового обслуживания (СМО) с разогревом и охлаждением [14, 15].
На начальном этапе для оценивания оперативности обработки больших данных производится формирование исходных данных: определяются характеристики центра обработки больших данных по числу параллельных каналов,
производительности каналов, интенсивности поступления запросов на обработку данных. Применительно к архитектуре Map-Reduce, реализующей концепцию распределенных параллельных вычислений (рис. 2), можно воспользоваться моделями многоканальных СМО или моделями сетей массового обслуживания (СеМО).
разделение сортировка слияние
[kl, vl] by k [kl, Ivl, v2,VN]]
Рис. 2. Архитектура Map-Reduce
Для расчета характеристик оперативности с помощью модели многоканальной СМО осуществляется составление и решение системы уравнений баланса на уровне средних интенсивностей потоков заявок. Затем производится построение n-канальной модели СМО GI/G/PH/PH/n с «разогревом» и/или «охлаждением». В модели СМО такого типа подразумевается рекуррентный входящий поток и произвольное распределение длительности обслуживания заявок, а также произвольные распределения длительности «разогрева» и/или «охлаждения», аппроксимируемые с помощью одного из распределений фазового типа (Эрланга, гиперэкспоненциального, Кокса). Расчет характеристик таких СМО подразумевает составление векторно-матричных уравнений баланса переходов между состояниями вида
YoDO = Y0C0 + Y1B1 , YjDj = Yj-iAj-i + YjCj + yj+iBj+i , j = 1-2.....
Здесь A, B, C, D — матрицы интенсивностей переходов между микросостояниями модели многоканальной СМО в стационарном режиме, j — номер яруса диаграммы переходов, соответствующий числу заявок в системе в стационарном режиме, у — стационарное распределение вероятностей микросостояний системы.
Решение указанных уравнений основано на реализации расчетной схемы Гаусса — Зейделя и использовании итерационного алгоритма Такахаши — Таками. Характеристики модели многоканальной СМО рассчитываются и уточняются в соответствии с алгоритмом [12, 13].
Еще ряд подходов к прогнозному расчету характеристик оперативности обработки больших данных приводится в работах [16-18]. Достоинством предлагаемых авторами подходов является учет особенностей архитектуры Map-Reduce, часто используемой при обработке больших данных. Предложены методы расчета длительности обработки исходной заявки в многоканальной системе массового обслуживания с учетом разделения заявки на независимые подзадачи и их параллельной обработки с последующим объединением результатов. Длительность
указанного процесса представляется как распределение максимума случайных длительностей выполнения подзадач. В частности, в [16] получено точное решение по определению максимума общего времени обслуживания независимыми каналами с экспоненциальным распределением длительности и различной интенсивностью, а также аппроксимации для произвольного распределения.
В работе [17] результирующее распределение получено в матрично-экспоненциальной форме и позволяет вычислить ряд начальных моментов высших порядков. Этот метод характеризуется высокой вычислительной сложностью. Разработанный в [18] метод позволяет рассчитать начальные моменты распределения максимума случайных величин и может использоваться для определения времени обслуживания заявки в СМО с учетом процессов Split-Join (распараллеливания-объединения). Метод обладает сравнительно невысокой вычислительной сложностью при достаточной для практического применения точности получаемого решения.
Расчет показателей оперативности перемещения больших данных в различных режимах функционирования информационной инфраструктуры целесообразно выполнять для оптимального аварийного восстановления хранилищ данных и обеспечения требуемой киберустойчивости цифровых платформ в целом. Примеры постановок и решения подобного типа задач подробно рассматриваются в работах [19, 20].
Заключение
Полученные в процессе исследования результаты можно использовать на этапе проектирования информационных систем и баз данных, реализующих хранение и обработку больших данных. В частности, с их помощью можно получить прогнозные оценки оперативности процессов передачи хранимой и обрабатываемой информации. Здесь могут быть использованы, например, решения с помощью нейронных сетей, а также с помощью методов и моделей исследования систем сетей массового обслуживания. Расчет оперативности перемещения больших данных в различных режимах функционирования информационной инфраструктуры целесообразно выполнять для оптимального аварийного восстановления хранилищ данных и обеспечения требуемой киберустойчивости цифровых платформ.
Литература
1. Reinsel D. The Digitization of the World — From Edge to Core / D. Reinsel, J. Gantz, J. Rydning // IDC Whitepaper. No. US44413318. November 2018. 28 p.
URL: http://www.seagate.com/files/www-content/our-story/ trends/files/idc-seagate-dataage-whitepaper.pdf (дата обращения 10.06.2020).
2. Pehcevski J. Big Data Analytics: Methods and Applications. — Oakville, Canada: Arcler Press, 2019. — 428 p.
3. Data Processing in High-Performance Computing Systems / A. Adamov, A. I. Buranbaeva, S. I. Gindin, et al. // BIG DATA and Advanced Analytics = BIG DATA и анализ высокого уровня: Сб. материалов VI Международной научно-практической конференции (Республика Беларусь, Минск, 20-21 мая 2020 г.): в 3-х ч. — Ч. 1. — Минск: Бестпринт, 2020. — C. 33-52.
4. PostgreSQL — объектно-реляционная система управления базами данных — 31.07.2019 // WEB Creator.
URL: http://web-creator.ru/articles/postgresql (дата обращения 10.06.2020).
5. Зимовец А. И., Хомоненко А. Д. Обоснование выбора модели хранения данных для системы мониторинга космического пространства // Автоматика на транспорте. 2019. Т. 5, № 2. С. 221-232.
DOI: 10.20295/2412-9186-2019-5-2-221-232.
6. Гайкова О. В. Модели баз данных NoSQL / О. В. Гай-кова, В. В. Рогальчук, А. Д. Хомоненко // Модели и методы исследования информационных систем: Монография / А. Д. Хомоненко, В. П. Бубнов, А. В. Забродин [и др.]; под ред. А. Д. Хомоненко. — СПб.: Лань, 2019. — С.25-30. — 204 c. — (Учебники для вузов. Специальная литература).
7. Fundamentals of Apache Sqoop // Hadoop Sqoop Tutorial / DeZyre — Online Training Courses, Certification From Industry Experts. URL: http://www.dezyre.com/hadoop-tuto-rial/hadoop-sqoop-tutorial (дата обращения 10.06.2020).
8. Performance Monitoring, Testing and Optimizing Ha-doop-MapReduce Job using Hadoop Counters — 21.10.2015 // Hadoop Mania. URL: http://hadoopmania.blogspot.com/ 2015/10/performance-monitoring-testing-and.html (дата обращения 10.06.2020).
9. Dean J. MapReduce: Simplified Data Processing on Large Clusters / J. Dean, S. Ghemawat // Communication of the ACM. 2008. Vol. 51, Is. 1. Pp. 107-113.
DOI: 10.1145/1327452.1327492.
10. Демонстрационная база данных // Компания Postgres Professional. URL: http://postgrespro.ru/education/de-modb (дата обращения 10.06.2020).
11. Integration of Big Data Processing Tools and Neural Networks for Image Classification / N. E. Kosykh, A. D. Kho-monenko, A. P. Bochkov, A. V. Kikot // Proceedings of Models and Methods of Information Systems Research Workshop 2019 (MMISR 2019). CEUR Workshop Proceedings. 2020. Vol. 2556. Pp. 52-58.
12. Рыжиков Ю. И. Алгоритмический подход к задачам массового обслуживания: Монография. — СПб: ВКА им. А. Ф. Можайского, 2013. — 496 с.
13. Хомоненко А. Д. Численные методы анализа систем и сетей массового обслуживания. — М.: Министерство обороны СССР, 1991. — 197 c.
14. Khalil M. M. Load Balancing Cloud Computing with Web-Interface Using Multi-Channel Queuing Systems with
Warming Up and Cooling / M. M. Khalill, A. D. Khomonenko, S. I. Gindin // Intelligent Distributed Computing XIII: Proceedings of International Symposium on Intelligent and Distributed Computing (IDC 2019), (Saint Petersburg, Russia, October 79, 2019) / I. Kotenko (eds), et al. // Studies in Computational Intelligence. 2020. Vol. 868. Pp. 385-393. DOI: 10.1007/978-3-030-32258-8_45.
15. Khomonenko A. D. Stochastic Models for Cloud Computing Performance Evaluation / A. D. Khomonenko, S. I. Gindin // Proceedings of the 10th Central and Eastern European Software Engineering Conference in Russia (CEE-SECR'14), (Moscow, Russia, October 23-25, 2014).
DOI: 10.1145/2687233.2687256.
16. Harrison P. G.Queueing Models with Maxima of Service Times / P. G. Harrison, S. Zertal // Computer Performance Evaluation. Modelling Techniques and Tools: Proceedings of 13th International Conference on Modelling Techniques and Tools for Computer Performance Evaluation (TOOLS 2003), (Urbana, IL, USA, September 2-5, 2003) / P. Kemper, W. H. Sanders (eds.) // Lecture Notes in Computer Science, Vol. 2794. Pp. 152-168. DOI: 10.1007/978-3-540-45232-4_10.
17. Fiorini P. M. Exact Analysis of Some Split-Merge Queues / P. M. Fiorini, L. Lipsky // ACM SIGMETRICS Performance Evaluation Review. 2015. Vol. 43, No. 2. Pp. 51-53. DOI:10.1145/2825236.2825257.
18. Рыжиков Ю. И. Метод расчета длительности обработки задач в системе массового обслуживания с учетом процессов Split-Join / Ю. И. Рыжиков, В. А. Лохвицкий, Р. С. Хабаров // Известия высших учебных заведений. Приборостроение. 2019. Т. 62, № 5. С. 419-423.
DOI: 10.17586/0021-3454-2019-62-5-419-423.
19. Воробьев Е. Г. Математические модели управления системой обеспечения доступности информации и оценки качества ее функционирования // Наукоемкие технологии в космических исследованиях Земли. 2019. Т. 11, № 2.
C. 51-62. DOI: 10.24411/2409-5419-2018-10259.
20. Petrenko S. A. Method of Ensuring Cyber Resilience of Digital Platforms Based on Catastrophe Theory / S. A. Petrenko,
D. E. Vorobieva // Proceedings of XXII International Conference on Soft Computing and Measurements (SCM 2019), (Saint Petersburg, Russia, May 23-25, 2019). Pp. 97-101. DOI:10.1109/SCM.2019.8903658.
Estimation of Efficiency of Transfer of Big Data on the Example of PostgreSQL Database, Hadoop Platform and Sqoop System
Master of Science O. V. Badanina, PhD S. I. Gindin Emperor Alexander I Petersburg State Transport University Saint Petersburg, Russia olgagaykova@gmail. com, sgindin@gmail. com
Abstract. The evaluation of the characteristics of the efficiency of large data transmission is considered. To do this, use the PostgreSQL demo database as a data source; Hadoop platform, as a data storage tool, as well as a Sqoop data transfer tool. The experimental results demonstrate a change in the parameters characterizing the efficiency of data transfer during import, depending on their volume and type. The obtained experimental results can be used for the predictive calculation of the performance characteristics of big data processing. Such a forecast can be made on the basis of using the obtained characteristics of efficiency as a training sample for a neural network. In addition, it is advisable to forecast the speed of processing big data using models of multichannel queuing systems with heating and cooling, as well as queuing networks. It is advisable to calculate the efficiency indicators for moving big data in various modes of functioning of the information infrastructure for optimal disaster recovery of data warehouses and ensuring the required cyber stability of digital platforms in general.
Keywords: big data, data transfer efficiency, PostgreSQL DBMS, Hadoop platform, Sqoop data transfer tool, Map-Reduce software platform.
References
1. Reinsel D., Gantz J., Rydning J. The Digitization of the World — From Edge to Core, IDC Whitepaper, No. US44413318, November 2018, 28 p.
Available at: http://www.seagate.com/files/www-content/our-story/trends/files/idc-seagate-dataage-whitepaper.pdf (accessed 10 June 2020).
2. Pehcevski J. Big Data Analytics: Methods and Applications. Oakville, Canada, Arcler Press, 2019, 428 p.
3. Adamov A., Buranbaeva A. I., Gindin S. I., et al. Data Processing in High-Performance Computing Systems, BIG DATA and Advanced Analytics: Proceedings of the VI International Scientific and Practical Conference [BIG DATA i analiz vysokogo urovnya: Sbornik materialov VI Mezhdunarodnoy nauchno-prakticheskoy konferentsii], Belarus, Minsk, May 20-21, 2020, Chapter 1, Minsk, Best Print Publishers, 2020, Pp. 33-52.
4. PostgreSQL — object-relational database management system [PostgreSQL — ob''ektno-relyatsionnaya sistema up-ravleniya bazami dannykh], WEB Creator. Published at 31 July 2019. Available at: http://web-creator.ru/articles/post-gresql (accessed 10 June 2020).
Grand PhD A. D. Khomonenko A. F. Mozhaisky Military Space Academy, Emperor Alexander I Petersburg State Transport University Saint Petersburg, Russia khomon@mail. ru
5. Zimovets A. I., Khomonenko A. D. The Rationale for Choosing a Data Storage Model for a Space Monitoring System, Automation on Transport, 2019, Vol. 5, No. 2, Pp. 221-232. DOI: 10.20295/2412-9186-2019-5-2-221-232.
6. Gaikova O. V., Rogalchuk V. V., Khomonenko A. D. NoSQL Database Models [Modeli baz dannykh NoSQL]. In: Khomonenko A. D., Bubnov V. P., Zabrodin A.V., et al. Models and methods of research of information systems: Monograph [Modeli i metody issledovaniya informatsionnykh system: Monografiya], St. Petersburg, LAN Publishing House, 2019, Pp. 25-30.
7. Fundamentals of Apache Sqoop, DeZyre — Online Training Courses, Certification From Industry Experts. Available at: http://www.dezyre.com/hadoop-tutorial/hadoop-sqoop-tutorial (accessed 10 June 2020).
8. Performance Monitoring, Testing and Optimizing Ha-doop-MapReduce Job using Hadoop Counters, Hadoop Mania. Published at October 21, 2015. Available at: http://hadoop-mania.blogspot. com/2015/10/performance-monitoring-testing-and.html (accessed 10 June 2020).
9. Dean J., Ghemawat S. MapReduce: Simplified Data Processing on Large Clusters, Communication of the ACM, 2008, Vol. 51, Is. 1, Pp. 107-113.
DOI: 10.1145/1327452.1327492.
10. Demonstration database [Demonstratsionnaya baza-dannykh], Postgres Professional [Kompaniya Postgres Professional]. Available at: http://postgrespro.ru/education/de-modb (accessed 10 June 2020).
11. Kosykh N. E., Khomonenko A. D., Bochkov A. P., Kikot A. V. Integration of Big Data Processing Tools and Neural Networks for Image Classification, Proceedings of Models and Methods of Information Systems Research Workshop 2019 (MMISR 2019), CEUR Workshop Proceedings, 2020, Vol. 2556, Pp. 52-58.
12. Ryzhikov Yu. I. Algorithmic approach to queuing tasks: Monograph [Algoritmicheskiy podkhod k zadacham masso-vogo obsluzhivaniya: Monografiya], Saint Petersburg, A. F. Mozhaisky Military Space Academy, 2013, 496 p.
13. Khomonenko A. D. Numerical methods for analysis of queueing systems and networks [Chislennye metody analiza sistem i setey massovogo obsluzhivaniya], Moscow, Ministry of Defense of the USSR, 1991, 197 p.
14. Khalil M. M., Khomonenko A. D., Gindin S. I. Load Balancing Cloud Computing with Web-Interface Using MultiChannel Queuing Systems with Warming Up and Cooling.
In: Kotenko I. (eds), et al. Intelligent Distributed Computing XIII: Proceedings of International Symposium on Intelligent and Distributed Computing (IDC 2019), Saint Petersburg, Russia, October 7-9, 2019. Studies in Computational Intelligence, 2020, Vol. 868, Pp. 385-393. DOI: 10.1007/978-3-030-32258-8_45.
15. Khomonenko A. D., Gindin S. I. Stochastic Models for Cloud Computing Performance Evaluation, Proceedings of the 10th Central and Eastern European Software Engineering Conference in Russia (CEE-SECR'14), Moscow, Russia, October 23-25, 2014. DOI: 10.1145/2687233.2687256.
16. Harrison P. G., Zertal S. Queueing Models with Maxima of Service Times. In: Kemper P., Sanders W. H. (eds.) Computer Performance Evaluation. Modelling Techniques and Tools: Proceedings of 13th International Conference on Modelling Techniques and Tools for Computer Performance Evaluation (TOOLS 2003), Urbana, IL, USA, September 2-5, 2003. Lecture Notes in Computer Science, Vol. 2794, Pp. 152-168. DOI: 10.1007/978-3-540-45232-4_10.
17. Fiorini P. M., Lipsky L. Exact Analysis of Some Split-Merge Queues, ACM SIGMETRICS Performance Evaluation Review, 2015, Vol. 43, No. 2, Pp. 51-53. '
DOI:10.1145/2825236.2825257.
18. Ryzhikov Yu. I., Lokhvitsky V. A., Khabarov R. S. Method of Calculating Task Treatment Duration in Queueing System with Consideration of Split-Join Processes [Metod rascheta dlitel'nosti obrabotki zadach v sisteme massovogo ob-sluzhivaniya s uchetom protsessov Split-Join], Journal of Instrument Engineering [Izvestiya vysshikh uchebnykh zavedeniy. Priborostroenie], 2019, Vol. 62, No. 5, Pp. 419-423.
DOI: 10.17586/0021-3454-2019-62-5-419-423.
19. Vorobiev E. G. Mathematical Models of Ensuring Information Availability Management System and Quality Assessment of Its Functioning [Matematicheskie modeli upravleniya sistemoy obespecheniya dostupnosti informatsii i otsenki kachestva ee funktsionirovaniya], High Technologies in Earth Space Research [Naukoemkie tekhnologii v kosmicheskikh is-sledovaniyakh Zemli], 2019, Vol. 11, No. 2, Pp. 51-62.
DOI: 10.24411/2409-5419-2018-10259.
20. Petrenko S. A., Vorobieva D. E. Method of Ensuring Cyber Resilience of Digital Platforms Based on Catastrophe Theory, Proceedings of XXII International Conference on Soft Computing and Measurements (SCM 2019), Saint Petersburg, Russia, May 23-25, 2019, Pp. 97-101. D0I:10.1109/SCM.2019.8903658.
