Дослідження автоматизованої системи управління Big Data на основі блокчейн-технології

Ретівов, Павло Андрійович

Please use this identifier to cite or link to this item: https://er.chdtu.edu.ua/handle/ChSTU/6482

Title:	Дослідження автоматизованої системи управління Big Data на основі блокчейн-технології
Authors:	Міценко, Сергій Анатолійович Ретівов, Павло Андрійович
Issue Date:	Jan-2025
Abstract:	У кваліфікаційній роботі розв’язано важливе наукове завдання розроблення методів та засобів організації та інтеграції інформаційних ресурсів Великих даних для автоматизованого процесу управління даними. У результаті виконання даної роботи одержано такі результати: Проаналізовано методи, моделі та засоби опрацювання різнотипних даних, інформаційних технологій роботи з Великими даними. Обґрунтовано актуальність розв’язання завдання організації та інтеграції інформаційних ресурсів Великих даних у розподілених системах даних. Удосконалено метод перетворення реляційних та слабоструктурованих даних у дані, подані в моделі «сутність-характеристика», що дало змогу уніфікувати форму запитів до різних моделей даних. Удосконалено метод інтеграції даних через визначення пари «сутність-характеристика» та узгодження семантики, що на відміну від методів інтеграції даних на рівні сховища даних дозволило інтегрувати дані з джерел з наперед невідомою структурою без попереднього локального завантаження, і що, в свою чергу, дало змогу підвищити ефективність подальшого аналізу Великих даних. Даний метод став основою для оптимізації формування відповіді на запит користувача. Удосконалено метод формування відповіді на запит користувача до Великих даних шляхом уніфікації елементів мов запитів до різних інформаційних джерел, що дало змогу трансформувати запит до Великих даних у запит на основі ключових слів. Розроблено компоненти інформаційної системи підтримки прийняття рішень для автоматизованого управління інформацією з використанням Великих даних. Розроблено метод забезпечення достовірності даних, що обробляються в блокчейн-системі. У рамках розробки методу розширено клас методів забезпечення достовірності даних щодо виявлення недостовірних персональних даних з введенням в блокчейн-систему штучної нейронної мережі. Запропонований метод відрізняється від відомих концептуально новим підходом до досягнення консенсусу, що включає процедуру автоматизованої оцінки ризиків внесення та обробки недостовірних даних, розроблену з використанням теорії штучних нейронів мереж та теорії нечітких множин. Метод дозволяє забезпечити достовірність даних при їх обробці в блокчейн-системі: заснованих на хмарних платформах, як на рівні організацій різних форм власності, і на рівні держави загалом.
URI:	https://er.chdtu.edu.ua/handle/ChSTU/6482
Appears in Collections:	174 Автоматизація, комп'ютерно-інтегровані технології та робототехніка (Автоматизація та комп'ютерно-інтегровані системи та компоненти)

Files in This Item:

File	Description	Size	Format
М_174_2024_Ретівов.pdf Restricted Access		1.4 MB	Adobe PDF	View/Open Request a copy

Show full item record

Extracted text

МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОІЧНИЙ УНІВЕРСИТЕТ
ФАКУЛЬТЕТ ІНФОРМАЦІЙНИХ ТЕХНОЛОГІЙ І СИСТЕМ
КАФЕДРА РОБОТОТЕХНІКИ ТА СПЕЦІАЛІЗОВАНИХ КОМП’ЮТЕРНИХ СИСТЕМ

Пояснювальна записка
до кваліфікаційної роботи
освітнього ступеню «магістр»

на тему: ДОСЛІДЖЕННЯ АВТОМАТИЗОВАНОЇ СИСТЕМИ
УПРАВЛІННЯ BIG DATA НА ОСНОВІ БЛОКЧЕЙН-ТЕХНОЛОГІЇ

Виконав: здобувач вищої освіти 2 курсу,
групи МАКІТ-2309
спеціальності 174 Автоматизація,
комп’ютерно-інтегровані технології та
робототехніка (освітня програма
«Автоматизація та комп’ютерно-
інтегровані системи та компоненти»)
Ретівов П.А.
(Прізвище ім’я по-батькові)

Керівник Міценко С.А.
(Прізвище ім’я по-батькові)

Рецензент
(Прізвище ім’я по-батькові)

Черкаси 2024 року
2
ЗМІСТ

ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ ........................................................................ 3
ВСТУП ......................................................................................................................... 4
РОЗДІЛ 1АНАЛІЗ ОСОБЛИВОСТЕЙ СТРУКТУРИ ВЕЛИКИХ ДАНИХ .......... 8
1.1. Аналіз проблем обробки різнорідної інформації .......................................... 8
1.2. Характеристика та визначення терміну Big Data........................................ 11
1.3. Основні способи взаємодії з Великими даними ......................................... 15
1.4. Методи математичного опису Великих даних ............................................ 25
Висновки ................................................................................................................ 31
РОЗДІЛ 2 МОДЕЛЬ УПРАВЛІННЯ ВЕЛИКИМИ ДАНИМИ ДЛЯ
АВТОМАТИЗОВАНИХ СИСТЕМ ......................................................................... 32
2.1. Типи моделей даних для представлення Великих даних ........................... 32
2.2. Формальний опис структури Великих даних .............................................. 46
2.3. Схеми асоціацій між об’єктами та характеристиками для різних класів
NoSQL баз даних ................................................................................................... 49
Висновки ................................................................................................................ 52
РОЗДІЛ 3 ЗАБЕЗПЕЧЕННЯ НАДІЙНОСТІ ІНФОРМАЦІЇ У БЛОКЧЕЙН-
ТЕХНОЛОГІЇ ............................................................................................................. 53
3.1. Основні характеристики технології блокчейн ............................................ 53
3.2. Визначення механізму досягнення консенсусу .......................................... 61
3.3. Інформаційні системи аналізу процесів ...................................................... 64
3.4. Проектування потоку операцій в блокчейн-системі .................................. 67
Висновки ................................................................................................................ 76
ВИСНОВКИ ............................................................................................................... 78
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ ................................................................. 80
3
ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ

CCP – Compute Cluster Pack
COMA – Сache-only memory architecture
FIPA – Foundation for Intelligent Physical Agents
HDFS – Hadoop Distributed File System
MIMD – Multiple Instruction Multiple Data
MPI – Message Passing Interface
MАС – Мультиагентна система
MРР – Massive Parallel Processing
NUMA – Non-cache coherent
PVM – Parallel Virtual Machine
QoS – Quality of service (якість обслуговування)
SMP – Symmetric multiprocessor
SOA – Service Oriented Apllication
TTL – Temporal Trace Language
БД – База даних
БОС – Багатопроцесорна обчислювальна система
ІТ – Інформаційна технологія
КС – Комп’ютерна система
ОС – Операційна система
ПЗ – Програмне забезпечення
РКС – Розподілена комп’ютерна система
СППР – Система підтримки прийняття рішень
4
ВСТУП

Актуальність. Застосування інформаційних систем розвитку сприяє
швидкому поширенню знань, навичок та найкращих практик у певних галузях
промисловості. Для комплексного аналізу інформації необхідно: зберігати і
керувати інформацією розміром у петабайти; опрацьовувати інформацію з
реляційних, багатовимірних баз даних, баз даних XML і NoSQL, структурованих
і слабоструктурованих текстових файлів, баз геоданих, медіафайлів тощо;
аналізувати різнотипну інформацію, використовуючи як консолідований, так і
підхід для її отримання.
Процес побудови узагальненої (комплексної) моделі ускладнюється
різноманітністю моделей даних, а також через наявність різних рівнів агрегації
даних. Однією з популярних технологій для розроблення автоматизованих
систем управління є Великі дані.
Великі дані є терміном, який використовується для ідентифікації наборів
даних, з якими не можна впоратися з використанням існуючих методологій та
програмних засобів через їх великий розмір і складність. Такі дослідники як
М. Гілбернт [10], С. Стрініваса [15] та ін. розробили методики і програмні засоби
для передачі даних або видобування інформаційних гранул з Великих даних
(колекції об’єктів, які зазвичай формуються для атрибутів з числовими даними і
які розташовані поряд через їх схожість, функціональну або фізичну суміжність).
Методи машинного навчання та візуалізації даних дають змогу опрацювати та
графічно подати результати аналізу даних великих обсягів (мільойони кортежів).
Проте нерозв’язаною задачею залишається задача побудови відображення між
моделями даних різних джерел. В роботах Alejandro Maté [14] та Lucentia
Research Group [5] обґрунтовано використання багатовимірної моделі для
представлення Великих даних та побудови відображення в реляційну модель.
Проте у випадку використання бази даних ключ-значення як однієї з джерел
даних застосування багатовимірної моделі неприйнятне. Vinayak Borkar [13],
5
Yingyi Bu [32] пропонують використовувати об’єктно-орієнтований підхід,
проте обмеженням є кількість зв’язків між об’єктами. Отже, єдиного підходу до
опрацювання Великих даних не знайдено. Грунтуючись на цій інформації, з
метою її подальшого аналізу, слід вирішити питання, які сутності і в який спосіб
пов’язані між собою. Тому задача розроблення методів та засобів опрацювання
Великих даних в автоматизованих системах управління є актуальною.
Мета роботи – розробка методів та засобів опрацювання та аналізу
різнорідної інформації на основі Великих даних для процесів автоматизованого
управління.
Мета роботи визначає необхідність розв’язання таких задач:
− проаналізувати методи, моделі та засоби опрацювання різнотипних
даних, інформаційні технології роботи з Великими даними,
обґрунтування й постановка задачі;
− удосконалити метод перетворення реляційних та слабоструктурованих
даних у дані, подані в моделі «сутність-характеристика»;
− удосконалити метод формування відповіді на запит користувача до
Великих даних;
− розробити компоненти інформаційної системи підтримки прийняття
рішень для автоматизованого управління з використанням Великих
даних.
Об’єкт дослідження – процес інтеграції слабоструктурованих даних,
виділення елементів структури, та збереження їх у базу даних.
Предмет дослідження – автоматизована система управління big data на
основі блокчейн-технології.
Методи дослідження. Для досягнення поставленої мети
використовувались: методи системного аналізу – для формування
концептуальної моделі Великих даних; методи штучного інтелекту – для
виявлення закономірностей у каталозі Великих даних; методи об’єктно-
орієнтованого аналізу та проектування – для визначення семантичних зв’язків
між джерелами даних.
6
Наукова новизна. Отримано наступні наукові результати:
− удосконалено модель Великих даних «сутність-характеристика», яка
дає змогу опрацьовувати структуровані та напівструктуровані дані та
на відміну від багатовимірної моделі не містить надлишковості;
− удосконалено отримання відповіді на запит користувача шляхом
уніфікації елементів мов запитів до різних інформаційних джерел, що
дало змогу трансформувати запит до Великих даних у запит на основі
ключових слів;
− одержав подальший розвиток метод інтеграції даних за рахунок
визначення пари «сутність-характеристика» та узгодження семантики,
що на відміну від методів інтеграції даних на рівні сховища даних
дозволило інтегрувати дані з джерел з наперед невідомою структурою
даних без попереднього локального завантаження і що, в свою чергу,
дало змогу підвищити ефективність подальшого аналізу Великих
даних.
Практичне значення отриманих результатів полягає у тому, що:
− удосконалено алгоритми інтеграції інформаційних ресурсів за
допомогою попереднього визначення структури джерел даних та їх
узгодження, що дало можливість розробити алгоритм оцінювання
якості Великих даних;
− розроблено алгоритми пошуку даних за запитом користувача з метою
уніфікації алгоритмів опрацювання даних з різнотипних джерел даних,
що дозволило збільшити релевантність відповіді користувачеві на 2%;
− спроектовано архітектуру інформаційної системи для роботи з
Великими даними.
Апробація результатів роботи. Результати кваліфікаційної роботи
доповідалися й обговорювалися на науковій конференції:
− «Scientific research: Modern challenges and future prospects»: Тези
доповідей п’ятої міжнародної науково-практичної конференції: (16-
18 грудня 2024 р., Мюнхен), 2024.
7
Публікації. Результати досліджень опубліковані в:
1. Research of an automated Big Data management system based on blockchain
technology / S.Mitsenko, P. Retivov // «Scientific research: Modern
challenges and future prospects»: Тези доповідей п’ятої міжнародної
науково-практичної конференції: (16-18 грудня 2024 р., Мюнхен),
2024. – С. 43.
Структура та обсяг кваліфікаційної роботи. Кваліфікаційна робота
складається із списку умовних скорочень, вступу, трьох розділів, висновку та
списку використаних джерел. Загальний обсяг роботи складає 85 сторінки,
13 рисунків, 5 таблицm. Список використаних джерел містить 45 найменуванm.

8
РОЗДІЛ 1
АНАЛІЗ ОСОБЛИВОСТЕЙ СТРУКТУРИ ВЕЛИКИХ ДАНИХ

1.1. Аналіз проблем обробки різнорідної інформації
Проблема швидкого отримання різнотипових даних (сенсорних числових,
текстових документів, графіків тощо) з метою формування на їх основі
оперативних рішень постала ще у роки 2-ї світової війни і активно розвивалась
для застосування в атомних проектах, управлінні ракетами, навігації, управлінні
бойовими діями.
Опрацювання та аналіз таких різнотипових даних використовується для
моделювання розвитку подій та ситуацій, а також в системах підтримки
прийняття рішень. Започаткували вивчення цієї проблеми фон Нейман, розробки
компанії IBM, науковці школи Лєбєдєва С.О. (спеціалізована ЕОМ), Глушкова
В.М. (системний аналіз, теорія конфліктних ігор, проблемноорієнтовані системи
моделювання та опрацювання даних) [1, 5], що призвело до розвитку мов
блокового програмування, систем підтримки прийняття рішень.
Проте зміна класу досліджень – від оперативного до аналітичного, поява
нових типів даних, необхідність швидкого доступу до них, зумовила збільшення
інтересу до проблеми інтеграції та опрацювання даних з метою підвищення
якості управлінських рішень. Найвищий пік активності досліджень у сфері
інтеграції припадає на 90-ті рр. XX ст. та на наш час [54] у зв’язку з бурхливим
розвитком методів Business Intelligence та збільшенням можливостей сховищ
даних (збільшення обсягів збережених даних, наявність процедур аналітичного
опрацювання даних – OLAP).
Особливістю сучасних досліджень є аналіз не лише типів даних (описів),
але й семантики. Особливо активний розвиток засобів для оперативного збору
різнотипних даних, завантаження їх у сховище даних, аналізу та прогнозування
спостерігається в сферах енергетики та адміністративного керування,
нафтогазовому секторі [53]. Схема отримання інформації органами керування
регіоном передбачає створення статистичних звітів іншими об’єктами галузі за
9
наперед визначеною формою з покроковим агрегуванням інформації від одного
об’єкту до іншого (рис. 1.1).

Рис. 1.1. Схема рівноправного обміну даними

Це приводить до того, що особа, яка отримує інформацію, бачить її лише в
агреговану вигляді за жорстко визначеними критеріями групування, а
деталізована інформація потрапляє зі значним запізненням. Тому рішення, які
можуть бути прийняті у такому випадку, недостатньо враховують усі
особливості перебігу процесів розвитку регіону.
Процес консолідації даних для аналізу та прогнозування розвитку регіону
генерує наступні задачі:
− підвищення оперативності отримання, аналізу та використання
інформації, необхідної для підтримання прийняття рішень щодо
керування регіоном;
10
− своєчасного виявлення негативних тенденцій розвитку з метою їх
подальшого усунення.
− підвищення якості та дієвості керуючих рішень завдяки оперуванню
достовірною інформацією, отриманою безпосередньо з відповідного
джерела;
− визначення нових аспектів діяльності регіону завдяки аналізу даних,
які не потрапляли у традиційні звіти, і тому не враховувалися при
прийнятті рішень;
Інформаційний бум призвів до збільшення кількості даних, накопичених у
багатьох предметних галузях у сотні та тисячі разів. До таких областей
відноситься і сфера державного управління. Кількість зібраної інформації
зростає експоненційно. Так, за дослідженням IDC Digital Universe Study [41],
проведеним на замовлення компанії EMC, сумарний обсяг світових даних у 2005
році складав 130 ексабайт, до 2011 року він зріс до 1227 EB, а за останній рік
знову подвоївся, досягши 3 ZB (зетабайт). Прогноз, здійснений тим же
дослідженням, показує, що до 2018 року обсяг цифрових даних зросте до 7.9 ZB.
Розмір окремих баз даних зростає так само швидко і подолав петабайтний бар’єр.
Більшість зібраних даних на даний час не аналізується, або ж проходить лише
поверхневий аналіз [52].
Видобування даних є процесом виявлення нових нетривіальних
закономірностей з великих масивів інформації. Необхідно зазначити, що
прикметник «великий» у застосуванні до даних має тенденцію до постійного
зростання значення. Наприклад, за даними Тіма Суонсона кількість операцій, що
здійснюється щодня в криптовалюті Bitcoin, перевищила 100 000 операцій.
Очевидно, що таку кількість даних неможливо опрацювати без використання
автоматизованих засобів. Тому фахівцями розроблено багато методів аналізу
даних, пошуку залежностей між ними, прогнозування тощо.
Основними проблемами, які виникають при обробці даних, є відсутність
методів аналізу, придатних до застосування через їх різнотипність (для регіону–
це і числові дані, і гео-дані, слабоструктуровані звіти тощо), потреба у значних
11
людських ресурсах для підтримки процесу аналізу даних, висока обчислювальна
складність наявних алгоритмів аналізу та стрімке зростання обсягу зібраних
даних. Це в свою чергу призводить до постійного зростання часу, що
витрачається на аналіз даних навіть при регулярному оновленні комп’ютерних
засобів, а також – необхідність роботи із розподіленими базами даних,
можливості яких більшість існуючих методів аналізу даних не використовують
ефективно.
Таким чином, виникає задача розроблення ефективного методу аналізу
даних, що може застосовуватись до розподілених баз даних різних предметних
областей. Тому для регіону доцільно розробляти методи та засоби консолідації
даних та використання їх для аналізу.

1.2. Характеристика та визначення терміну Big Data
Концепція Великих даних не нова, вона виникла за часів мейнфреймів і
пов’язаних з ними наукових обчислень [136, 138]. Як добре відомо,
наукомісткість обчислень завжди було складним завданням. Як правило, вона
нерозривно пов’язана з обробкою великих обсягів інформації.
Проте, безпосередньо термін «Великі дані» (Big Data) з’явився порівняно
недавно. Він є одним з небагатьох, що має відомий день народження – 3 вересня
2008 р. Тоді було випущено спеціальний випуск найстарішого британського
наукового журналу Nature. Журнал присвячений пошукам відповіді на питання:
«Як технології можуть вплинути на наукове майбутнє, що відкриває можливості
для роботи з Великими даними» [35].
Згідно зі звітом McKinsey інституту під назвою «Великі дані: Наступний
рубіж для інновацій, конкуренції і продуктивності», термін «Великі дані»
відноситься до наборів даних, розмір яких перевищує ємність звичайної бази
даних (БД) для видобування, зберігання, управління і аналізу інформації [15].
Глобальні сховища даних продовжують зростати. Представлений звіт
аналітичної компанії IDC під назвою «Digital Universe Study» в середині
2011 року (який був організований компанією EMC) [41] передбачає, що
12
загальний світовий обсяг генерованих і тиражованих даних може досягати в 2011
році близько 1,8 зеттабайт (1,8 трлн гігабайт ). Це приблизно в 9 разів більше,
ніж те, що було створено в 2006 році [41].
Проте, концепт «Великі дані» означає набагато більше, ніж просто
величезні обсяги інформації. Проблема полягає не в тому, що організації
генерують величезні обсяги даних, але більшість з них представлені в форматі,
який не дуже добре вписується в традиційний структурований формат бази
даних. Це веб-журнали, відео, текстові документи, машинний код, або,
наприклад, картографічні дані.
У результаті, корпорація може мати доступ до величезного обсягу своїх
даних і не мати необхідних інструментів для встановлення зв’язків між цими
даними, автоматизованого формулювання конструктивних висновків на основі
аналізу цих даних.
Крім того, дані зараз оновлюються частіше, і ми маємо ситуацію коли
традиційні методи аналізу інформації не можуть опрацювати величезні обсяги
даних, що постійно оновлюються, і це, в кінцевому рахунку, прокладає шлях для
технологій Big Data.
EWeek подає визначення, запропоноване дослідницькою компанією
Gartner: «Великі дані характеризуються обсягом, різноманітністю і швидкою
плинністю структурованих і неструктурованих даних в процесорах і пристроях
зберігання даних, а також перетворення даних для задач бізнес-консалтингу для
підприємств» [52].
Великі дані (Big Data) в інформаційних технологіях за визначенням К.
Лінч, Д. Леней – набір методів та засобів опрацювання структурованих і
неструктурованих різнотипних динамічних даних великих обсягів з метою їх
аналізу та використання для підтримки прийняття рішень [52].
Є альтернативою традиційним системам управління базами даних і
рішенням класу Business Intelligence. До цього класу відносять засоби
паралельного опрацювання даних (NoSQL, алгоритми MapReduce, Hadoop) [48].
На думку компанії DCA (Data-Centric Alliance) під Big Data розуміють не якийсь
13
конкретний об’єм даних і навіть не дані, а методи їх обробки, які дозволяють
розподілено обробляти інформацію [11].
Ці методи можна застосовувати як до великих масивів даних (таких як дані
всіх сторінок в мережі Інтерет), так і до малих масивів (інформація про денні
поступлення товару в магазин).
Визначальними характеристиками для Великих даних є [47] обсяг (volume,
в сенсі величини фізичного обсягу), швидкість (velocity в сенсах як швидкості
приросту, так і необхідності високошвидкісної обробки та отримання
результатів), різноманіття (variety, в сенсі можливості одночасної обробки різних
типів структурованих і слабоструктурованих даних).
Хмарні технології підтримують інфраструктуру віртуалізації та її
профілювання для конкретних структур даних або для підтримки конкретних
наукових робочих процесів [56].
Розмаїтість (Variety) визначається за допомогою [46]:
1 реляційних даних (таблиці / транзакції);
2 текстових даних (Web),напівструктурованих даних (XML);
3 даних на основі графових моделей (соціальна мережа, Semantic Web,
RDF);
4 потокових даних;
5 великих публічних даних (онлайн, погода, фінанси і т.д.).
Є такі види вартості (Value) у Великих даних як статистичні дані, події,
метадані тощо.
Швидкість (Velocity) (Speed) Великих даних подана як:
1 дані генеруються швидко і повинні бути опрацьовані швидко;
2 он-лайн аналіз даних;
3 підтримка прийняття рішень з неповними даними.
Достовірність (Veracity) – поняття, зворотне до невизначеності, яка
виникає через невідповідність даних, їх неповноту, латентність [49].
Аналіз даних в системах територіального управління зводиться до
вирішення трьох конкретних завдань:
14
− соціально-економічна оцінка стану природного середовища в регіоні в
даний час і перспективі, розроблення на її основі системи заходів по
повному запобіганню чи максимальному пом’якшенню негативного
впливу господарської діяльності на навколишнє середовище;
− визначення й врахування можливих наслідків змін у природному
середовищі в результаті господарської діяльності і техногенних
процесів, їх вплив на спеціалізацію і комплексний розвиток
господарства регіону;
− врахування прогнозів еколого-економічних процесів у контексті
загального комплексного прогнозу соціально-економічного розвитку
регіону шляхом формування ряду критеріїв і обмежень як по ресурсах,
так і за допомогою показників якісного стану навколишнього
середовища.
Незважаючи на те, що термін був введений в академічному середовищі,
первинною була проблема зростання кількості і різноманітності наукових даних.
Станом на 2009 рік термін став широко поширений у діловій пресі, а до 2010
року з’явилася перша низка інформаційно-технологічних продуктів і рішень, що
стосуються виключно проблем обробки великих обсягів даних.
З 2011 року більшість найбільших постачальників інформаційних
технологій для організацій в їх бізнес-стратегії використовують концепцію
Великих даних, у тому числі IBM, Oracle, Microsoft, Hewlett-Packard , EMC [51].
Завдання, що виникають під час опрацювання, обробки, інтерпретації,
збору та організації Великих даних, з’явилися в численних секторах, включаючи
бізнес, промисловість, некомерційні організації. Обсяги даних, такі як операції
замовника у роздрібній торгівлі, моніторинг погоди, бізнес-аналіз, можуть
швидко випереджувати потужність традиційних методів та інструментів аналізу
даних. З’явилися нові методи та інструменти, включаючи бази даних NoSQL,
MapReduce, обробка природної мови, машинне навчання, візуалізація,
придбання, і серіалізація. Усе це стає необхідним, щоб повною мірою
усвідомити, що відбувається, коли зростають Великі дані, як вони
15
застосовуються і де починають відігравати вирішальну роль. Також необхідо
знати вимоги до існуючих методів розроблення систем і аналізу даних.
Великі дані є терміном, який використовується для ідентифікації наборів
даних, з якими ми не можемо впоратися з використанням існуючих методологій
та програмних засобів через їх великий розмір і складність. Багато дослідників
намагаються розробити методики і програмні засоби для передачі даних або
видобування інформаційних гранул з Великих даних [27, 54].
Особливості Великих даних, а саме:
− робота з неструктурованою та структурованою інформацією;
− орієнтація на швидке опрацювання даних;
− призводять до того, що традиційні мови запитів виявляються
малоефективними для роботи з даними [41].
Тому метою роботи є формальний опис різних моделей даних, виділення
операцій та носіїв, а також способів їх сумісного використання.

1.3. Основні способи взаємодії з Великими даними
Концепція NoSQL
Однією з концепцій опрацювання не тільки реляційних даних є NoSQL
[32]. Прихильниками концепції мови NoSQL підкреслюється, що вона не є
повним запереченням мови SQL і реляційної моделі, що SQL – це важливий і
досить корисний інструмент, але при цьому він не може вважатися
універсальним. Однією з проблем, яку вказують для класичних реляційних БД, є
проблеми при роботі з даними дуже великого обсягу, проектами з високим
навантаженням. Основна мета підходу – розширити можливості БД там, де SQL
недостатньо гнучкий, і не витісняти його там, де він справляється зі своїми
завданнями.
В основі NoSQL є такі фактори:
− нереляційна модель даних;
− розподіленість;
− відкритий вихідний код;
16
− гарна горизонтальна масштабованість.
У якості одного з методологічних обґрунтувань підходу NoSQL
використовується евристичний принцип, відомий як теорема CAP (Consistence,
Availability, Partition tolerance – «узгодженість, доступність, стійкість до
поділу»), стверджуючий, що в розподіленій системі неможливо одночасно
забезпечити узгодженість даних, доступність (англ. availability, у змісті наявності
відповіді по будь-якому запиту) і стійкість до розщеплення розподіленої системи
на ізольовані частини.
Таким чином, за необхідності досягнення високої доступності й стійкості
до поділу не фокусуються на засобах забезпечення узгодженості даних, що
забезпечуються традиційними SQL-орієнтованими СУБД з транзакційними
механізмами на принципах ACID [33].
Нестроге доведення теореми CAP засноване на простих міркуваннях.
Нехай розподілена система складається з N серверів, кожен з яких обробляє
запити деякого числа клієнтських застосунків. Під час опрацювання запиту
сервер повинен гарантувати актуальність інформації, що міститься у відповіді на
запит, що надсилається, для чого попередньо потрібно синхронізувати вміст його
власної бази з іншими серверами. Т
аким чином, серверу необхідно чекати повної синхронізації або генерувати
відповідь з урахуванням не синхронізованих даних. Можливий і третій варіант,
коли з яких-небудь причин синхронізація здійснюється тільки з частиною
серверів системи. У першому випадку невиконаною є вимога стосовно
доступності, у другому – узгодженості, у третьому – стійкості до поділу.
Існує чотири категорії NoSQL баз даних [31].
Перша категорія – це Key-Value (Ключ-Значення) бази даних. Це дуже
прості по своїй ідеї бази даних. Фактично це дуже великі хеш-таблиці, де
кожному ключу поставлене у відповідність значення. Такі бази можуть дуже
швидко оперувати колосальними обсягами інформації, але вони мають серйозні
обмеження в мові запитів. У якості прикладів Key-Value баз даних можна
привести Dynomite, Voldemort, Tokyo, Redis.
17
Друга категорія – клони Bigtable. BigTable – це база даних розроблена
компанією Google для власних потреб. Ця база являє собою велику таблицю із
трьома вимірами: колонки, рядки й часові мітки. Така архітектура дозволяє
добитися дуже високої продуктивності, крім того, вона добре масштабується на
багато комп’ютерів. Але це нереляційна база даних, і вона не підтримує багато
можливостей реляційних баз даних. Зокрема в Bigtable немає операцій з’єднання
(join), немає складних запитів і ін. Компанія Google не поширює Bigtable, тому
на ринку з’явилося кілька незалежно розроблених клонів цієї бази даних.
Зокрема це такі проекти як: Hadoop, Hypertable і Cassandra [28].
Наступна категорія баз даних – це документо-орієнтовані бази даних. Такі
бази нагадують Key-Value бази даних [28], але в цьому випадку в метаданих чи
словниках бази даних вказано, що собою представляють значення. Зазвичай,
значенням є деякий документ або об’єкт, до структури якого можна робити
запити. Прикладами таких баз даних є CouchDB і MongoDB [28].
Четверта категорія – це бази даних, побудовані на графах. Такі бази
орієнтовані на підтримку складних взаємозв’язків між об’єктами і ґрунтуються
на теорії графів. Структура даних у таких базах являє собою набір вузлів,
зв’язаних між собою посиланнями. При цьому й вузли, й посилання можуть мати
деяку кількість атрибутів. Як приклад можна привести такі бази даних як: Neo4j,
AllegroGraph, Sones graphDB [46].
Також існує ще й п’ята категорія, але її не відносять до NoSQL. Мова йде
про об’єктно-орієнтовані бази даних. Такі бази даних призначені насамперед для
підтримки об’єктно-орієнтованої парадигми програмування. Їх дуже просто
використовувати в мовах програмування, у яких підтримується ця парадигма.
Існує кілька механізмів для доступу до даних в NoSQL БД [30].
1 Restful інтерфейси. Це інтерфейс, схожий на основний протокол
інтернету – HTTP. У рамках даного підходу передбачається, що кожний
об’єкт, яким ми можемо маніпулювати, має свою унікальну адресу.
Звертаючись за цією адресою, ми можемо запитувати, створювати,
редагувати або знищувати зазначений об’єкт. При цьому на сервері не
18
зберігається ніякого стану, тобто кожний запит опрацьовується
незалежно від інших запитів.
2 Мови запитів, відмінні від SQL. GQL – SQL-подібна мова для Google
Bigtable, SPARQL – мова запитів Семантичного Веба, Gremlin – мова
обходу графів, Sones Graph Query Language – мова запитів до Sones
Graph.
3 API запити. Google Bigtable Datastore API, Neo4j Traversal API.

Таблиця 1.1
Порівняння SQL і NoSQL
NoSQL SQL
Термін NoSQL охоплює Зберігаються в реляційній
множину баз даних, кожна з моделі в рядках і
яких може мати різні стовпцях.
Зберігання даних
моделі зберігання даних.
Основні з них: документ,
графік, ключзначення.
Схеми являються Кожний запис відповідає
динамічною інформацією, визначеній схемі. Схема
яка може бути додана в може бути змінена, але в
будь-який момент часу. цьому випадку вона
Схеми і гнучкість
передбачає зміну всієї
бази даних. Виконання
змін відбувається
оффлайн.
Горизонтальна Вертикальна
Масштабованість
масштабованість. масштабованість.

19
Продовження таблиці 1.1
Все залежить від Більшість реляційних баз
технології. Багато рішень в даних відповідають ACID.
області NoSQL не
Відповідність ACID дотримуються
відповідності ACID на
користь масштабованості
та продуктивності.

NoSQL можуть запропонувати високий рівень експлуатаційної готовності,
коректності й продуктивності.
Головною перевагою NoSQL баз даних є продуктивність. Усі NoSQL бази
даних перевершують реляційні бази даних у своїй ніші. Якщо ще недавно існував
тільки один вид баз даних для всіх випадків – реляційні бази, то сьогодні ситуація
змінилася.
Для кожної конкретної ситуації необхідно підбирати свою модель даних.
Іноді доводиться мати одночасно кілька баз даних, у кожної з яких
використовуються її найсильніші сторони. Наприклад, у web-застосуваннях
Mongodb застосовується як основне сховище даних, а за допомогою Redis
організовується кешування запитів користувача.
У результаті ми отримуємо систему з дуже високою продуктивністю й з
досить зручними інтерфейсами для розроблювачів. Ще одна важлива перевага
NoSQL баз даних полягає в тому, що багато представників цього сімейства
сховищ даних реалізовані як проекти з відкритим кодом.
Отже, існування різних категорій баз даних NoSQL вимагає формального
опису моделей даних, що ними опрацьовуються. Загалом порівняння SQL і
NoSQL подано в таблиці 1.1 [10].
Аналіз програмного забезпечення для роботи з Великими даними
Концепція «Великі дані» досі не дуже добре окреслена, хоча активно
використовується для бізнесу та технологій. Аналіз згаданих вище джерел,
20
науково-популярних журналів, і блогів дають змогу виділити наступні фокуси
обговорення [18]:
− джерела Великих даних;
− апаратне забезпечення та інфраструктура;
− програмне забезпечення і зберігання;
− інформаційні технології (методи і засоби обробки даних);
− використання Великих даних, бізнес-аналіз.
В якості джерел Великих даних можна виділити пристрої та людей.
Приклади перших джерел: національні та міжнародні проекти, такі як Великий
адронний коллайдер (LHC) в ЦЕРН, Лабораторія фізики елементарних частинок
в Європі, Великий синоптичний оглядовий телескоп на півночі Чилі;
промисловість (SCADA, фінанси і т.д.) [21].

Рис. 1.3. Порівняльна характеристика OLAP та Великих даних

Приклади другого типу джерел: соціальні мережі, охорона здоров’я,
роздрібна торгівля, особисті дані про місцезнаходження, управління
громадським сектором і т.д.
21
Для збору і обробки Великих даних доцільно використовувати технології
хмарних обчислень. Хмарні обчислення – це нова парадигма для розміщення
кластерів даних і надання різних послуг локальною мережею або через Інтернет.
Хостинг кластерів даних дає змогу клієнтам зберігати та обчислювати величезну
кількість даних у хмарі.
Оскільки розмір окремих баз даних зростає швидко і подолав петабайтний
бар’єр (наприклад, бази даних соціальних мереж), то онлайн опрацювання в
режимі OLAP таких обсягів практично неможливе (рис. 1.2) [21].

В таблиці 1.2 [29] подано відомості щодо ряду інструментів опрацювання
Великих даних з відкритим вихідним кодом, які надаються через інфраструктури
хмарних обчислень. Більшість інструментів забезпечується Apache і випущені
під ліцензією Apache [19]. Усі ці продукти згруповано за типами задач, що
виникають в процесах опрацювання Великих даних.

Таблиця 1.2
Засоби роботи з Великими даними
Засоби для Великих даних Опис
Засоби аналізу даних
Інструмент веб для надання послуг,
Ambari http://ambari.apache.org управління та моніторингу Apache
Hadoop кластерів
Avro http://avro.apache.org Система серілізації даних
Chukwa Система колекціонування даних для
керування великими розподіленими
http://incubator.apache.org/chukwa системами
Швидкий і генеральний обчислювач
для даних Hadoop. Забезпечує
просту і виразну модель
Spark http://spark.incubator.apache.org програмування, яка підтримує
широкий спектр додатків, у тому
числі ETL, машинного навчання,
опрацювання потоків
22
Продовження таблиці 1.2
Hive http://hive.apache.org/ Інфраструктура сховища даних,
яка забезпечує агрегацію даних
Високорівнева мова потоків даних
Pig http://pig.apache.org і виконуваний framework для
паралельних обчислень
Високопродуктивна служба
ZooKeeper http://zookeeper.apache.org/ координації для розподілених
застосунків
Actian Забезепечує зберігання сирих
http://www.actian.com/aboutus/#overview даних і готує дані для подальшого
аналізу
Забезпечує швидке перетвореня,
HPCC http://hpccsystems.com паралельне опрацювання для
застосувань з Великимиданими
Засоби Data Mining
Orange http://orange.biolab.si Візуалізація та аналіз даних для

новачка і експертів
Mahout http://mahout.apache.org Бібліотека засобів машинного
навчання та видобування даних
KEEL http://keel.es Еволюційний алгоритм для
проблем видобування даних
Засоби соціальних мереж
Платформа з високою пропускною
Apache Kafka здатністю для опрацювання даних
в режимі реального часу
Засоби BI
Інтеграція даних, управління,
Talend http://www.talend.com інтеграція застосувань, засоби і
сервіси для Великих даних
Jedox http://www.jedox.com/en Функції аналізу, звітності,

планування
Pentaho http://www.pentaho.com Інтеграція даних, бізнес-аналіз,
візуалізація даних, прогнозування
Rasdaman http://rasdaman.eecs.jacobs Багатовимірні расторові дані
university.de/ (масив) без обмежень на розмір,
наявність мови запитів

23
Продовження таблиці 1.2
Засоби пошуку
Застосування для повнотекстового
Apache Lucene http://lucene.apache.org індексування і пошуку
Повнотекстовий пошук, фасетний
пошук, динамічна кластеризація,
Apache Solr http://lucene.apache.org/solr формати документів типу Word,
PDF, просторовий пошук
Elasticsearch Засіб розподіленого
http://www.elasticsearch.org повнотекстового пошуку з веб-
інтерфейсом і JSON докуметами
MarkLogic
http://developer.marklogic.com NоSQL і XML база даних

Крос-платформенна документо-
mongoDB http://www.mongodb.org орієнтована система управління

базами даних з підтримкою JSON та
динамічних схем
Cassandra http://cassandra.apache.org Маштабована мульти-майстерна

база даних без єдиної точки відмови
Маштабована розподілена база
даних з підтримкою
HBase http://hbase.apache.org структурованого зберігання даних
великого обсягу
InfiniteGraph http://www.objectivity.com Розподілена графова база даних

Особливості перетворення NoSQL в інші формати
Узагальнюючи результати аналізу відображення систем баз даних NoSQL
різних класів в інший формат, можна зробити висновок, що незалежно від класу
системи – «ключ-значення», колонкова або документна, існує ряд cпільних
проблем.
Так як в NoSQL схема може бути присутня неявно, реалізованою в коді
програми, то семантично значуще відображення в об’єктну модель автоматично
будувати неможливо. Виявлення схеми даних для кожної окремої бази даних
вимагатиме залучення експерта. Є сенс будувати відображення на рівні додатку
24
(зaстосунку), що працює над базою даних, минаючи відображення моделей
системи баз даних. Однак ці додатки можуть бути [50]:
− закритими для зовнішніх запитів, які не надають довільного доступу до
даних,
− розбитими на частини, які працюють з різними підмножинами даних з
одних і тих же баз;
− з однією базою може працювати багато застосунків.
Основна причина проблем, що виникають при семантичному відображенні
моделей даних NoSQL в об’єктну модель даних, полягає в їх слабкій
структурованості:
− в більшості з них не визначається схема даних в явному вигляді;
− значення в парах «ключ-значення» часто можуть бути довільними і
неструктурованими, ключі можуть розглядатися і як елементи
структури, так як і дані;
− за відсутності схеми структура пар може змінюватися динамічно;
− фактично, за допомогою операції оновлення можна в будь-який момент
ввести нову структуру пар «ключ-значення»;
− бази даних зазвичай не обмежені за кількістю пар в структурах, за
довжиною ключів, за вкладеністю пар.
Такі системи можуть використовуватися для вирішення завдань,
розрахованих на використання нефіксованих і необмежених
слабоструктурованих даних (наприклад, ієрархічних або потокових).
З іншого боку, багато програм використовують системи баз даних NoSQL
для зберігання досить жорстко типізованих структур. І той, і інший випадки
доводиться враховувати при відображенні в об’єктну модель.
Під час аналізу семантики даних звертається увага на використання в
ключах фіксованих (імена елементів структур) або нефіксованих (дані) значень.
У разі виявлення статичної схеми даних фіксовані значення ключа
трансформуються в атрибути типів, нефіксовані – в значення атрибутів.

25
Під час відображення створюються такі структури [82, 83]:
− фреймові структури для вкладених пар;
− абстрактні типи даних в разі, якщо дані підлягають виявленню чіткої
структурі.
Можливі різновиди запитів, які використовуються при вирішенні завдань
над даними в моделях NoSQL повинні бути відомі заздалегідь. Дані, за якими
необхідно організувати пошук, повинні виявитися ключами в деяких парах
«ключ-значення», а дані, які шукають – значеннями, для чого формуються
допоміжні пари над основними даними з відповідною структурою даних. Такі
пари при відображенні не утворюють нові структури, а відображаються в типи і
класи, утворені основними парами. Відповідно до допоміжних пар в цільовій
моделі утворюються вторинні ключі. Запити з порівнянням по атрибутам, що є
ключами в допоміжних парах, при зворотному відображенні відображаються в
операції над цими парами [5].

1.4. Методи математичного опису Великих даних
Багатовимірна модель даних
Одним із способів представлення Великих даних є гіперкуб даних [10].
Основними поняттями багатовимірної моделі даних є:
− гіперкуб даних rel,
− вимір V,
− атрибут A,
− комірка X,
− значення rel(V, A).
Гіперкуб даних містить один або більше вимірів і є впорядкованим
набором комірок. Кожна комірка визначається одним і лише одним набором
значень вимірів – атрибутів. Комірка може містити дані – значення або бути
порожньою.
Під виміром у [14] розуміють множину атрибутів, що утворюють одну з
граней гіперкуба. Прикладом часового виміру є список днів, місяців, кварталів.
26
Прикладом географічного виміру може бути перелік територіальних об’єктів:
населених пунктів, районів, реґіонів, країн та ін.
Отже, V – множина вимірів гіперкуба, AVi = {A1i ,A2i ,...,Aki } i = 1,..., n –
множина атрибутів виміру Vi . Гіперкуб даних позначимо як множину комірок,
що відповідає множинам V, A: rel(V, A). Підмножина гіперкуба даних, що
відповідає множині фіксованих значень, позначається як rel(V, A).
Кожній комірці гіперкуба даних відповідає єдино можлива множина
атрибутів вимірів Arel. Комірка може бути порожня (не містити даних) або
містити значення показника [10]. Множину комірок гіперкуба rel(V,A)
позначимо як V(rel). Для отримання доступу до даних користувачу необхідно
вказати множину необхідних вимірів і значень атрибутів (фіксувати атрибути).
Множину комірок, що відповідають відповідним атрибутам та вимірам.
Ключем виміру є атрибут, який однозначно визначає кортеж (рядок)
виміру гіперкуба. Гіперкуби підтримують ієрархію вимірів і формул без
дублювання їх визначень. Набір відповідних гіперкубів складає багатовимірну
базу даних (або сховище даних).
Комбінації значень вимірів визначають комірки гіперкуба. Залежно від
конкретного застосування (прикладної програми), комірки в гіперкубі можуть
розташовуватися як розріджено, так і щільно. Гіперкуби, як правило, стають
розрідженими у міру збільшення числа розмірностей і ступеня деталізації
значень вимірів.
Багатовимірне представлення даних добре використовувати для задач
візуалізації даних та їх аналізу, але у зв’язку з розрідженістю гіперкуба [40] обсяг
даних у такому випадку є більший порівняно з реляційним представленням, що
є неприпустимим до Великих даних.
Об’єктне подання даних
Інформація про модельовані об’єкти подається множиною складних
значень, що зберігаються в ідентифікованих змінних (у подальшому – об’єкти
даних). Об’єкт даних o опишемо як [30, 31]

27
{id, meta, o},

де id – унікальний ідентифікатор зазначеної змінної, meta – інформація, що
описує структуру зазначеної змінної (метадані), де, зокрема, перелічуються
поіменовані атрибути об’єкта даних, o – складне значення, що описує стан
об’єкта.
Будемо розглядати кожне зі значень ri як значення іменованого атрибута
об’єкта о. Тоді атрибут має розглядатися як змінна відношень, а схема об’єкта
даних повинна перелічувати імена атрибутів. Відповідно, об’єкт o буде
описуватися як

де ri – значення відношень Ri , ri = relval(Ri), Dj, – не обов’язково різні
домени з множини D доменів. Відзначимо, що в системі O може одночасно
існувати множина не обов’язково різних значень r того самого відношення R, що
є значеннями атрибутів різних об’єктів або значеннями різних атрибутів того
самого об’єкта.
Розглянемо множину O усіх вхідних у систему об’єктів. Кожному
об’єктові ставиться у відповідність схема об’єкта Si =oSchema(oi), що є власною
підмножиною множини S. Та сама схема S може бути поставлена у відповідність
багатьом об’єктам. Отже, можна стверджувати, що між множиною схем і
множиною класів існує функціональна відповідність S= Schema(C).
Також ми можемо говорити про існування множини R усіх визначених на
множині доменів D відношень R, значення яких є значеннями атрибутів oai
об’єктів із множини O. Кожному імені oa ставитися у відповідність одне і тільки
одне відношення R з множини R, тим самим обмежуючи множину можливих
значень атрибута з іменем oai значеннями цього відношення R. Оскільки мова
йде про пару «множина – визначене на цій множині значення», відношення R
28
можна позначити як домен атрибута oa. Однак, оскільки значення, визначене на
цьому домені, являє собою значення відношень (relval) і також є множиною,
будемо називати відношення R реляційним доменом атрибута oa, R=rdom(oa).
Отже, ми можемо говорити про функціональну відповідність між
множиною атрибутів oa і множиною відношень R, R = rdom(oa).
Кожне таке відображення відповідає унікальному значенню, що є
ідентифікатором цього об’єкта. Тоді множина ідентифікованих об’єктів O –
функціональна відповідність між множиною id, що включає унікальні
ідентифікатори id всіх об’єктів o вхідних у множину O, і множиною відображень,
що формують власні значення цих об’єктів.
Припустимо, що значення унікальних ідентифікаторів об’єктів, що
входять у множину id, визначені на домені DOID, а імена їхніх атрибутів, що
входять у множину oa – на домені DA,Можна показати, що

Звідси випливає, що
1 об’єкт має унікальний ідентифікатор, і, отже, у системі можуть
існувати два об’єкти з абсолютно однаковим власним значенням;
2 значення атрибутів об’єктів є значеннями відношень, що є множиною
кортежів – іншими словами атрибут можна розглядати як групу
повторення.
На рівні збереження ця ж інформація подана у вигляді множини значень
відношень R', визначених на доменах з множини D'. Інформація про унікальні
ідентифікатори об’єктів oi і про значення, які визначають семантику атрибутів,
на рівні збереження існує точно в такому ж вигляді, як і інформація про власні
значення цих об’єктів, а саме у вигляді явно заданих значень атрибутів кортежів
відношень R'. Отже, рівень збереження цілком описується в термінах реляційної
29
моделі даних. З практичної точки зору цей факт цікавий тим, що він дозволяє
реалізувати рівень збереження, використовуючи наявні реляційні СКБД.

Таблиця 1.3
Порівняння моделей представлення Великих даних
Назва моделі Автори Переваги Недоліки
У зв’язку з
розрідженістю
Добре гіперкуба з
Багатовимірна Maté, Alejandro використовувати для неоднорідними
модель [14] задач візуалізації даними, їх обсяг
даних та їх аналізу. збільшується, що є
неприпустиме до
Великих даних
Нерозв’язаною є
задача
За певної
Chang, Fay [30], трансформації з
Об’єктна модифікації може
Papakonstantino, одних типів
модель бути використана
Y [31] представлення
для Великих даних.
даних в об’єктну
модель даних
Велика
обчислювальна
Добра для аналізу
Графова складність
Zhou Feng [32] зв’язків між
модель алгоритмів пошуку
об’єктами.
за умови великої
кількості об’єктів

Множина O об’єктів o може бути однозначно перетворена до множини
значень відношень R', що входять у множину R', причому між множиною R
30
відношень, що є доменами атрибутів об’єктів o, і множиною R' існує така
взаємно-однозначна відповідність, що для будь-якого відношення, що належить
R, у множині R' буде існувати відповідне відношення:

Тому об’єктне подання даних за певної модифікації може бути
використане для подання інформаційних ресурсів Великих даних. Проте
залишається нерозв’язаною задача трансформації з одних типів представлення
даних в об’єктну модель даних.

Рис. 1.4. Постановка задачі дослідження

Основними проблемами, які виникають при обробці даних, є відсутність
методів аналізу, придатних до застосування через їх різнотиповість (для регіону
– це і числові дані, і геодані, слабоструктуровані звіти тощо), потреба у значних
31
людських ресурсах для підтримки процесу аналізу даних, висока обчислювальна
складність наявних алгоритмів аналізу та стрімке зростання обсягу зібраних
даних.
Вони призводять до постійного зростання часу аналізу даних навіть при
регулярному оновленні апаратних засобів серверів, а також – необхідність
роботи із розподіленими базами даних, можливості яких більшість існуючих
методів аналізу даних не використовують ефективно.
Таким чином, виникає задача розроблення ефективного методу аналізу
даних, що може застосовуватись до розподілених баз даних різних предметних
областей. Тому для регіону доцільно розробляти методи та засоби роботи з
Великими даними та використання їх для аналізу.

Висновки
В першому розділі отримано наступні результати:
1. Визначено складові розвитку регіону і показано, що для цього треба
опрацьовувати різнотипні дані.
2. Подано поняття Великих даних та описано їх характеристики.
3. Проаналізовано інформаційні моделі представлення даних великих
обсягів та показано їх обмеження. Це призводить до необхідності
розроблення моделі представлення Великих даних.
4. Проаналізовано особливості NoSQL-баз даних та принципи
перетворення даних в інші формати. Визначено нерозв’язані задачі.
5. Проаналізовано методи прогнозування процесів територіального
управління та окреслено їх обмеження.
6. Здійснено постановку задачі дослідження на основі виділення раніше
нерозв’язаних задач.

.
32
РОЗДІЛ 2
МОДЕЛЬ УПРАВЛІННЯ ВЕЛИКИМИ ДАНИМИ ДЛЯ
АВТОМАТИЗОВАНИХ СИСТЕМ

2.1. Типи моделей даних для представлення Великих даних
Поняття структурованих та слабоструктурованих даних
Межу між структурованими й неструктурованими даними можна провести
навіть інтуїтивно. Однак, перш ніж перейти до розгляду прикладів такої
інформації і її формальних описів, пояснимо відмінність структурованої й
слабкоструктурованої інформації докладніше.
Модель даних – це сукупність засобів опису структур даних для додатка
або класу додатків. Модель даних містить у собі типи й структури даних, систему
операцій, засоби опису обмежень [15].
Модель структурованих даних має такі особливості: по-перше, на дані
накладаються заздалегідь відомі обмеження за типом й довжиною кожного
атрибута, що робить ускладненим, а найчастіше навіть неможливим,
модифікацію моделі під вимоги, що змінилися із часом; по-друге, структура
даних відома й визначена за допомогою схеми даних, її автоматична зміна в
процесі роботи моделі ускладнена.
Інтерпретувати дані без знання схеми не представляється можливим. При
цьому в процесі розробки схеми необхідно провести формалізацію
оброблюваних даних, що унеможливлює автоматизацію коректування схеми в
процесі використання моделі.
Однак, внаслідок наявних обмежень, модель структурованих даних має
великий набір можливих операцій. Прикладом реалізації моделі структурованих
даних може виступати будь-яка реляційна система керування базою даних
(СУБД).
Розробка моделі для неструктурованих даних є вкрай складним завданням
з наступних причин. По-перше, дані, як правило, представлені природньою
33
мовою, що ускладнює роботу з ними. По-друге, повна відсутність визначеної
структури накладає серйозні обмеження на можливі операції з даними.
Автоматичне виділення структури в таких даних, як правило, не може бути
виконане однозначним чином.
Слабоструктурованими даними є будь-які проміжні дані між
структурованими й неструктурованими. Такі дані мають певні особливості.
По-перше, структура даних може бути неповною, недовизначеною, а також
допускати виключення. По-друге, значення скалярних даних представлені у
вигляді текстової інформації. По-третє, виникає проблема визначення
приналежності даних, тому що не завжди можна однозначно стверджувати про
коректність опрацьованого документа.
Модель слабоструктурованих даних повинна враховувати визначені
особливості. Виділено основні проблеми, що виникають під час розроблення
моделі слабоструктурованих даних.
По-перше, при роботі з даними заздалегідь невідомий ступінь їх
коректності, і, як наслідок, у моделі необхідний інструментарій для оцінки
«правильності» даних. Враховуючи, що в слабоструктурованих даних усі
атрибути представлені у вигляді текстової інформації, необхідний досить
гнучкий механізм перевірки приналежності даних до конкретного атрибута.
По-друге, схема даних може або зовсім не існувати, або не повною мірою
відповідати оброблюваним даним. Оскільки працювати з документом, не маючи
ніяких уявлень про його структуру, неможливо, виникає завдання виділення
схеми з оброблюваних даних, а також її коректування в процесі експлуатації
моделі й одержання нової інформації.
По-третє, деякі атрибути даних можуть бути або взагалі відсутні, або не
повною мірою задовольняти умовам коректності, заданим для цих атрибутів.
Таким чином, у цій моделі повинен існувати інструмент обробки виключень, що
дозволяє формувати спосіб запиту до цих даних, ґрунтуючись на заздалегідь
заданих критеріях.
34
Існуючі методи організації зберігання й доступу до слабоструктурованої
інформації
Проаналізуємо три основні представлення слабоструктурованої інформації
[8]:
− OEM (Object Exchange Model, модель обміну об’єктами);
− XML (Еxtensible Markup Language, розширювана мова розмітки);
− RDF (Resource Description Framework, фреймворк опису ресурсів).
Ці представлення, як і в науковій, так і практичній літературі даються в
описовому, а не формалізованому виді. Як уже зазначалось в попередньому
параграфі, під слабоструктурованими даними розуміють такі дані, які протягом
невеликого проміжку часу можуть виявитися недостатньо формалізованими,
неповними, або мати структуру, яка може значно змінитися.
Як правило, такі дані не можуть бути описані за допомогою якої-небудь
незмінної схеми, тому іноді їх називають schema-less (такі, що не мають схеми),
а також self-describing (самоописуваними).
Характерною рисою слабоструктурованих даних є те, що описова
інформація, яка зазвичай виділяється в окрему схему, є присутньою у самих
даних. Досить докладно існуючі методи організації зберігання й доступу до
слабоструктурованої інформації розглядалися у роботі [15], а нижче будуть
запропоновані формальні моделі для найпоширеніших методів подання
слабоструктурованих даних.
Слабоструктурована інформація в OEM-поданні
У рамках OEM-подання [33] – моделі, розробленої раніше всіх інших,
поняття слабоструктурованих даних означає скоріше не той факт, що дані не
можуть мати певну структуру, а те, що схема даних піддається доволі частій зміні
за кількістю і типом атрибутів сутностей і зв’язків між ними. На етапі розробки
OEM-схеми даних, у принципі, немає перешкод для реалізації в реляційних
таблицях набагато більшого числа атрибутів даних, аніж потрібно практично,
тобто на «майбутнє» їх застосування. Найчастіше при проектуванні схеми даних
35
розробники діють саме таким чином, надалі одержуючи громіздку й надлишкову
структуру зберігання, що не піддається адекватному формалізованому опису.
Перерахуємо основні ознаки OЕМ-подання, що приводять до появи
слабкої структурованості БД.
1 Дані потрапляють в базу з гетерогенних джерел. Вони можуть містити
пропуски, або дублювання, або мати вкладеність різної глибини.
2 Схема даних може мінятися залежно від семантичної інтерпретації
збережених даних. Наприклад, схема даних змінюється залежно від
підходу до складання колекції неформатованих текстових документів,
присвячених деякій тематиці.
3 Схема даних постійно ускладнюється й вимагає деталізації. Наприклад,
часто змінюються умови зовнішнього середовища, граничні значення
показників, склад базових і нормативних характеристик, що
зберігаються в БД.
4 Схема даних повинна надходити разом із запитами даних, тобто бути
вбудованою. Наприклад, різні рівні доступу до конфіденційної
інформації не повинні виявляти й розкривати цілком усю структуру БД.
Першим відомим дослідницьким проектом, що практично
використовуєOEM-подання й спрямований на інтеграцію структурованих даних
(представлених реляційними БД), слабоструктурованих даних (зокрема,
xmlсторінок) і неструктурованих даних (колекцій файлів текстів) є проект
TSJMMIS [42].
Архітектура компонентів у зазначеному проекті наступна:
1 транслятори/конвертори даних;
2 медіатори;
3 менеджери обмежень;
4 класифікатори/екстрактори даних.
Перший компонент призначений для конвертування даних, що надходять
із різних джерел до формату єдиної інформаційної моделі проекту TSIMMIS.
Другий компонент, медіатори, являють собою інформаційні роутери
36
інформаційних запитів, що перенаправляють дані окремим трансляторам, а
також об’єднують результати вибірок даних. Третій компонент, менеджери
обмежень, виконують перевірку несуперечності й відповідності вихідної
інформації вхідному запиту. Четвертий компонент, класифікатори/екстрактори
даних необхідні для добування ключових характеристик зі слабоструктурованих
(неструктурованих) джерел даних і виділення в них деякого «резюме», тобто
деякої системної складової, відповідно до якої їх можна було б віднести до того,
або до іншого класу. Обмін інформацією в проекті TSIMMIS здійснюється за
допомогою самоописової моделі даних OEM.
Цей проект був неповністю автоматичною системою зберігання й обробки
даних, у зв’язку із чим користувачі взаємодіяли з нею за допомогою інтерфейсу
MOBIE (Mosaic Based Information Explorer), могли переглядати OEM - об’єкти й
виконувати запити до даних на SQL- подібній мові – OEM-QL.
Слабоструктурована інформація в XML-представленні
Умовам schema-less і self-describing насамперед відповідає XML- подання
слабоструктурованих даних. Мова XML є підмножиною мови SGML (Standard
Generalized Markup Language, стандартна узагальнена мова розмітки). SGML
являє собою систему визначення структурованих типів документів і мов
розмітки екземплярів документів таких типів. Ця мова дозволяє розділити
будьякий документ на дві логічно незалежні частини; одна з них визначає
структуру документа, а інша містить сам текст. Визначення структури
називається визначенням типу документа (Document Type Definition – DTD).
Мова SGML уможливлює призначення для будь-якого документа окремо певну
структуру й дає можливість авторам документів створювати власні,
спеціалізовані структури, тому може стати основою надзвичайно потужної
системи керування документами. Проте, ця мова відрізняється значною
складністю, тому не одержала досить широкого поширення.
Мова XML призначена для виконання аналогічних функцій, але є менш
складною і разом з тим більше пристосована для використання в мережі. При
цьому дуже важливо те, що мова XML зберегла основні переваги SGML,
37
розширюваність, структурованість і можливість перевірки правильності
документів. Оскільки XML є підмножиною SGML, то будь-яка система,
повністю сумісна з SGML, має здатність обробляти документи XML (але
зворотне твердження не є дійсним). Проте мова XML не призначена для заміни
SGML. До того ж вона не може замінити мови HTML, яка також заснована на
SGML і є додатком цієї мови. У дійсності, XML призначена для використання як
доповнення до мови HTML і повинна забезпечити передачу через WWW даних
різних типів. Завдяки своїм широким можливостям мова XML фактично може
застосовуватися не тільки для розмітки тексту, але й для розмітки звуку або
зображення, тобто мультимедійних даних. У якості прикладів широко
застосовуваних мов, створених на основі XML, можна вказати Mathml
(Mathematics Markup Language – мова математичної розмітки), SMIL
(Synchronized Multimedia Integration Language – мова інтеграції синхронізованих
джерел мультимедійної інформації) і CML (Chemistry Markup Language – мова
хімічної розмітки).
Мова XML уже фактично стала стандартним засобом обміну даними в
індустрії програмного забезпечення. Деякі аналітики припускають, що згодом
мовою XML буде створюватися й зберігатися більшість документів як в
Інтернеті, так і за його межами. Не дивлячись на все це, сама по собі мова не є
моделлю даних, оскільки надає тільки можливості зберігання інформації, і не має
інструментів маніпуляції даними, інструментів опису обмежень, способів опису
схеми.
Для того щоб використовувати XML як повноцінну модель були
розроблені наступні рішення. По-перше, мова опису структури XSD (XML
Schema Definition), що дозволяє описувати схеми даних XML документа. XML
Schema описує спосіб визначення в схемі елемента кожного типу й дає змогу
вказати типи даних, пов’язані з кожним елементом. Схема сама є документом
XML, у якому використовуються елементи й атрибути, що виражають семантику
схеми. А оскільки схема – документ XML, то її можна редагувати й обробляти за
допомогою таких же інструментальних засобів, які застосовуються для обробки
38
описаного нею документа XML. Один з найпростіших способів створення схеми
XML полягає у відстеженні структури документа й визначенні кожного елемента
в міру виявлення.
Елементи, що містять інші елементи, відносяться до типу складних
елементів. По-друге, штучна мова DTD (Document Type Definition), що надає
можливість створення обмежень і вимог до XML документу та його атрибутів. І
нарешті, мови запитів, такі як xpath і xquery, що дозволяють оперувати даними.
Методи, засновані на XML моделі, не вирішують багато проблем, зв’язаних зі
слабоструктурованими даними, тому що не мають необхідного інструментарію
відновлення структури документа й засобів опрацювання виникаючих
невідповідностей оброблюваних даних до очікуваної структури.
Очевидно, що специфікація XML Schema надає повніший і строгіший
метод визначення моделі інформаційного наповнення документа XML, аніж
визначення DTD. Але вона все-таки не забезпечує підтримку необхідного рівня
семантичної функціональної сумісності.
Наприклад, якщо два додатки повинні обмінюватися інформацією за
допомогою XML, то призначення і зміст застосовуваних при цьому документів
повинні бути погоджені з тою структурою даних, яка ними формується. Але для
цього необхідно сформувати модель предметної області з описом даних, які
потрібні для того чи іншого додатка. Це дозволяє чітко визначити, які дані
повинні передаватися в прямому й зворотному напрямках від одного додатка до
іншого. Таку модель зазвичай прийнято описувати в термінах об’єктів або
відношень. А оскільки схема XML описує тільки синтаксичну структуру
документа, то сама модель предметної області може бути представлена у вигляді
схеми XML багатьма різними способами. Тому неможливо визначити
безпосередню відповідність між моделлю предметної області й певною схемою
[10]. Ця проблема стає ще складнішою, якщо в обміні інформацією повинні брати
участь не два, а кілька додатків. У такому випадку недостатньо просто
встановити відповідність між декількома схемами XML, оскільки завдання тут
полягає не у перетворенні однієї синтаксичної структури в іншу, а у встановленні
39
відповідності між об’єктами й відношеннями, що належать до декількох
предметних областей.
Таким чином, для розв’язання описаної вище задачі необхідно виконати
три етапи:
1 відновити первісні моделі предметних областей зі схем XML;
2 визначити відповідності між об’єктами моделей предметних областей;
3 визначити механізми перетворення для документів XML, наприклад, за
допомогою мови XSLT (Еxtensible Stylesheet Language
Transformations).
Ці етапи на практиці іноді стають дуже складними, тому може виявитися,
що мова XML добре підходить для обміну даними тільки між додатками, для
яких уже відома модель інформаційного наповнення, але погано підходить для
тих ситуацій, коли до обміну даними приєднуються все нові й нові додатки.
Доступ до слабоструктурованої інформації в XML- представленні
Можна виділити такі методи й мови доступу: Xpath (XML Path), Xlink
(XML Linking); Xpointer (XML Pointer).
Xpath – це декларативна мова запитів для XML, у якій передбачені прості
синтаксичні конструкції для адресації окремих частин документа [13]. У мові
Xpath визначено 13 типів осей (обов’язкових частин), включаючи ancestor
(предок), attribute (атрибут) і child (нащадок). Предикат повинен бути укладений
у квадратні дужки й знаходитись після базису. Якщо елемент містить більше
одного субелемента, для вибірки конкретного субелемента може
застосовуватися конструкція [position{)= ’positionnumber’], де positionnumber –
номер позиції, що починається з 1. У мові Xpath підтримується повний і
скорочений синтаксис.
Мова Xlink дозволяє вставляти в документи спеціальні елементи, за
допомогою яких можна створювати й описувати посилання між ресурсами [12].
У ній застосовується синтаксис XML для створення структур, що дозволяють
описувати посилання, аналогічні простим, односпрямованим гіперпосиланням
HTML, а також складніші посилання. Посилання Xlink можуть ставитися до
40
одного із двох типів: простого і розширеного. Просте посилання з’єднує джерело
з ресурсом призначення, а розширене посилання з’єднує будьяку кількість
ресурсів. Крім того, ця мова надає можливість зберігати посилання в окремій БД
(її називають базою посилань Unkbase). Тим самим надається можливість
домогтися в деякій мірі незалежності від місцезнаходження ресурсів: навіть у
випадку зміни посилань вихідні документи XML залишаються незмінними, і
відновлення вносяться тільки в базу посилань.
Мова Xpointer надає доступ до значень атрибутів або до вмісту елементів,
що перебувають у будь якому місці документа [14]. Будь-який покажчик
Xpointer, за суттю, являє собою вираз Xpath, що входить в ідентифікатор URІ.
Крім усього іншого, мова Xpointer дозволяє сформувати посилання на
розділи тексту, вибрати конкретні елементи або атрибути й перейти з одного
елемента на інший. Ця мова дає можливість також здійснити вибірку інформації,
що знаходиться більше ніж в одному наборі вузлів, тоді як за допомогою мови
Xpath це завдання виконати неможливо. Крім визначення вузлів, у мові Xpointer
визначаються також точки й діапазони, які в комбінації з вузлами дозволяють
позначити місцезнаходження даних. Точка – це позиція в документі XML, а
діапазон позначає всю структуру й інформаційне наповнення XML між
початковою й кінцевою точками, причому й та, і інша можуть перебувати в
середині вузла.
Слабоструктурована інформація в RDF-представленні
Інфраструктура опису ресурсів (Resource Description Framework - RDF),
розроблена під егідою W3C, являє собою інформаційне середовище, яке
забезпечує кодування, обмін і повторне застосування структурованих метаданих
[101]. Ця інфраструктура забезпечує функціональну сумісність метаданих різних
додатків за рахунок застосування таких проектних механізмів, які дозволяють
створювати загальноприйняті угоди по семантиці, синтаксисі й структурі
документів. Інфраструктура RDF не визначає семантику кожної розглянутої
предметної області, а надає можливість створювати в міру необхідності
елементи метаданих для таких предметних областей. В інфраструктурі RDF у
41
якості загального синтаксису для обміну й обробки метаданих застосовується
мова XML. За допомогою засобів мови XML створюються моделі даних RDF,
структура яких забезпечує опис семантики, а також дозволяє створювати
однаковий опис і забезпечувати обмін стандартизованими метаданими.
Найпростіша модель даних RDF складається із трьох об’єктів.
1 Ресурс. Ресурсом є все, що може мати ідентифікатор URL, наприклад,
Web-сторінка, ряд Web-сторінок або навіть частина Web-сторінки, така
як елемент XML.
2 Властивість. Це – конкретний атрибут, який служить для опису
ресурсу. Наприклад, атрибут Author може використовуватися для
опису особи, що підготувала конкретний документ XML.
3 Оператор. Це – конструкція, що складається з комбінації ресурсу,
властивості й значення. Компоненти оператора RDF прийнято називати
«суб’єктом», «предикатом» і «об’єктом».
Схема RDF дозволяє представити інформацію про класи, що входять у
схему, у тому числі про їхні властивості (атрибути) і про зв’язки між ресурсами
(класами). Інакше кажучи, механізм визначення схеми RDF надає базову систему
типів для використання в моделях RDF, аналогічно схемі XML.
Схеми RDF надають також можливість визначити деяку частину
обмежень, зокрема вказати необхідну кардинальність і визначити припустимі
властивості екземплярів класів. Для визначення схеми RDF застосовується
декларативна мова, створена під впливом ідей з області представлення знань
(наприклад, семантичних мереж і логіки предикатів), а також моделей
представлення схем БД, таких як двійкові реляційні моделі й моделі даних на
основі графів.
Слабоструктурована інформація в документо-орієнтованому
представленні
Грунтовний виклад методів документо-орієнтованого зберігання подано в
роботі [27]. В основі цих методів лежать колекції даних, тобто набори, у яких
збираються однотипові за деякими ознаками документи. Колекції призначені для
42
узагальнення однотипних документів, підтримки схем даних документа й
забезпечення підтримки групових операцій над документами. Для кожної
колекції може бути визначена своя схема даних, свій пошуковий індекс і
додаткова інформація про мітки. Якщо проводити паралель із реляційними
моделями даних, то колекція – це аналог кортежів (таблиць), з єдиною
відмінністю, що про зв’язки між колекціями мова навіть не йде. Документ сам
по собі представляє одиницю зберігання даних і кожний з них не залежить від
інших. При роботі зі слабоструктурованими даними тип подання інформації
може мінятися від документа до документа в рамках однієї колекції. Це показує
ступінь відмінності з реляційними моделями, де тип видачі інформації із БД
визначається заздалегідь, при проектуванні схеми даних.
Для ідентифікації документів кожному документу присвоюється
універсальний ідентифікатор. У якості ідентифікатора можна використовувати
рядок, що має достатню складність і довжину для забезпечення унікальності.
Найкращим варіантом вважається застосування хеш-функцій MD5. Над
документами в колекції визначені такі операції:
1 Додавання нового документа. Головна особливість операції додавання
полягає в тому, що знання схеми даних для даної операції не потрібно,
більше того, колекції в момент вставки документа може не існувати. У
момент вставки, модель повинна перевірити документ, що додається,
скорегувати або створити схему даних, і повинна зберегти дані про
операцію для подальшої статистичної обробки.
2 Відновлення документа. Вона визначена тільки цілком для документа.
Таке штучне обмеження дозволить перенести контроль атомарності на
рівень цілого документа. Відсутнє поняття «ізоляції». Будь-які дані, які
зчитуються одним користувачем, можуть паралельно змінюватися
іншим клієнтом. За рахунок відсутності механізму блокувань і
контролю цілісності даних виходить збільшення швидкості роботи БД.
3 Операція видалення документа. Операція може бути виконана тільки за
будь-якою пошуковою умовою.
43
Документи мають значення елементи-атрибути. З них формується весь
документ, і вони, за суттю, є найменшою одиницею даних, якою можна
оперувати за допомогою документо-орієнтованої моделі. На відміну від
класичних реляційних моделей атрибути не мають строгої типізації, тому що
оброблювані дані не мають явно вираженої структури. Наприклад, той самий
атрибут у різних документах однієї колекції може бути представлений як
текстом, так і числом. Значення в атрибутах не мають обмежень на довжину й
можуть бути змінені тільки спільно з усім документом; таким чином, операція
відновлення (зміни) вмісту одного атрибута не визначена. Для контролю
коректності даних, що вводяться, визначені спеціальні функції-валідатори, що
беруть на себе завдання з контролю обмежень, наявних для атрибутів.
Функції-валідатори призначені для організації гнучкої типізації даних у
БД, тому що слабоструктуровані дані найчастіше представлені неформальною
мовою, у зв’язку із чим виникає завдання визначення типів даних. При цьому
найчастіше неможливо однозначно визначити тип даних атрибута, тому
завдання його розпізнавання перебирають на себе зазначені функції, що
аналізують зміст атрибута та повідомляють наскільки (якою мірою) даний
атрибут відповідає шуканому типу даних.
Елементи реалізації ідеї слабоструктурованої обробки й зберігання даних
є в безсхемних БД, що відносяться до типу NoSQL(Not Only SQL, не тільки SQL)
[28] систем. Їхньою особливістю, зокрема, є горизонтальне масштабування,
сховища даних та підтримка пошуку й індексування по довільних полях, а в
деяких БД є можливість формування будь-яких запитів вибірки даних.
Найпростішим способом реалізації слабоструктурованого зберігання
даних є динамічне сховище ключів і значень, яке реалізовано в БД Redis і Riak.
Іншим підходом до забезпечення можливості динамічної зміни структури БД є
стовпчикова реалізація зберігання даних (протилежно до рядкової в реляційних
БД), при якій є можливість визначення різної кількості стовпців для різних
рядків. За таким принципом влаштовані БД Hbase, Cassandra, Hypertable.
44
До таких, зокрема, відносять БД Mongodb, Couchdb. У БД Mongodb
документ буде ставитися й зберігатися в якій-небудь колекції, а форматом
зберігання служить структура мовою JSON. Схема БД Mongodb повністю
змінювана, використовує технологію Google Mapreduce, що допускає побудову
широкого спектра індексів документів: унікальних, складних, геопросторових і
вкладених. Для стійкості й надійності зберігання даних застосовується
атомарність операцій, журналювання, технологія асинхронної реплікації із
сегментацією по декількох наборах реплік. Безсхемна БД Couchdb також
використовує масово-облікові функції тарreduce, інтерфейс REST API для
безпосередньої обробки вилучених даних через HTTP протокол, а також формат
опису даних JSON.

Рис. 2.1. Співвідношення структурованої й слабкоструктурованої інформації в
Digital Universe

Поряд із привабливими можливостями документо-орієнтованого
зберігання даних є й особливості, які не дуже приймають розробники
автоматизованих систем на основі БД. Серед таких: відсутність транзакцій,
неможливість автоматичного приведення типів даних, ускладнена робота з
45
масивами даних у відношенні їх сортування й фільтрації, вимога приведення
даних до певного формату й відсутність інших звичних функцій БД.
Великі обсяги даних вимагають нових підходів і методів добування знань
і даних з них. У зв’язку з тим, основні наукові положення пов’язані з розробкою
графових моделей зберігання слабоструктурованої і нечіткої інформації.
Подальші положення стосуються цих методів і їх реалізацій. Тому необхідно
виконати докладний аналіз місця графових моделей даних у сучасних
аналітичних системах і платформах [16].

Рис. 2.2. Співвідношення мультиструктурних моделей даних і реляційних
моделей

За оцінками інформаційно-аналітичної компанії IDC (International Data
Corporation) обсяги «цифрового всесвіту» (Digital Universe) [66] до 2023 року
можуть досягти 40 зеттабайт, тобто 40 трильйонів гігабайтів, з яких до 80% буде
становити так звана погано-, слабоструктурована інформація, що циркулює у
вигляді інтервальних медіа-потоків, інформації соціальних мереж, медіа-мереж,
мережних мобільних пристроїв і так далі. Графічна ілюстрація, за даними IDC,
наведена на рис. 2.1, показує співвідношення структурованої й
слабоструктурованої інформації в сучасній Digital Universe.
46
Превалювання слабоструктурованих даних над структурованими, як і
мультиструктурної моделі даних над реляційною моделлю, відзначається й в
аналітичних матеріалах досліджень ІТ-ринку компанією Gognizanl, рис. 2.2.
Основними постачальниками, оброблювачами й сховищами даних у
сучасній Digital Universe є розподілені мережні системи й пристрої різного
призначення.

2.2. Формальний опис структури Великих даних
Яскравим прикладом Великих даних є масив даних, що описує
функціонування:
− обсяги інформації у петабайтах;
− необхідність обробки структурованої та неструктурованої інформації;
− он-лайн аналіз даних для швидкого доступу до детальних даних.
Отже, у підсумку існує:
− великий набір сутностей: особи, місця, організації (фізичні, юридичні),
дати, природні ресурси (річки, ліси, озера), рекреаційний фонд
(історичні пам’ятки, санаторії), законодавчі акти та звіти;
− величезна база даних особливостей: документи для інтелектуального
аналізу даних, онтологічні терміни, словники даних, які дозволяють
зв’язати деякі об’єкти.
У подібних ситуаціях, коли у нас є кілька сутностей, пов’язаних з
харакетристикою, використаємо кількісне представлення інформації, тобто
кількість бінарних запитань (так, ні), які необхідно задати, щоб знайти потрібний
об’єкт. Загалом, якщо ми знаємо, що невідомий об’єкт належить множині, що
складається з N елементів, то ми можемо розділити цей набір на дві половини і,
задаючи двійкові питання, з’ясувати, до якої половини належить шуканий
об’єкт. Отже, тоді кількість об’єктів становитиме N/2. Продовжимо далі таку ж
процедуру: задамо друге питання, для чого поділимо виділену половину ще на
дві половини. Отже, після двох запитань матимемо N/4 об’єктів, серед яких є
шуканий. Після трьох запитань матимемо N/8. Загалом, після відповіді на q
47
бінарних запитань матимемо множину з 2 -q елементів, що містить необхідний
об’єкт [12].
Таким чином, той факт, що сутність пов’язана з характеристикою f,
дозволяє зменшити кількість питань до

Крім того, ефект кількох асоціацій може бути описаний шляхом
підрахунку кількості додаткових бінарних питань, які ми можемо задавати, щоб
і надалі знати асоціацію з необхідною сутністю. Кожне бінарне запитання
зменшує кількість об’єктів на половину; q питань зменшують кількість до n.
Для кожної сутності e маємо кількість питань I(e, f) для різних
характеристик f . Значення важливості необхідно нормалізувати:

Ця відстань залежить від кількості характеристик: наприклад, якщо на
додаток до документів, ми зберігаємо їх копії, відстань збільшується вдвічі. Щоб
уникнути цієї залежності, відстань d(e1,e2), як правило, нормалізується в
інтервалі [0,1] через ділення на максимально можливе значення цієї відстані.
На рис. 2.3 показано використання моделі «сутність-характеристика» для
порівняння схем даних реляційної бази даних та NoSQL бази даних. У першу
чергу визначається, у скількох джерелах характеристики асоціюються з
вказаними сутностями. Далі ця інформація може бути використана для
48
порівняння схем за сутностями. Введемо поняття моделі асоціацій між об’єктами
та характеристиками для різних категорій NoSQL баз даних.

Рис. 2.3. Порівняння схеми реляційної бази даних та NoSQL бази даних з
допомогою моделі «сутність-характеристика»
49
2.3. Схеми асоціацій між об’єктами та характеристиками для різних
класів NoSQL баз даних
Для версійного розподіленого зберігання великих обсягів даних
спроектована модель, що використовується у системі BigTable компанії Google:
− неповна реляційна модель даних;
− підтримка динамічного контролю над розміщенням даних.
У базі пошукача іменами рядків можуть слугувати адреси документів з
інтернету, а іменами стовпців – особливості цих документів (наприклад, зміст
документа може зберігатися в стовпці «content:», а посилання на дочірні сторінки
– в шпальтах «anchor:»). Інший приклад – карти Google, що складаються з
мільярдів зображень, кожне з яких деталізує ту чи іншу географічну ділянку
планети. У Bigtable карти Google структуруються таким чином: кожному рядку
відповідає один географічний сегмент, а стовпцями є зображення, з яких цей
сегмент складається, у різних стовпчиках зберігаються зображення з різною
деталізацією.
Рядки Bigtable (їх максимальна довжина може досягати 64 кілобайти) теж
важливі. Операція звернення до рядка є атомарною (це означає, що, поки одна
програма звертається до рядка, жодна інша не має права змінювати дані в
сімействах стовпців цього рядка). А ще рядки зручно сортувати. У прикладі з
URL документа, зробивши його запис реверсивним, легко впорядкувати всі
рядки за іменем домена третього рівня.
Вміст сторінок в інтернеті постійно змінюється. Щоб врахувати ці зміни,
кожній копії даних, що зберігаються в стовпці, присвоюється тимчасова мітка
(timestamp). У Bigtable тимчасовою міткою слугує 64-розрядне число, яке може
кодувати час і дату так, як це потрібно клієнтським програмам. Наприклад,
timestamp для копій веб-сторінки в стовпці «contents:» є датою і часом створення
цих копій. Використовуючи тимчасові мітки, додатки можуть задати в Bigtable
пошук, наприклад, тільки найостанніших копій даних.
Отже, для предметної області будь-якого сервісу Google можна створити
власну карту даних Bigtable, що містить довільне число рядків і унікальний для
50
цієї предметної області набір сімейств стовпців. Неминучі повтори даних у
стовпцях упорядковуються за тимчасовими мітками. Усе це вказує на повну
відсутність підтримки властивостей ACID.
Але головною перевагою цього підходу є те, що таку базу неважко порізати
на незалежні шматочки і розподілити на множині серверів. Відсортовані за
алфавітом рядки діляться на діапазони, які іменуються «Таблет» (tablet) –
несамостійними таблицями. Оскільки рядки в кожному Таблеті відсортовані за
ключовим іменем, то клієнтським додаткам дуже просто знайти потрібний
таблет, а в ньому – потрібний рядок.
В цій моделі ключ ідентифікує рядок, який містить дані, що зберігаються
в одному чи декількох сімействах стовпчиків. В рамках таких сімейств кожен
рядок може мати багато значень стовпчиків. Значення в кожному стовпці містять
мітку часу, тому декілька значень-відповідностей між рядком і стовпчиком
можуть знаходитися в рамках одного сімейства стовпчиків.
Bigtable – це велика і розподілена система для об’єктів, що
синхронізуються, тому замість них застосовується розподілений сервіс
блокувань (distributed lock service), який в Google називають Chubby. Його роль
в Bigtable можна порівняти з роллю транзакцій в звичайних СУБД [27].
Для кожного таблет-сервера Chubby створює спеціальний chubby-файл.
Завдяки цьому файлу Bigtable Master завжди відомо, які з серверів працездатні.
Ще один chubby-файл містить посилання на розташування кореневого таблета
(Root-tablet) з даними про розташування всіх інших таблетів. Цей файл
повідомляє майстру, який з серверів якими таблетами керує.
Безумовно, використання сервісу Chubby в Bigtable якоюсь мірою вирішує
завдання підтримки несуперечливості даних у розподіленому середовищі з
безліччю реплік. Але несуперечливість буває різною. Bigtable стала першою
спробою досягти балансу між продуктивністю системи, її масштабованістю і
несуперечливістю даних. Результатом стала підтримка так званої слабкої
несуперечливості, яка, в принципі, задовольняє вимоги більшості працюючих з
Bigtable сервісів. На рис. 2.4 показано, як користувач шукає свій таблет [18].
51

Рис. 2.4. Ієрархія таблетів

Структура XML-документа, що складається з вкладених елементів-тегів
добре відома, її відмінність від розглянутої вище графової моделі полягає, в
основному, у трактуванні тегів і міток: в графах мітки використовуються як
позначення зв’язків між елементами схем даних, і мітки не потрібні для
позначення елемента, а в XML документно-орієнтованій моделі потрібно, щоб
кожний (нетекстовий) елемент даних мав ідентифікуючу ознаку. Також XML
транслюється в структуру даних «дерево», що є частковим випадком графової
моделі.
У графовій моделі XML для слабоструктурованих даних необхідно
використовувати спеціалізовані типи атрибутів, такі як ID, IDREF, IDREFS.
Зазначені типи дають змогу організувати зберігання перехресних посилань в
XML-елементах виду <eid,vahie> (<ідентифікатор елемента, значення>) і
атрибутах виду < label, eid> (<мітка, значення>).
Існує кілька видів RDF-даних як графової моделі: RDF / XML, N3, Turtle,
RDF / JSON. Опис ресурсів у вигляді RDF-набору даних – це трійка «суб’єкт»-
«предикат»-«об’єкт», тобто для множини U (Universal Resource Identifier, URI,
уніфікований ідентифікатор ресурсів) – елементи f, множини В {Black nodes,
порожніх вузлів), множини L {Literal, RDF-літералів), визначається набір (f, e(f),
e), де f – «суб’єкт»; e(f) – «предикат»; e – «об’єкт».
52
Отже, Великі дані поєднують різні моделі даних. Для цього повинні
існувати методи їх перетворення з мінімальною втратою даних. Однією з
технологій, що доцільно використовувати для роботи з Великими даними, є
простір даних.

Висновки
Удругому розділі отримано наступні результати:
1. У розділі побудовано модель даних «сутність-характеристика» для
Великих даних, що дає змогу опрацьовувати дані різних форматів.
2. Для аналітичного опрацювання Великих даних використано сховище
даних, що дає змогу працювати з Великими даними без проміжного
збереження і тим самим зменшує обчислювальну та ємнісну складність
виконання запитів.
3. Визначено моделі асоціацій об’єктів та характеристик основних
представлень даних в NoSQL. Побудовано інформаційну структуру
Великих даних. Усе це стало основою для продовження досліджень і
зосередженню на проблемі опрацювання різнорідних даних без їх
попередньої інтеграції.
4. Для представлення Великих даних використано простір даних, який дає
змогу працювати з різнотипними даними. Проте основною операцією
інтеграції даних є не консолідація, що дає змогу зменшувати ємнісну
складність запитів.

53
РОЗДІЛ 3
ЗАБЕЗПЕЧЕННЯ НАДІЙНОСТІ ІНФОРМАЦІЇ У БЛОКЧЕЙН-
ТЕХНОЛОГІЇ

3.1. Основні характеристики технології блокчейн
Починаючи з 2009 року все більшої популярності набувають інформаційні
системи, що базуються на технології блокчейн (англ. block chain). Блокчейн – це
технологія обробки даних, в якій можна виділити такі основні принципи [54]:
− структура зберігання даних є вибудованою за певними правилам
ланцюжок блоків, що містять інформацію;
− кожен блок ланцюжка пов'язаний із сусідніми блоками за допомогою
відомостей про хеш-суму попереднього блоку;
− самі по собі блоки та інформація, що міститься в них, є
загальнодоступними;
− копії ланцюжка блоків зберігаються на різних комп'ютерах.
Блоки ланцюжка складаються з наступних основних елементів:
− «корисні» дані;
− службова інформація;
− хеш-сума попереднього блоку ланцюга;
− хеш-сума поточного блоку ланцюга.
«Корисними» даними може бути будь-яка інформація, у розподіленому
зберіганні якої виникає потреба. Службова інформація може містити, наприклад,
час створення блоку, складність обчислень, довільне число для обчислення хеш-
суми. Хеш-сума попереднього блоку використовується для однозначного
впорядкування блоків. Винятком є хеш-сума попереднього блоку, що вказується
в першому блоці (генезис блоці) – вона, як правило, генерується випадковим
чином. Хеш-сума поточного блоку забезпечує достовірність інформації, що
міститься в блоці, і пов'язує його з наступним блоком ланцюга. У загальному
54
вигляді ланцюжок блоків представлений на рис. 3.1. У процесі розвитку
технології блокчейн основні її принципи також розвиваються та змінюються.

Рис. 3.1. Узагальнена схема ланцюжка блоків

На сьогоднішній день умовно можна виділити п'ять поколінь технології
блокчейн.
Перше покоління технології блокчейн
Перше покоління ланцюжків блоків (блокчейн 1.0) є основою цифрових
систем грошових розрахунків, першим та найбільш популярним представником
яких є запущений у 2009 році біткоін [5]. Одним із головних недоліків біткоїну є
метод обчислення хешу. Оскільки вирішення завдання обчислення хешу
проводиться децентралізовано, переможцем може бути лише один учасник
обчислень (майнер).
Отже, більшість роботи, проведеної майнерами, виконується марно, так як
виконувані обчислення не виконують жодної корисної мети. На грудень
2021 року загальна обчислювальна потужність (хешрейт) майнерів біткоїну
становить приблизно 174 квінтильйону хешей в секунду. Звідси випливає ще
один недолік – тенденція до централізації обчислень. На ранніх етапах
переможцями могли ставати майнери одинаки, але на сьогоднішній день, зі
збільшенням загальної обчислювальної потужності майнерів і, як наслідок,
складності обчислень, єдиним способом обчислити хеш швидше решти (і
55
отримати винагороду) є об'єднання майнерів. Відповідно до звіту фірми з
управління цифровими активами CoinShares, за станом12 на червень 2021 року
близько 65% ефективної обчислювальної потужності обладнання, задіяного в
видобутку криптовалюти, зосереджено у Китаї.
Друге покоління технології блокчейн
Друге покоління ланцюжків блоків (блокчейн 2.0) підтримує виконання
функцій реєстрації, підтвердження та передачі не тільки валюти, а й інших видів
активів – всіх видів контрактів та власності. Протоколи блокчейн другого
покоління можуть використовувати як розподілений журнал записів біткоїну,
так і створювати власні розподілені журнали записів.
Можна виділити наступні напрямки застосування технології блокчейн
другого покоління:
− розумні активи;
− розумні контракти;
− гаманці;
− децентралізовані додатки (Decentralized Applications, DApps) [6],
децентралізовані автономні організації та корпорації (Decentralized
Autonomous Organization/Corporation, DAO/DAC) [7–5],
децентралізовані автономні товариства (Decentralized Autonomous
Society, DAS);
− штучний інтелект.
Розумні активи дозволяють робити угоди з будь-якою власністю – як
матеріальною (наприклад, нерухомістю, транспортними засобами), так і
віртуальною (акціями, замовленнями, авторськими правами тощо). Після
реєстрації активу у розподіленому журналі записів, управління власністю на
нього переходить до власника секретного ключа. Передача секретного ключа
означає передачу власності. Загальний зміст розумних контрактів випливає з ідеї
розумних активів. Розумний контракт – це спосіб здійснення угоди у
розподіленому журналі записів, заснований на використання криптовалюти та
розумних активів для формування угод за допомогою технології блокчейн.
56
Прикладом розумного контракту є транзакція, що знаходиться в розподіленому
журналі записів незадіяним, поки не настане певна дата або подія – передача
спадщини у день смерті власника активу, здійснення купівлі або продажу на
біржі з появою будь-якої новини, автоматична передача прав на власність від
фінансової компанії фізичній особі після всіх виплат за позикою, тощо.
Повсюдне впровадження механізмів керування доступом (QR-коди,
доступ до Wi-Fi, датчики, програмний код тощо), заснованих на застосуванні
технології блокчейн, дозволить значно спростити та прискорити процедуру
забезпечення доступу. У частині судової практики, точно укладені угоди та
впровадження автоматизованих механізмів їх виконання можуть суттєво
зменшити кількість суперечок [20]. Спільне використання розумних активів та
розумних контрактів уможливлює побудову системи кредитування,
використовуючи як заставу розумні активи позичальника, що знижує витрати на
страхування від шахрайства та неправомірних дій і, як наслідок, здатне зробити
кредитування значно безпечнішим і вигіднішим [61]. Відмінною рисою
розумного контракту є необхідність довіри між учасниками – розумний контракт
виконується автоматично, що працює на технології блокчейн кодом, який не
залишає місця для людського чинника Однак, на сьогоднішній день застосування
розумних контрактів вимагає серйозного доопрацювання нормативно-правової
бази, що регулює процедури виконання контрактних зобов'язань [32].
Третє покоління технології блокчейн
Одним із ключових напрямків розвитку технології «блокчейн» третього
покоління є застосування методу, заснованого на застосуванні прямих
ациклічних графів (Directed Acyclic Graph, DAG). Прямі ациклічні графи – це
структура обробки даних, в основі якої лежить топологічне дерево.
Розташування блоків у такій структурі не обов'язково має бути послідовним (як
у технологіях блокчейн 1.0 та 2.0) та може забезпечувати прямі зв'язки між будь-
якими транзакціями ланцюга. Ланцюг у такій структурі починає формуватися
вже не з блоків, а з транзакцій. Хеш при цьому обчислюється з батьківської
транзакції і передається до наступної, пов'язаної з нею, транзакції. Основними
57
перевагами застосування прямих ациклічних графів є швидкість, простота
забезпечення зростання та підвищена безпека системи обробки даних. У
ланцюжку блоків першого покоління для створення нового блоку потрібно
близько 10 хвилин (біткоїн). Блок ланцюжки другого покоління створюється за
20 секунд (Ethereum). Із застосуванням прямих ациклічних графів пропадає
необхідність збирання транзакцій у блоки, що в теорії забезпечує проведення
сотень тисяч транзакцій на секунду. Відмова розробників систем, заснованих на
технології блокчейн, від високої складності обчислення хешу призводить до
необхідності об'єднання майнерів у пули, що, у свою чергу, призводить до
більшої децентралізації мережі та, як наслідок, більшої безпеки.
Загалом, незалежно від застосування прямих ациклічних графів, третє
покоління ланцюжків блоків дозволяє реалізовувати розв'язання завдань, не
пов'язаних з грошовим обігом та ринковими транзакціями. Прикладами таких
рішень є:
− служби ідентифікації (система безпеки електронної пошти KeyID,
системи зіставлення 32-розрядних буквено-цифрових ідентифікаторів з
ім'ям, що легко читаються. OneName та BitID, системи ідентифікації на
базі адреси біткоін-гаманця типу Bithandle);
− служби атестації, які забезпечують доказ авторства (наприклад,
вебслужба Proof of Existence) та цілісність документів: існування
заповітів, договорів, довіреностей, медичних свідоцтв, боргових
розписів);
− персоніфікований уряд, який забезпечує моментальні виплати
криптовалюти активним учасникам соціальних взаємовідносин
(наприклад, переказ коштів потерпілим внаслідок дорожньо-
транспортної пригоди);
− керуючі служби, що переймають на себе частину традиційних
державних послуг (наприклад, укладання шлюбів з наступною
прив'язкою договору опіки над дитиною, прав володіння нерухомістю
тощо);
58
− системи ідентифікації особи, які забезпечують людей міжнародними
паспортами, які не прив'язані до конкретної держави (проект World
Citizien [63]);
− рішення, спрямовані на боротьбу з цензурою в Інтернеті (проекти по
децентралізації DNS (Namecoin, забезпечує функціонування доменних
імен верхнього) рівня .bit), WikiLeaks (wikileaks.bit), записів Twitter
(проект Alexandria) і т.п.).
Четверте покоління технології блокчейн
Прикладами рішень, основаних на технології блокчейн четвертого
покоління, є Opporty Plasma Cash, PolkaDot, Universa та EOS.
Opporty Plasma Cash – це рішення, спрямоване на підвищення
масштабування ланцюжків блоків. Оптимізація навантаження на мережу
досягається зменшенням даних, переданих із дочірніх ланцюжків у кореневий
ланцюжок блоків. Це дозволяє знизити комісійні за транзакції для смарт-
контрактів та децентралізованих додатків. У основі цього рішення лежить
твердження про те, що користувачеві необхідно мати відомості лише про
транзакції, що містять монети, які вони хочуть відстежувати. Таким чином, для
користувача відсутня необхідність завантаження цілих блоків ланцюжка. На
сьогодні це рішення дозволяє досягти швидкості роботи мережі в 5000
транзакцій у секунду.
PolkaDot – це блокчейн-екосистема, що забезпечує об'єднання
різноманітних ланцюжків (обмін даними між ланцюжками, заснованими на
різних варіаціях технології "блокчейн"), а також загальну інформаційну безпеку.
У перспективі також планується забезпечення роботи децентралізованих
додатків та інших сервісів. В якості механізму досягнення консенсусу у проекті
використовується доказ концепції. До складу екосистеми PolkaDot входять такі
основні компоненти: сполучна мережа (Relay Chain) – центр системи, що
забезпечує обмін транзакціями між ланцюжками, досягнення консенсусу, а
також загальну безпеку екосистеми; парачейни (Parachains) – різнорідні
ланцюжки блоків, які забезпечують проведення транзакцій; мости (Bridges) –
59
своєрідні посилання на ланцюжки блоків, що мають власні механізми
досягнення консенсусу. Серед основних суб'єктів екосистеми PolkaDot можна
назвати: колаторів (керують парачейнами, збирають транзакції користувачів,
підтверджують блоки з урахуванням алгоритму Proof of Validity; одержують
нагороду у вигляді 100% комісій мережі); валідаторів (підтверджують
інформацію, що міститься в блоках парачейнів; додають нові блоки в ланцюг-
ретранслятор; за верифікацію даних одержують токени проекту); номінатори
(підбирають надійних валідаторів, забезпечуючи захист ланцюга-
ретранслятора); фішермени (відстежують порушення з боку валідаторів; за
виявлені факти порушень одержують значну нагороду). Усього випущено 1 млрд
монет. Передбачається, що власники токенів повинні мати повний контроль над
екосистемою, винагороджуватися за хорошу поведінку та втрачати токени за
погану. PolkaDot – проект 2016 року, авторства Гевіна Вуда. Нині управляється
швейцарським фондом Web3.
EOS – це блокчейн-платформа, призначена для забезпечення роботи
децентралізованих додатків. Акцент, зроблений на масштабованість, а також
нульові комісії за транзакції роблять її конкурентом Ethereum. Відносна
централізація забезпечує швидкість роботи тисячу транзакцій в секунду. За
заявою розробника, платформа здатна забезпечити обробку кількох мільйонів
транзакцій за секунду. У якості алгоритму консенсусу використовується
делегування доказу частки (Delegated Prof of Stake). Відносини між ними
регулюються смарт-контрактами. Творцем платформа є компанія Block.one. ICO
EOS організовано у червні 2017 року та за рік забезпечило збирання понад
$4 млрд. Запуск мережі відбувся у червні 2018 року.
П'яте покоління технології блокчейн
До технічного рішення, заснованого на п'ятому поколінні технології
блокчейн, можна віднести проект Telegram Open Network (TON). TON – це
платформа для створення блокчейн-екосистеми, що забезпечує зберігання
персональних даних («телеграм паспорт») у хмарному сховищі та реєстрації в
сервісах, що вимагають підтвердження особистості.
60
TON складається з наступних основних елементів [14]:
− ланцюжок блоків (TON Blockchain) – основний компонент TON [5];
− мережа (TON Network) – забезпечує комунікації всіх компонентів TON;
− служби та програми (TON Services and Applications) – платформа для
прикладних сервісів;
− система оплати (TON Payments) – забезпечує платежі.
Основні типи блокчейн-систем
Загалом блокчейн-системи можна підрозділити на дві групи, зумовлені
можливістю розмежування – публічні (Public Blockchain) та приватні (Private
Blockchain). У публічних системах доступ до участі в роботі мережі відкритий,
будь-хто може вносити нові записи та отримувати доступ до читання існуючих.
Подібні рішення доцільно застосовувати у криптовалютах. Прикладами таких
систем є Біткоїн, Ethereum, Litecoin.
У приватних системах для внесення нових записів чи читання існуючих
потрібно розширення. Серед областей застосування таких систем можна
виділити корпоративні системи. Прикладами таких систем є Hyperledger,
Hashgraph, R3 Corda та Quorum.
Доцільність застосування технології «блокчейн»
У роботі [7] показано доцільність застосування технології блокчейн, а
також для уточнення типу блокчейн-системи необхідно звернути увагу на такі
основні умови обробки даних:
− наявність необхідності у зберіганні даних;
− наявність необхідності запису даних кількома користувачами;
− відсутність довіреної третьої сторони, яка підтверджує дані;
− наявність або відсутність необхідності в анонімності;
− наявність або відсутність необхідності у публічній перевірці даних (для
визначення необхідності застосування публічної ексклюзивної системи
(Public Permissionless Blockchain) або приватної ексклюзивної системи
(Private Permissionless Blockchain)).

61
3.2. Визначення механізму досягнення консенсусу
Загальний порядок забезпечення обробки даних у розподіленому реєстрі
персональних даних (РРПДн)
При побудові РРПДН необхідно вирішити наступні задачі:
− визначити мету обробки ПДн, а також відповідний склад ПДн, обробку
яких доцільно здійснювати у розподіленій системі;
− визначити загальну архітектуру РРПДн;
− визначити порядок зберігання даних;
− розробити механізм досягнення консенсусу, який би стимулював
користувачів до участі у забезпеченні роботи РРПДн, а також
автоматизовану оцінку ризиків внесення та обробки в РРПДн
недостовірних ПДн;
− визначити метод обчислення хеш-функції;
− визначити узагальнений порядок розвитку РРПДн;
− визначити метод розрахунку компрометації ПДн під час їх обробки у
РРПДн.
На рис. 3.2 представлена узагальнена схема запропонованого методу
захисту ПДн за їх обробці в РРПДн.

Рис 3.2. Узагальнена схема методу захисту ПДн при їх обробці в РРПДн
62
Узагальнений порядок досягнення консенсусу
У таблиці 3.1 представлені узагальнені відомості про деякі з найбільш
поширених алгоритмів досягнення консенсусу.

Таблиця 3.1
Узагальнені відомості про алгоритми досягнення консенсусу
№ Найменування
п/п алгоритму Узагальнений опис Приклади
блокчейн-систем
1 Proof of Work Майнери вирішують криптографічні завдання, Bitcoin,
(PoW) щоб створити блок, який потім потрібно додати до Ethereum,
ланцюжка. Цей процес вимагає великої кількості Litecoin,
енергії та обчислювальних потужностей. Система Monero,
спеціально спроектована таким чином, щоб ZCash,
завдання ускладнювалися зі зростанням кількості Dogecoin
блоків у ланцюгу. Коли майнер знаходить блок,
він відправляє його до мережі для перевірки.
Перевірка того, чи належить блок ланцюжку чи ні,
є простим процесом.
2 Proof of Stake Валідатори повинні блокувати деякі зі своїх VCash,
(PoS) монет як ставка. Після цього вони розпочинають BitBay,
перевірку блоків. Коли вони виявляють блок, який Peercoin,
може бути доданий у ланцюжок, вони Qtum,
підтверджують його, ставлячи ставку. Якщо блок Stratis
додається, то валідатори отримують винагорода,
пропорційно ставці.
3 Proof of Stake Доказ часу ставки використовує вік монети. Але Vericoin
Time (PoST) замість того, щоб брати кількість монет для
розрахунку віку, використовується період часу,
протягом якого монети утримувалися за
конкретною адресою.
4 Delegated Значно доопрацьований алгоритм PoS. У DPoS Steemit,
Proof of Stake токени не голосують за самі блоки, але голосують EOS,
/ DPoS за обрання делегатів, які проведуть перевірку від BitShares
свого імені. Делегати періодично переобираються.
Система працює швидко. Якщо обрані вузли
постійно пропускають блоки або публікують
недійсні транзакції, які голосують проти них та
замінюють їх найкращим варіантом.
5 Kafka, RBFT, Комплексне застосування алгоритмів у межах Hyperledger
Sumeragi, однієї системи.
Proof of
Elapsed Time
63
Продовження таблиці 3.1
6 Proof of Алгоритм поєднує переваги Proof of Work і Proof Тестова мережа
Activity (PoA) of Stake. Майнінг починається традиційним Ethereum Kovan
способом.ю майнери змагаються у вирішенні
завдання та отриманні нагороди. Різниця в тому,
що блоки не містять транзакцій, а містять лише
відомості про заголовку та адресу для винагороди
за майнінг.
7 Proof of Burn Майнер відправляє монети на випадкову адресу Slimcoin
згенерованого хешу. Витратити кошти з цієї
адреси практично неможливо, оскільки
ймовірність підібрати до нього ключі майже нуль.
За таке «спалювання» монет майнер отримує
постійний шанс знайти PoB блок та отримати за
нього нагороду. Шанси на майнінг збільшуються
зі збільшенням кількості "спалених" монет. Такий
алгоритм має сенс використовувати лише на
пізніх етапах існування криптовалюти. Цей
алгоритм так само добре підходить для трансферу
зі старих до нових криптовалют.
8 Proof of Кожен майнер обчислює досить великий обсяг Burstcoin
Capacity (PoC) даних, що записується на дискову підсистему
(Жорсткий диск, хмарні системи зберігання).
Такий початковий набір даних у PoC називається
"ділянка". Для кожного нового блоку у блокчейні
майнер читає великий набір даних (1/4096 від
свого загального збереженого обсягу) та повертає
результат (дедлайн) – кількість секунд, що минули
з моменту створення останнього блоку.
9 Proof of Значення кожного користувача у мережі NEM
Importance визначається як кількість коштів наявних у нього
(PoI) на балансі та кількість проведених транзакцій з/на
його гаманець. У на відміну від PoS, який враховує
лише баланс наявних коштів у користувача, PoI
враховує яка кількість коштів і активність
користувача в блокчейн мережі. Такий підхід
залучає користувачів не просто тримати кошти у
себе на рахунку, але й активно використовувати.
10 Proof of Усі транзакції та блоки перевіряються за VeChain
Authority допомогою схвалених акаунтів (валідаторів).
(PoAuthority) Проведення транзакцій та створення блоків
проходить у автоматичному режимі за допомогою
обчислювальних потужностей валідатора

64
3.3. Інформаційні системи аналізу процесів
Засоби аналізу поведінки користувачів та процесів (далі – ЗАКП) стали
одним із напрямків розвитку систем управління інформаційною безпекою (далі
– СУІБ).
В даний час ЗАКП, як правило, є розширеннями СУІБ та систем захисту
від витоків інформації (DLP). У завдання ЗКПП входить аналіз дій користувачів
(облік складу даних, з якими працює користувач або процес, контроль пристроїв
і додатків, що використовуються, облік взаємодій з іншими користувачами тощо)
і виявлення аномалій в їх поведінці.
Загалом, під час роботи ЗАКП кожному користувачеві присвоюється
певний рівень надійності, який відбиває загальну адекватність поведінки
користувача у зручному сприйняті адміністратором безпеки.
Прикладами практичного застосування ЗАКП є виявлення аномальних дій:
− від імені службових облікових записів (наприклад, використання
облікових записів, призначених для забезпечення певних сервісів, для
інших цілей);
− від імені привілейованих облікових записів (адміністратор домену
здійснює масовий збір робочих матеріалів користувачів тощо);
− від імені облікових записів звичайних користувачів (активний аналіз
доступних ресурсів, доступ у незвичайний час або з незвичайного
місця, паралельний доступ із кількох місць, різко збільшені обсяги
інформації, що виходить в Інтернет тощо).
Основною відмінністю ЗАКП від систем захисту від витоків інформації
(DLP) є те, що DLP-системи орієнтовані насамперед на аналіз контенту, а ЗАКП
– аналіз контексту.
Будь-яка розподілена в часі або серед кількох зловмисників аномалія
викликає труднощі при виявленні, що ґрунтується на застосуванні експертних
систем. Через велику різноманітність дій користувачів навіть регулярні
оновлення бази даних правил експертної системи ніколи не дадуть гарантії
точної ідентифікації всього діапазону аномалій. Тому сучасні ЗАКП повинні
65
включати інтелектуальні підсистеми, розроблені з використанням методики
машинного навчання. Створення нових блоків не повинно бути завданням, що
потребує значних обчислювальних ресурсів (як у разі застосування методу
підтвердження роботи (Proof of Work [11])). З урахуванням специфіки
аналізованої блокчейн-системи найбільш підходящим є алгоритм Proof of
Authority, призначений для забезпечення роботи приватних мереж і дозволяє
виділяти привілейованих валідаторів. Пропонується розширити його
функціональні можливості процедурою автоматизованої оцінки достовірності
даних, що вносяться в блокчейн-систему. Спочатку право на створення нових
блоків, а також можливість делегування цих блоків.
Узагальнена схема запропонованої процедури підтвердження ПДн, що
вносяться в реєстр, представлена на рис. 3.3.

Рис. 3.3. Узагальнена схема підтвердження даних, що вносяться до реєстру

На рис. 3.3 представлено наступні позначення:
1.1 – шифрування ПДн на пристрої користувача (за необхідності);
1.2-1.3 – передача ПДн у чергу транзакцій РРПДн, розшифрування;
2.1 – ручне підтвердження достовірності ПДн;
2.2 – оцінка ризиків внесення недостовірних ПДн;
3.1-3.4 – генерація нового блоку, шифрування (за потреби);
3.5 – автоматичне підтвердження нового блоку.
66
Машинне навчання є одним із напрямків розвитку штучного інтелекту та
за рахунок застосування різних математичних апаратів (таких як математична
статистика, теорія ймовірностей, чисельні методи оптимізації тощо) дозволяє
вирішувати завдання класифікації, кластеризації, систематизації, передбачення
та регресії.
Крім того, з урахуванням перспектив розвитку СУІБ на базі хмарних
платформ, ЗАКП, здатні забезпечити оперативне виявлення аномалій серед
великої кількості користувачів, набувають особливої актуальності.
Прикладами ЗАКП, які можна використовувати для забезпечення безпеки
конфіденційної інформації є:
− Exabeam Advanced Analytics (одне з перших ЗАКП-рішень, розроблене
компанією Exabeam, США);
− ArcSight User Behavior Analytics (розробка компанії Micro Focus,
Англія);
− Forcepoint UEBA (розробка компанії Forcepoint, США);
− Splunk User Behaviour Analysis (розробка компанії Splunk, США);
− Securonix UEBA (розробка компанії Securonix, США).

Таблиця 3.1
Системний аналіз ЗАКП систем
№ Найменування засобів Країна Наявність Вартість
функції аналізу (впровадження +
п/п захисту інформації виробник поведінки супровід)
1 Exabeam Advanced
Analytics США + Висока
2 ArcSight User Behavior
Analytics Англія + Висока
3 Forcepoint UEBA США + Висока
4 Splunk User Behaviour
Analysis США + Висока
5 Securonix UEBA США + Висока
67
У таблиці 3.1 подано узагальнені відомості про ЗАКП системи. Як видно з
таблиці 3.1., функціоналом аналізу поведінки користувачів мають переважно
іноземні рішення. Однак у разі їх застосування, сертифікація їх на відповідність
вимогам, що висуваються за рівнем контролю відсутності недекларованих
можливостей, за рівнями довіри, а також за відповідністю реальних та
декларованих у документації функціональних можливостей неможливо.
Єдиним рішенням, яке має необхідний функціонал і може бути
сертифіковано є Securonix UEBA. Однак ця система має суттєвий недолік – для
забезпечення механізму аналізу поведінки користувачів необхідна купівля та
встановлення DLP-системи в цілому, що в свою чергу значно збільшує
складність і вартість як застосування, так і супроводу ЗАКП.

3.4. Проектування потоку операцій в блокчейн-системі
Одним із напрямків машинного навчання є теорія нейронні мережі. При
роботі з нейронними мережами, розглядаючи різні мережеві конфігурації та
алгоритми, дослідники застосовують терміни, запозичені із принципів
організації мозкової діяльності. Через обмеженість знань про роботу мозку,
розробникам мереж доводиться виходити за межі сучасних знань у пошуках
структур, здатних виконувати корисні функції. Елементарною структурною
одиницею нейронної мережі є штучний нейрон [19], схематично представлений
на рис. 3.4.
У загальному випадку, основними елементами штучного нейрона є: вхідні
сигнали x (відповідні сигналам, що приходять у синапси нейрона), коефіцієнти
ω (на які множаться вхідні сигнали, відповідають «силі» синаптичних зв'язків),
сумирний блок ∑ (приймає і сумує сигнали – відповідає тілу нейрона), вихідний
сигнал NET (створюється підсумовуючим блоком, є сумою алгебри зважених
входів), активаційна функція Fa (перетворюючий вихідний сигнал) і,
безпосередньо, вихідний нейронний сигнал OUT. Один нейрон здатний
виконувати найпростіші процедури розпізнавання, для серйозних обчислень
необхідно з'єднувати нейрони в мережі.
68

Рис. 3.4. Загальна схема нейрона

Універсальність, яка спочатку була закладена в нейронні мережі, зумовлює
активний розвиток цього напряму як загалом [2, 9], так і в галузі забезпечення
інформаційної безпеки – при захисті від мережевих ТН та вторгнень [7],
антивірусному захисті [13], фільтрації спаму [14, 15], аналіз безпеки [16–18],
аналіз загроз, автентифікація за біометричними ознаками [11], розробка
адаптивних засобів захисту [12–14], виявлення аномалій [15 ] та ін [16, 17].
В даний час існує велика кількість різних змін нейронних мереж з різними
принципами функціонування [17]. Однак практично всі вони пов'язані з вибором
та аналізом деяких приватних видів структур із відомими властивостями (мережі
Хопфілда, Гроссберга, Кохонена) [18]. Як зазначається в роботі [8], найбільш
популярними та вивченими є наступні: багатошаровий персептрон, мережі
Кохонена, нейронні мережі зустрічного поширення, мережі Хопфілда та
Хеммінга, мережа з радіальними базисними елементами (RBF), ймовірнісна
нейронна мережа (PNN), узагальнено-регресійна нейронна мережа (GRNN) та
лінійні нейронні мережі. Використання існуючих нейронних мереж відкриває
широкі можливості в галузі забезпечення інформаційної безпеки, але разом з тим
воно пов'язане і з проблемними завданнями [19, 20].
До переваг нейронних мереж належать [17]:
− наявність здатності відображення вхідної інформації у вихідну, що
набувається в процесі навчання, без використання будь-яких
69
відомостей про статистичну модель даних (імовірнісну модель
розподілу);
− наявність можливості розширення функціональних можливостей за
рахунок застосування нелінійних штучних нейронів;
− наявність здатності до адаптації під впливом зовнішніх умов шляхом
перенавчання;
− наявність можливості побудови мережі, що змінюють свої
характеристики з плином часу та здатні працювати в нестаціонарному
середовищі, в якому статистика змінюється з плином часу;
− наявність можливості прискорення вирішення деяких завдань та
забезпечення масштабованості мережі за рахунок паралельної
структури нейронних мереж;
− наявність можливості застосування одного проектного рішення в
кількох предметних галузях за рахунок універсальності механізму;
− наявність здатності враховувати спостережувані чи інтуїтивно
передбачувані поправки, що потребують величезних обчислень та
розрахунків.
До недоліків нейронних мереж належать:
− відсутність суворої теорії щодо вибору структури;
− кількість ступенів свободи, що виникають у процесі навчання, може
перевищувати кількість прикладів, які використовуються для навчання,
і, таким чином, мережу можна навчити навіть на випадково
згенерованому масиві чисел;
− логічна інтерпретація описаних закономірностей практично неможлива
(за винятком найпростіших випадків), оскільки навчені нейронні
мережі є нетрактованими моделями («чорними ящиками»);
− при великій кількості нечислових змінних з великою кількістю
можливих значень використання мережі стає вкрай скрутним, оскільки
70
при роботі з нечисловими змінними виникає необхідність їх числового
кодування [22].
− використання мережі дозволяє пояснити історію минулих подій, але не
дає обґрунтованого прогнозу на майбутнє [21];
Здатність мережі навчатися, адаптуватися під нові типи поведінок і
розпізнавати їх, навіть якщо раніше з ними не стикалися, надає системі захисту
інформації певну гнучкість і незалежність. Навчають мережі на певній вибірці
прикладів. Реакція нейромережі аналізується і система налаштовується таким
чином, щоб досягти задовільних результатів. Після закінчення початкового
навчання, з часом (за результатами аналізу даних у процесі роботи), мережа стає
дедалі досвідченішою. Важливою перевагою мережі при виявленні аномалій є
їхня здатність «вивчати» адекватні дії користувачів та виявляти аномалії, не
властиві користувачеві чи групі користувачів.
Виділяють алгоритми навчання з учителем та без вчителя. Навчання з
учителем передбачає подачу на вхід набору навчальних даних, оцінка чи
класифікація яких наперед відома навчальному експерту. У процесі навчання
мережа вибудовує взаємозв'язок між елементами навчальних даних та їх
оцінкою. Результати навчання випробовуються за допомогою тестової вибірки.
Така технологія навчання має певні переваги і недоліки, що позначається на класі
завдань для даного методу завдань [37].
До переваг навчання з учителем належать:
− висока стійкість до шумів та перешкод – випадкові дані та помилки
легко фільтруються та відсіваються ще на етапі аналізу предметної
області;
− ефективна класифікація об'єктів.
До недоліків навчання з учителем належать:
− для забезпечення високої якості роботи системи потрібні великі обсяги
навчальної вибірки;
− при роботі навченої системи можуть виникати помилки при оцінці
даних, схожі з якими не були представлені у навчальній вибірці;
71
− потрібна точна оцінка прецедентів із навчальної вибірки.
Навчання без вчителя (спонтанне навчання) – це метод навчання,
ключовою особливістю якого є необхідність оцінки даних навчальної вибірки.
Будучи більш біологічно правдоподібною, навчена без вчителя дозволяє
ефективно виявляти внутрішні взаємозв'язки без корекції ззовні (за допомогою
зворотного зв'язку). Такі мережі використовують для візуалізації складних даних
[17].

Рис. 3.5. Функціональність мережі Hyperledger Fabric

До переваг навчання без вчителя належать:
− висока якість роботи системи досягається при малих розмірах
навчальної вибірки або її повній відсутності;
− навчена мережа проводить ефективну кластеризацію об'єктів і
знаходить неочевидні та складні взаємозв'язки між об'єктами;
− навчена мережа забезпечує візуалізацію даних для подальшого аналізу
експертами;
72
− значне зниження розрядності даних.
До недоліків навчання без вчителя належить низка складнощів, що
виникають при класифікації об'єктів, викликаних відсутністю зворотного зв'язку
та виправлення оцінок системи [17].
У мережі Hyperledger Fabric транзакції починаються з клієнтських
додатків, керуючих пропозиціями з угод, і навіть, іншими словами, пропонують
угоду схвалення іншими вузлами.
Члени мережі повинні мати «розумні» контракти, що імітують пропозиції
щодо угод. Стратегія схвалення транзакції залежить від політики схвалення, яка
фактично вказується після того, як чейн-код справді розгорнуть. Хорошим
прикладом політики схвалення є те, що «основна маса колег, які беруть участь у
угоді, має схвалити її». Оскільки політика схвалення насправді вказана для
певного чейн-коду, різні вузли можуть мати різну політику схвалення [29].
Після цього програмне забезпечення надсилає у службу підтвердження
узгоджену угоду, а також RW набори. Додавання транзакції відбувається по всій
мережі, паралельно із забезпеченими чейн-кодами.
Сервіс заявок приймає схвалені транзакції та набори RW, додає цю
інформацію до блоку та доставляє блок усім учасникам мережі блокчейн.

Рис. 3.6. Endorsing peer надсилає блок послідовних транзакцій усім вузлам
73
Сервіс заявок, що складається із групи замовників, не обробляє транзакції,
не виконує смарт-контракти та не бере участі у формуванні блоків. Сервіс заявок
приймає схвалені транзакції та вказує порядок, у якому ці транзакції буде
передано до розподіленого реєстру. Архітектура Fabric v1.0 розроблена таким
чином, що конкретна реалізація «упорядкування» (Solo, Kafka, BFT) стає
компонентом, що підключається. Сервісом замовлень для Hyperledger Fabric є
Kafka. Таким чином, сервіс заявок є модульним компонентом Hyperledger Fabric.
У блокчейн-мережі транзакції мають записуватися до розподіленого
реєстру у погодженому порядку. Порядок транзакцій повинен бути
встановлений, щоб гарантувати, що оновлення стану блокчейна є дійсними, коли
вони зафіксовані в мережі.
На відміну від блокчейну, де впорядкування відбувається шляхом
вирішення криптографічного завдання або майнінгу, Hyperledger Fabric дозволяє
організаціям, що управляють мережею, вибрати механізм упорядкування, який
найкраще підходить для цієї мережі. Ця модульність та гнучкість робить
Hyperledger Fabric неймовірно вигідною для корпоративних додатків.
Архітектура Hyperledger надає три механізми впорядкування: SOLO, Kafka та
спрощена Візантійська стійкість до відмов (SBFT), які ще не були реалізовані у
версії v1.0.
SOLO це утиліта для створення черг, яка зазвичай використовується
розробниками, що експериментують з мережею Hyperledger Fabric. SOLO
складається з одного послідовного вузла.
Kafka – механізм упорядкування блоків Hyperledger, який рекомендується
для використання виробництві. Командний рядок використовує Apache Kafka –
платформу обробки потоків з відкритим вихідним кодом, що забезпечує
уніфіковану високочастотну платформу для обробки потоку даних в реальному
часі. І тут дані містять підтверджені набори транзакцій. Кафка пропонує стійкість
до відмови для класифікації систем [29].
SBFT – це алгоритм спрощеної задачі Візантійської стійкості до відмови.
Цей послідовний механізм є колізійно-толерантним, тому угода може бути
74
досягнута за наявності шкідливого або дефектного вузла. Спільнота Hyperledger
Structure ще не запровадила цю систему, але вона планує її використовувати.
Важливо, що стан мережі підтримується партнерами, а не службою
замовлення чи клієнтом. Зазвичай проектується система так, щоб різні машини
мережі грали різні ролі.
Таким чином, машини, які є частиною сервісу заявок, не повинні бути
налаштовані також для підтримки чи підтвердження транзакцій та навпаки. Тим
не менш, існує збіг між схваленням та фіксацією бенкетів у системі.
Підтверджуючі однорангові вузли повинні мати доступ і мати смарт-контракти,
на додаток до виконання ролі однорангового вузла.
Однорангові вузли, що підтверджують, перевіряють підпис клієнта і
виконують функцію чейн-коду для імітації транзакції. Відповідь на пропозицію
відправляється назад клієнту разом із підписом підтвердження. Ці відповіді на
пропозиції надсилаються замовнику для подальших дій. Потім замовник
упорядковує транзакції в блок, який він спрямовує endorsing і committing
бенкетів. Набори RW використовуються для перевірки того, що транзакції, як і
раніше, здатні до оновлення вмісту розподіленого реєстру. Нарешті, однорангові
вузли асинхронно повідомляють клієнтський додаток про успіх чи невдачу
транзакції.

Рис. 3.7. Поділ спільної мережі за допомогою каналів

75
Піри можуть належати кільком мережам або каналам. Піри, які беруть
участь у кількох каналах, моделюють та передають транзакції до різних реєстрів.
Сервіс заявок однаковий для будь-якої мережі чи каналу.
Розрахунок параметрів відмовостійкості мережі на основі технології
блокчейн, що складається із 2 вузлів.
Готовність відображає здатність системи безперервно виконувати свої
функції. Фактор доступності – це ймовірність того, що система працюватиме в
будь-який час. MTTR (Mean Time to Repair) – це середній час відновлення [30].
MTBF (Mean Time Between Failure) – це технічний параметр, що
характеризує надійність відновленого пристрою або технічної системи.
Вимірюється статистично, шляхом тестування різних приладів.
Імовірність відмови компонента під час MTBF дорівнює 1, і якщо MTBF
вимірюється у роках, то ймовірність відмови компонента протягом одного року
дорівнює:

Імовірність виходу з ладу всього вузла протягом року розраховується як
сума ймовірностей виходу з ладу окремих вузлів:

Збій дубльованого компонента призведе до збою мережі лише за умови,
що резервний компонент також вийде з ладу протягом часу, необхідного для
«гарячої» заміни компонента, що вийшов з ладу першим. Якщо гарантований час
заміни компонента становить 24 години (1/365 року), то ймовірність такої події
протягом року:

Імовірність одночасного наступу цих подій дорівнює добутку їх
ймовірностей. Для випадку, коли спочатку відмовляє компонент №2, а потім
76
компонент №1, ймовірність буде однаковою. Тепер, знаючи ймовірність Pi
відмови кожного з N компонентів (дубльованих та не дубльованих) сервера,
можна розрахувати ймовірність відмови сервера протягом одного року.

Висновки
Запропоновано актуальну методику аналізу санкціонованої поведінки
користувачів інформаційної системи, засновану на застосуванні технології
машинного навчання (теорія штучних нейронних мереж).
Формалізовано поведінку користувача та доведено можливість виявлення
аномалій у поведінці користувача за допомогою нейронних мереж:
1 Підготовлено вибірку характеристик санкціонованих дій користувачів.
Ця вибірка використовувалася на навчання тришарового персептрона.
Навчання проводилося у програмному забезпеченні Google Collaborate
Pro, призначеному для роботи зі штучними нейронними мережами.
2 Після навчання нейронної мережі проведено перевірку ефективності її
роботи з допомогою тестової вибірки. Зміщення навченої нейронної
мережі склало 4% на тестовій вибірці, а розкид між зміщеннями
валідаційної та тестової вибірок – 1%, що є досить добрим результатом.
Застосування запропонованої методики дозволить:
− забезпечити виконання вимог щодо аналізу зареєстрованих подій
безпеки та реагування на них;
− при захисті від загроз, поданих у банку даних загроз, пов'язаних із
заміною довіреного користувача та його дій шляхом обману.
З урахуванням перспектив розвитку інформаційних систем на базі хмарних
платформ, ЗАКП, здатні забезпечити оперативне виявлення аномалій серед
великої кількості користувачів, набувають особливої актуальності.
Запропонована методика відрізняється від відомих унікальним складом
формалізованих характеристик поведінки користувача (складом вхідних
характеристик нейронної мережі) та параметрами нейронної мережі.
77
Використання запропонованого методу забезпечить появу наступних
функцій та властивостей забезпечення безпеки (конфіденційності, доступності,
цілісності, достовірності) інформації:
− аналіз санкціонованої поведінки користувачів;
− виявлення аномалій у санкціонованій поведінці користувачів.
Таким чином, поставлене в роботі завдання (розробка методики аналізу
санкціонованої поведінки користувачів інформаційної системи) вирішено та при
обробці даних у блокчейн-системі здійснюватиметься виявлення аномалій у
поведінці користувачів (операторів) інформаційної системи. При цьому
очікувані витрати, впровадження та супроводження запропонованого рішення
будуть нижчими, ніж на впровадження та супровід аналогічного за своїми
функціональними можливостями рішення.

78
ВИСНОВКИ

У кваліфікаційній роботі розв’язано важливе наукове завдання
розроблення методів та засобів організації та інтеграції інформаційних ресурсів
Великих даних для автоматизованого процесу управління даними. У результаті
виконання даної роботи одержано такі результати:
Проаналізовано методи, моделі та засоби опрацювання різнотипних даних,
інформаційних технологій роботи з Великими даними. Обґрунтовано
актуальність розв’язання завдання організації та інтеграції інформаційних
ресурсів Великих даних у розподілених системах даних.
Удосконалено метод перетворення реляційних та слабоструктурованих
даних у дані, подані в моделі «сутність-характеристика», що дало змогу
уніфікувати форму запитів до різних моделей даних.
Удосконалено метод інтеграції даних через визначення пари «сутність-
характеристика» та узгодження семантики, що на відміну від методів інтеграції
даних на рівні сховища даних дозволило інтегрувати дані з джерел з наперед
невідомою структурою без попереднього локального завантаження, і що, в свою
чергу, дало змогу підвищити ефективність подальшого аналізу Великих даних.
Даний метод став основою для оптимізації формування відповіді на запит
користувача.
Удосконалено метод формування відповіді на запит користувача до
Великих даних шляхом уніфікації елементів мов запитів до різних
інформаційних джерел, що дало змогу трансформувати запит до Великих даних
у запит на основі ключових слів. Розроблено компоненти інформаційної системи
підтримки прийняття рішень для автоматизованого управління інформацією з
використанням Великих даних. Розроблено метод забезпечення достовірності
даних, що обробляються в блокчейн-системі. У рамках розробки методу
розширено клас методів забезпечення достовірності даних щодо виявлення
недостовірних персональних даних з введенням в блокчейн-систему штучної
79
нейронної мережі. Запропонований метод відрізняється від відомих
концептуально новим підходом до досягнення консенсусу, що включає
процедуру автоматизованої оцінки ризиків внесення та обробки недостовірних
даних, розроблену з використанням теорії штучних нейронів мереж та теорії
нечітких множин. Метод дозволяє забезпечити достовірність даних при їх
обробці в блокчейн-системі: заснованих на хмарних платформах, як на рівні
організацій різних форм власності, і на рівні держави загалом.

80
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ

1. Alechina N. Decentralised Norm Monitoring in Open Multi-Agent Systems /
N. Alechina et al. // Proceedings of the 2019 International Conference on
Autonomous Agents & Multiagent Systems. – International Foundation for
Autonomous Agents and Multiagent Systems, 2019. – P. 1399-1400.
2. Alharbi F. Understanding the determinants of Cloud Computing adoption in
Saudi healthcare organisations / F. Alharbi, A. Atkins, C. Stanier // Complex &
Intelligent Systems. – 2019. – Т. 2. – №. 3. – P. 155-171.
3. Axak N. Cloud-fog-dew Architecture for Personalized Service-oriented Systems
/ N. Axak, D. Rosinskiy, O. Barkovska, I. Novoseltsev // The 9th IEEE
International Conference on Dependable Systems, Services and Technologies,
DESSERT’2018, Kyiv, Ukraine – 2022. – P. 80-84.
4. Barron A. R. Universal approximation bounds for superpositions of a sigmoidal
function / A. R. Barron // IEEE Transactions on Information Theory. – 2023. –
Vol. 39. – P. 930-945.
5. Bartolini C. A software framework for automated negotiation / C. Bartolini,
C. Preist, N. R. Jennings // International Workshop on Software Engineering for
Large-Scale Multi-Agent Systems. – Springer Berlin Heidelberg, 2022. – P. 213-
235.
6. Bellifemine F. Developing Multi Agent System with JADE / F. Bellifemine,
G. Caire, D. Greenwood. – England, John Wiley & Sons, 2023. – Т. 7 – 286p.
7. Blockchain Basics: A Non-Technical Introduction in 25 Steps / Daniel Drescher,
2019. – Р. 29-30.
8. Blockchain By Example: A developer's guide to creating decentralized
applications using Bitcoin, Ethereum, and Hyperledger / Bellaj Badr, Richard
Horrocks, Xun (Brian) Wu, 2023. – Р. 241-255.
9. Blockchain For Dummies (For Dummies (Computer/Tech)) / Tiana Laurence,
2022. – Р. 95-99.
81
10. Blockchain: A Practical Guide to Developing Business, Law, and Technology
Solutions / Rene Madsen, 2020. – Р. 26-52.
11. Blockchain: The Insights You Need from Harvard Business Review / Don
Tapscott, Marco Iansiti, Karim R. Lakhani, Catherine Tucker, 2021. – Р. 122-
123.
12. Build Your Own Blockchain: A Practical Guide to Distributed Ledger
Technology / Arnd Huchzermeier, 2022. – Р. 398-407.
13. Camenisch J. Concepts and languages for privacy-preserving attribute-based
authentication / J. Camenisch, M. Dubovitskaya, R. Enderlein, A. Lehmann,
G. Neven, C. Paquin, F. Preiss // IFIP Working Conference on Policies and
Research in Identity Management. – Vol. 19. – 2020. – P. 25-44.
14. Camenisch J. On the Portability of Generalized Schnorr Proofs / J. Camenisch,
A. Kiayias, M. Yung // EUROCRYPT 2019 (LNCS). – Vol. 5479. – 2019. –
P. 425- 442.
15. Camenisch J. Practical UC-Secure Delegatable Credentials with Attributes and
Their Application to Blockchain / J. Camenisch, M. Drijvers, M. Dubovitskaya
// ACM Conference on Computer and Communications Security. – 2021. –
P. 683-699.
16. CElectronic Signatures for B2B Contracts: Evidence from Australia / Aashish
Srivastava, 2019. – Р. 256-257.
17. Chase M. Malleable Proof Systems and Applications / M. Chase, M. Kohlweiss,
A. Lysyanskaya, S. Meiklejohn // EUROCRYPT 2022 (LNCS). – Vol. 7237. –
2022. – P. 281-300.
18. Chen W. A survey of traffic data visualization //IEEE Transactions on Intelligent
Transportation Systems. – 2020. – Т. 16. – №. 6. – Р. 2970–2984.
19. Chine W. A novel fault diagnosis technique for photovoltaic systems based on
artificial neural networks / W. Chine et al. // Renewable Energy. – 2019. – Т. 90.
– Р. 501-512.
20. Cryptoassets: The Innovative Investor's Guide to Bitcoin and Beyond / Chris
Burniske, Jack Tatar, 2023. – Р. 43-48.
82
21. Dumas M. A formal approach to negotiating agents development / M. Dumas,
G. Governatori, A. H. M. ter Hofstede, P. Oaks // Electronic commerce research
and applications. – 2020. – Т. 1. – №. 2. – P. 193-207.
22. Electronic Signatures: Authentication Technology from a Legal Perspective /
M.H.M. Schellekens, 2020. – Р. 212-215.
23. Ferber J. Influences and reactions: a model of situated mul-tiagent systems /
J. Ferber, J. P. Muller // Proceedings of the MultiAgent Systems (ISMAC-20). –
Menlo Park: IEEE Computer So-ciety Press, 2020. – P.72-79.
24. Hastie T. The elements of statistical learning: data mining, inference, and
prediction. / T. Hastie, R. Tibshirani, J. Friedman // Springer Series in Statistics.
– 2020.– Р. XXII–745 р.
25. Haveliwala T. Efficient computation of pageRank / T. Haveliwala // Technical
Report. – Stanford University, 2020. – 15р.
26. Jemmaa A. B., Ltifi H., Ayed M. B. Multi-agent architecture for visual
intelligent remote healthcare monitoring system //International Conference on
Hybrid Intelligent Systems. – Springer, Cham, 2022. – Р. 211–221.
27. Lagoudakis M. Auction-Based Multi-Robot Routing [Text] / M. Lagoudakis,
P. Keskinocak, C. Tovey, J. Sonal // Conference Paper. – 2019. – P. 7-18.
28. Lanctot M. A unified game-theoretic approach to multiagent reinforcement
learning / M. Lanctot et al. // Advances in Neural Information Processing
Systems. – 2023. – Р. 4190-4203.
29. Lou W. SPREAD: Improving Network Security by Multipath Routing in Mobile
Ad Hoc Networks / W. Lou, W. Liu, Y. Zhang, Y. Fang // Wireless Networks. –
2022. – Vol. 15, Issue 3. – P. 279-294.
30. Mastering Bitcoin: Programming the Open Blockchain / Andreas M.
Antonopoulos, 2023. – Р. 334-340.
31. Mastering Blockchain: Deeper insights into decentralization, cryptography,
Bitcoin, and popular Blockchain frameworks / Imran Bashir, 2022. – Р. 52-60.
32. Maxwell T. Nonlinear Dynamics of Artificial Neural Systems // AIP Conference
Proceedings. 2020. – Vol. 151. – Р. 299-304.
83
33. Montague E. Dynamic modeling of patient and physician eye gaze to understand
the effects of electronic health records on doctor–patient communication and
attention / E. Montague, O. Asan // International journal of medical informatics.
– 2019. – Т. 83. – №. 3. – P. 225-234.
34. Niazi M. A. Verification and Validation of Agent Based Simulations using the
VOMAS (Virtual Overlay Multi-agent System) Approach / M. A. K. Niazi, A.
Hussain, M. Kolberg // MAS & S at Multi-Agent Logics (MALLOW). – CEUR-
WS, 2019. – Т. 494. – P. 340-346.
35. Proof of Work and Proof of Stake consensus protocols: a blockchain application
for local complementary currencies / Sothearath SEANG, Dominique TORRE,
2022. – Р. 111.
36. Radchenko G. I. Model of problem-oriented cloud computing environment
//Proceedings of the Institute for System Programming of the RAS. – 2023. –
Т. 27. – №. 6. – Р. 275–284.
37. Ronald R. Yager. Fuzzy Set and Possibility Theory: Recent Developments. –
Pergamon, New York, 2021. – 408 p.
38. Shen F. An incremental network for on-line unsupervised classification and
topology learning / F. Shen, O. Hasegawa // Neural Networks 19. – 2019. –
Р. 90-106.
39. Tapscott D. Blockchain Revolution: How the Technology Behind Bitcoin is
Changing Money, Business, and the World / Don Tapscott, Alex Tapscott /
Blockchain – K.: Information Systems, 2020. – Р. 100-150.
40. Аксак Н. Г. Дослідження збільшення потужності у програмуванні на
мультиядерній кластерній системі / Н. Г. Аксак, В. Д. Волонцевич,
І. А. Осотов, Я. М. Філін // Комп’ютерні системи та мережі. Вісник
національного ун-ту «Львівська політехніка». – 2022. – №. 603. – С. 8-11.
41. Аксак Н. Г. Концепція побудови мультиагентних систем розподіленої
нейромережевої обробки великих даних / Н. Г. Аксак // Вісник ХНТУ. –
2022. – №. 3(66). – Т. 1. – С. 205-212.
84
42. Беляева К. С. Розробка засобів верифікації протоколу консенсусу в
децентралізованих системах / Беляева К.С., Пенко В.Г. // Інформатика та
інформаційні системи: тези доповідей шістнадцятої всеукраїнської
конференції науковців, 19 квітня 2020 р. – Одеса, 2020. – С.61-62.
43. Лебьодкіна А.Ю. Методи та моделі прискореної нейромережевої обробки
даних у розподіленому обчислювальному середовищі. : дис. канд. техн.
наук: 05.13.23 – системи та засоби штучного інтелекту. Харківський
національний університет радіоелектроніки. Харків. 2019. – 175 с.
44. Николайчук Я. М. Спеціалізовані комп'ютерні технології в інформатиці:
монографія / за загальною редакцією Я. М. Николайчука. – Тернопіль:
«Бескиди», 2021. – 919 с.
45. Помазун О. М. Особливості побудови групової системи підтримки
прийняття рішень з реінжинірингу бізнес-процесів / О. М. Помазун //
Вісник Запорізького національного університету. – 2019. – №. 1(4). – С. 83-
88.

ChSTU repository

ChSTU repository preserves and enables easy and open access to all types of digital content including text, images, moving images, mpegs and data sets