CC BY
16
3. Popularity of Programming Language // GitHub. - 2016. [Electronic resource]. - Mode of access http://www.pypl.github.io/PYPL.html.
4. A small place to discover languages in GitHub // GitHut. - 2015. [Electronic resource]. - Mode of access http://www.githut.info.
5. An Interview with the Creator of Ruby // O'Reilly Media. - 2001. [Electronic resource]. - Mode of access http://www.linuxdevcenter.com/pub/a/linux/2001/11/29/ruby.html.
6. Сейбел П. Кодеры за работой. Размышления о ремесле программиста / Питер Сейбел. -СПб. : Изд-во "Символ-Плюс", 2011. - 544 с.
7. TIOBE Index // TIOBE. - 2016. [Electronic resource]. - Mode of access http://www.ti-obe.com/tiobe_index.
8. Креншоу Д. Давайте создадим компилятор! / Джек Креншоу. - М. : Изд-во "Наш мир", 2001. - 465 с.
Надтшла до редакцп 16.05.2016р.
Пасека Н.С., ТурчинО.Б. Теоретическое обоснование показателей жизненного цикла технологий
Проанализированы основные показатели жизненного цикла технологий и выделена обобщенная система для оценки этапа жизненного цикла. Показатели рассмотрены как свойства, которыми должна обладать та или иная технология, чтобы соответствовать определенному этапу своего существования. Исследованы существующие подходы анализа развития технологии. Предложена обобщенная классификация, что представляет собой перечень показателей для соответствующего этапа развития. Обобщенная система оценки технологий позволит минимизировать технологические риски, связанные с кратко- и долгосрочными перспективами разработки программного обеспечения.
Ключевые слова: жизненный цикл, технология, параметры, этап развития, обобщенная классификация, технологические риски, язык программирования.
Paseka M.S., Turchyn O.B. Theoretical Explanation of Technologies Life Cycle Indicators
The basic indicators of the life cycle of technology were analyzed and the generalized system for the evaluation of the life cycle phase is allocated. Indicators are considered as properties that technology must have to fit a certain stage of its existence. The existing approaches of technology development analysis are studied. The generalized classification, which is a list of indexes for the proper stage of development, is proposed. The generalized technologies estimation system will enable to minimize technological risks related to the short-term and long-term software development prospects.
Keywords: life cycle, technology, stage of development, generic classification, technological risks, programming language.
УДК 004.9:530.1
МЕТОДИ ТА ЗАСОБИ ОПРАЦЮВАННЯ ВЕЛИКИХ ДАНИХ У СИСТЕМАХ ТЕРИТОР1АЛБНОГО УПРАВЛ1ННЯ
Ю.Я. Болюбаш1
Подано визначення Великих даних та описано основш характеристики. Проаналь зовано математичш засоби подання та опрацювання Великих даних та визначено 1х об-меження. Визначено формальний опис Великих даних. Подано моделi асощацш мiж сутностями та характеристиками для рiзних категорш Nosql баз даних. Розроблено метод обмшу рiзнотипними даними та приведения реляцшних даних до моделi "сутшсть-характеристика". Спроектовано схему даних регюну. Апробовано розроблеш методи та алгоритми.
1 Здобувач Ю.Я. Болюбаш - НУ " Львгвська полггехнка"
Ключов1 слова: Велик данi, iнформацiйна модель, гетерогенш данi.
Вступ. Регiон - складна, багатокомпонентна, вщкрита, динамiчна, ймо-вiрнiсна система, оскiльки:
• до складу регюну входять рiзнi за природою об'екти, такi як економiчнi показ-ники, соцiальнi фактори, технiчнi об'екти, яю, водночас також е системою;
• стан системи змшюеться тд дiею зовнiшнiх факторiв;
• перехщ з одного стану в шший вiдбуваеться не миттево, а з часом;
• причинно-наслiдковi зв'язки е ймовiрнiсного характеру. Характеристики регiону (рис. 1):
• великий набiр сутностей: особи, оргашзацп, природнi ресурси, рекреацшний фонд, законодавчi акти та звгги;
• база даних особливостей: документи для штелектуального аналiзу даних, словники даних для зв'язування об'екив.
±
Репон
Територ1альш характеристики
— площа кордони
— адммжстративно-територ1альш одиницИ
Т W
Населения Природа
1
Економ1ка
Культура
— структура зайнятють
— динамка
— кл1матичш умови
— ресурсний потенщал
— флора
— фауна
—тдприемства рекреац1я транспорт —зв'язок
. J
L
— ¡сторичж • об'екти
" ДуХОВНЮТЬ
J
обсяги ¡нформацп у петабайти
он-лайн анал1з даних
I
необх1днють обробки структурованоУ та неструктурованоУ ¡нформацп Рис. 1. Структура регюну
Процес побудови узагаленено1 (комплексно'1) моделi регюну усклад-нюеться рiзноманiтнiстю моделей даних, а також через наявшсть pi3Hnx piBHiB агрегацп даних. Однieю з популярних технологш для розроблення систем тери-тоpiального упpавлiння е Великi данi.
Аналiз лiтературних джерел та постановка задачь Великi данi (Big Data) в шформацшних технологiях, за визначенням К. Лшч, Д. Леней, - набip методiв та засобiв опрацювання структурованих i неструктурованих piзнотипо-вих динамiчних даних великих обсягiв з метою 1х аналiзу та використання для тдтримки прийняття piшень [1]. С альтернативою традицшним системам уп-равлшня базами даних i piшенням класу Business Intelligence. До цього класу вщносять засоби паралельного опрацювання даних (NoSQL, алгоритми MapRe-duce, Hadoop) [2].
Визначальними характеристиками для Великих даних е [2]: обсяг (volume, у сенш величини фiзичного обсягу), швидкiсть (velocity у сенсах як швид-костi приросту, так i необхiдностi високошвидкiсного оброблення та отримання
результатов), р1зномашття (variety, у сенс1 можливост одночасного оброблення р1зних тишв структурованих i слабоструктурованих даних).
Велик данi е термiном, який використовують для щентифгкади наборiв даних, з якими не можна впоратися з використанням кнуючих методологи та програмних засобiв через !х великий розмiр i складшсть. Такi дослiдники М. Гiлбернт [3], С. СтрШваса та iн. розробили методики i програмнi засоби для передачi даних або видобування шформацшних гранул з Великих Даних (ко-лекцп об'ектiв, якi зазвичай формуються для атрибутiв з числовими i яю розта-шованi поряд через 1х схожiсть, функцiональну або фiзичну сумiжнiсть). Мето-ди машинного навчання та вiзуалiзацii даних дають змогу опрацювати та гра-фiчно подати результати ан^зу даних великих обсяпв (мiльойони кортежiв). Проте нерозв'язаною задачею залишаеться задача побудови вiдображення мiж моделями даних рiзних джерел.
У роботах Alejandro Maté [4] та Lucentia Research Group обгрунтовано використання багатовимiрноi моделi для подання Великих даних та побудови воображения в релящйну модель. Багатовимiрне подання даних добре вико-ристовувати для задач вiзуалiзацil даних та iх аналiзу, але у зв'язку з розрщже-нiстю гiперкуба обсяг даних у такому випадку е бшьший порiвняно з реля-цiйним поданням, що е неприпустимим до Великих даних.
Vinayak Borkar, Yingyi Bu [5] пропонують використовувати об'ектно-орiентований шдхвд, проте обмеженням е кiлькiсть зв'язюв мiж об'ектами. Тому об'ектне подання даних за певно! модифiкацii може бути використане для Великих даних. Проте залишаеться нерозв'язаною задача трансформацн з одних тишв подання даних в об'ектну модель даних (табл. 1).
Табл. 1. Пор 1в ня н ня моделей подання Великих даних
Назва моделi Автори Переваги Недолiки
Багатовимiрна модель М. Слокун Доцшьно використовувати для задач вiзуалi-зацй' даних та ix аналь зУ У зв'язку з розрщжешстю гшер-куба з неоднорщними даними, ix обсяг збiльшуеться, що е неприпустимим до Великих даних
Об'ектна модель I. Добешi За певно! модифiкацii може бути використана для Великих даних Нерозв'язаною е задача тран-сформацп з одних титв подання даних в об'ектну модель даних
Графова модель Чен [6], Паркер, Демченко Доцшьна для анатзу зв'язкiв мiж об'ектами Значна обчислювальна склад-тсть алгорштшв пошуку за умо-ви велико! кiлькостi об'екпв
Отже, единого шдходу до опрацювання Великих даних не знайдено. Тому задача розроблення методiв та засобш опрацювання Великих даних у системах репонального розвитку е актуальною.
Основний матерiал. Отже, iнформацiйна модель Великих даних - це
BigD = (e, f, а),
де сутностi e е E, характеристики f е F, асоцiацii а ^ ие,f мiж сутностями e та характеристиками f .
Загальна кшьккть сутностей визначаеться як |e|, загальна кiлькiсть характеристик е потужнiстю множини f: |f| . Також опишемо:
• для кожно1 характеристики f множину e(f) = {e е E : ne f > 0} ycix асоцшова-них з f сутностей;
• для кожно'1 сутноси e множину f (e) = { f е F : ne, f > 0} ycix асоцшованих з e характеристик.
Опишемо щ якiснi подання у кiлькiсному виглядi [8, 9]. Для цього ско-ристаемося аналогом опису мiри TF-IDF у текстових документах [10].
У подiбних ситуациях, коли е кшька сутностей, пов'язаних з характеристикою, використаемо кшьккне подання iнформацii, тобто кшьккть бшарних за-питань (так, ш), якi потрiбно задати, щоб знайти потрiбний об'ект. Загалом, як-що знаемо, що невiдомий об'ект належить множит, що складаеться з N еле-ментш, то можемо роздшити цей набiр на двi половини i, задаючи двiйковi питания, з'ясувати, до яко! половини належить шуканий об'ект. Отже, тодi кшь-кiсть об'ектiв становитиме n/2. Продовжимо далi таку ж процедуру: задамо друге питання, для чого подшимо видiлену половину ще на двi половини. Отже, шсля двох запитань матимемо n/4 об'ектш, серед яких е шуканий. Шсля трьох запитань матимемо n/8. Загалом, шсля вщповвд на q бшарних запитань матимемо множину з N ■ 2-q елементiв, що мктить потрiбний об'ект [11].
Коли множина складатиметься з одного елемента, точно визначимо пот-рiбну нам альтернативу. Кшьккть бшарних запитань для пошуку характеристики для N альтернатив: N ■ 2-q = 1, або q = log2 (N).
Аналопчно можна описати сутностi. Маемо El сутностей з кшькктю ш-формацц log2(|E|). Коли знаемо, що якась сутнiсть асоцшована з характеристикою (маемо |e(f)| сутностей асоцiйованих з характеристикою f), то кiлькiсть питань дорiвнюе log2(|e(f )|). Отже, той факт, що сутнкть e пов'язана з характеристикою f, дае змогу зменшити кiлькiсть питань до
Загальна важливкть характеристики f для сутност e визначаеться як
Ця формула е одним з варiантiв у термiнах частоти термiнiв - т. зв. зво-ротною частотою документа tf-idf [11]. Для кожно! сутностi e маемо кiлькiсть питань I(e, f) для рiзних характеристик f. Значення важливост потрiбно нор-малiзувати:
визначаеться як
(1 + log2(«e, f )))• log2
V(e, f) = ,
e(f )|
Z
<jef (e)
(1 + log2(«e, >))• log2
V
e(j)\
Для кожно! сутностi е е вага У(е, /). Отже, в якостi мiри близькостi мiж двома об'ектами Е1 i Е2, можемо вважати ввдстань мiж вiдповiдними векторами
(V(еь/),У(е2,/),...).
У звичайнiй Евклiдовiй вiдстанi ¿(а,Ь) = ^(а1 -Ь1)2 +... додаються квадра-ти рiзниць. Отже, для кожно! ваги V(e, /), що репрезентуе кiлькiсть вiдповiдей " так" -" нi", матимемо
¿(еь е2) = Е / ^У (е1, /)- V (е* /)|.
Ця вiдстань залежить вiд кiлькостi характеристик: наприклад, якщо на додаток до документов, зберiгаемо !х копií, вiдстань збшьшуеться вдвiчi. Щоб уникнути цiеí залежносп, вiдстань ¿(е1, е2), як правило, нормалiзуеться в штер-валi [0,1] через дшення на максимально можливе значення цiеi вiдстанi.
Поргвнюючи сутност по кожнiй з характеристик, отримаемо вiдстань мiж ними, подану як
Деь е2) = 1
Xfmax(V(ei,f),V(e2,f)) '
Далi здiйснимо подання ввдомих моделей даних у моделi даних "сут-нкть-характеристика". Носiй даних у моделi "ключ-значения" (iнша назва - ко-лонкова БД) описуеться кортежами виду
KV = {< к, v >},
де: к - ключ, який приймае ушкальш значення у кожнiй парц v - значення, що вiдповiдае цьому ключу, e ^ к; f ^ v. Сигнатура моделi виглядае як:
O = [п,о),
де: п - операция проекцц за атрибутами (ключ або значення); а - селекцп ат-рибупв (вибiр значення за ключем, ключiв за значенням, ключiв за значенням предков). Перерахованi операцii вiдносять до категорц читання [9]. Приклади реальних операцiй читання:
• get(key),
• multiGet,
■ також MultiGetlterator, Storelterator (за major key)
■ Subrange (keyFirst, keyLast)
■ Depth.CHILDREN_ONLY
• multiGetKeys
■ Subrange (keyFirst, keyLast)
■ Depth.CHILDREN_ONLY
Прикладом СУБД колонкового типу е Cassandra.
г
Нoсiй мoделi "об'ект-документ " oписyeться кopтежами виду
OD = {< fo, < f : eb f2 : e2, fn : en, fn+1 : db f2 : d2, fn+l : dl >},
де: f0 - ^m^i^TOp дoкyмента; f..fm - xаpактеpистики (атpибyти) дoкyмен-ту; e1..em - атoмаpнi значення xаpактеpистик f1..fm ; d1.dl - пoсилания на iншi дo-кументи, di = e( fi). Опеpацiï цieï мoделi e oб'eктнi.
Опеpацiя визначення вузлш елемента
v(fi) = {С} и {/Oí I i = Íñ и {e(fi) I i = 0ñ+~l}, де С - шлекщя дoкyментiв f0i. Опеpацiя визначення значень вyзлiв
v(fi) = {neJ,fi I 1 = 1, n, J = 0, m +1}, де ej - значення атpибyтiв fi. Пpикладами СУБД ^oro типу e MongoDB та Co-uchDB. Гpафoва мoдель даниx додана як:
O = ( ID, A, z, r),
де: ID - мнoжина iдентифiкатopiв, вузлш гpафа; А - мдажина пoзначениx с^я-мoваниx дуг (p, l, с), p, c e ID, l - " pядoк-мiтка", запис (p, 1, с) oзначаe, щo мiж вузлами p та с e зв'язoк l; z - функця, щo вiдoбpажаe кoжний вyзoл n e ID в шн-^етне значення складенoгo абo атoмаpнoгo типу, z : n ^ v ; V - oсoбливий кopе-невий вyзoл гpафа.
Оснoвнoю метою пеpетвopення даниж y мoдель "сyтнiсть-xаpактеpисти-ка" e забезпечення мoжливoстi oпpацювання даниx бyдь-якoï стpyктypи.
Метoд пеpетвopення даниx y мoдель "сyтнiсть-xаpактеpистика" пoлягаe y пеpеpаxyнкy важливoстi xаpактеpистики для сутшси, а такoж фiзичнoмy пе-pетвopеннi сxеми даниx y rnpy "сyтнiсть-xаpактеpистика". Сxемy пеpетвopения даниx y мoдель "сyтнiсть-xаpактеpистика" пoданo на pra. 2.
Для poзшиpения XML пpoпoнyeться викopистoвyвати аpxiтектypy MVVM ("View-Model", "Bигляд-Мoдель"). Цей шаблoн застoсoвyeться пiд час пpoектy-вання аpxiтектypи пpoгpамнoгo дoдатка й викopистoвye пoдiл мoделi в частиш лoгiки ïï фyнкцioнyвания та ïï пoдания на кopистyвацькoмy iнтеpфейсi. Осгов-нoю ïï вiдмiннiстю ввд вiдoмoï аpxiтектypи пpoгpамнoгo дoдатка MCV (ModelView-Controller, Мoдель-Bигляд-Koнтpoлеp) e вщсутшсть вимoги пpив'язyвания даниx дo ïx^oro пoдания. Biдпoвiднo дo цьoгo пiдxoдy пoкажемo пoтpiбнi poз-poбленi кoмпoненти для автoматизoванoï кoнвеpтацiï з pеляцiйнoï БД y мoдель XML з ypаxyванням oсoбливoстей мoделi "сyтнiсть-xаpактеpистика" (pис. 3).
В аpxiтектypi дoдаткiв, якi pеалiзyються за стpyктypoю, яку пoказанo на pro. 3, ^исутш кiлька кoмпoнентiв, якi пoтpебyють дoдаткoвиx пoяснень. Один з такт кoмпoнеитiв - xml-poзмiтка. Вказана poзмiтка такoж мoже бути виш-pистана для poбoти з дoкyментo-opieнтoваними базами даниx. Тoмy пеpетвo-pения з мoделi "oб'eкт-дoкyмент" y мoдель "сyтнiсть-xаpактеpистика" не виш-нyвалoсь.
Наведемo пpиклад XML oписy вимipiв системи тypистичнoгo кoмплексy. <measurement> <name> Станця </name> <location> Красне </ location>
<time> 2014-04-14 09:41</ time> <brake>
<fuzzy name="brakel">
<function minvalue="0"> 0 </ function>
Cfunction minvalue ="1" maxvalue="5"> x/(maxvalue-Minvalue) + maxvalue/(maxvalue-minvalue) </ function> </ fuzzy>
<fuzzy name="brake2"> <function minvalue="6"> 6 </ function>
<function minvalue="7" maxvalue="9">x/(maxvalue-minvalue) - minvalue/(maxvalue-minvalue)</function> </ fuzzy> </ brake> </measurement>
Для зручност универсального опису елементав можна застосовувати Xsd опис, вид якого подано нижче. Функця приналежностi в цьому прикладi обме-жена значениями Minvalue i Maxvalue.
<>: s:schema id="Fuzzyshema " elementformdefault="F qualified"
xmlns:xs="http://www.w3.org/2001/XMLSchttp">
<xs:complextypename="fuzzy">
<xs:sequence>
<xs:elementname="fuzzy'minoccurs="1"maxoccurs="un-bounded"
type="functions7>
</xs:sequence>
</xs:complextype>
<xs:complextypename="functions">
<xs:sequence>
<xs:elementref="function'minoccurs="1"maxoccurs="unbounded"/> </xs:sequence>
<xs:attributename="name'type="xs:string"/>
</xs:complextype>
<xs:elementname="function">
<xs:complextype>
<xs:simplecontent>
<xs:extensionbase="xs:string">
<xs:attributename="minvalue'type="xs:string"/>
<xs:attributename="maxvalue'type="xs:string"/>
</xs:extension>
</xs:simplecontent>
</xs:complextype>
</:ts :element>
</xs :schema>
Далi розроблено метод перетворення реляцiйних даних у модель "сут-нiсть-характеристика" transformRDB, який мiстить такi кроки.
Крок 1. Створити кореневий елемент схеми RDB для моделi даних Big Data.
Крок 2. Для кожно'1 сутност е створити окремий елемент Entity i розмiстити його шд кореневим елементом.
Крок 3. Для кожно'1 характеристики f сутностi e з важливiстю, бiльшою за порого-ве значення, створити атрибут Feature, розмiстити його усерединi вiдповiдного опису сутносй та задати його тип.
Крок 4. В атрибут потрiбно вибрати й задати тип даних та визначити граничнi значення.
с
tansformXML
Визначити параметри запиту користувача
Визначити XML-po3MÍTKy
I ~
Видобування XML, XSD DTD, XQEURY
Обробка ¡нструкцш XML, XSD, DTD, XQEURY
Перев1рка синтаксису XML-команд
Перетворення в двшку сутнють-характеристика
Перерахувати важливють асоц1ацш
Рис. 2. Схема перетворення даних у модель «сутшсть-характеристика»
^ Кшець ^
Рис. 3. Схема конеертаци XML-БД з урахуванням модель сутшсть-характеристика "
Метод перетворення з формату JSON нагадуе структуру методу перетво-рення з формату XML i тому окремо не розглядаемо. Для перетворення графо-во1 моделi в модель мсутнiсть-характеристикам важливим е визначення ваги зв'язку мiж елементами. Оскiльки першим параметром моделi е характеристика, другим - зв'язок, а третГм - сутнiсть, то перетворення мiж моделями полягатиме у числовому вираженнГ асоцiацГí мiж елементами RDF-моделi (рис. 4). Далi спроектовано архГтектуру системи опрацювання даних регГону з використанням моделГ "сутнГсть-характеристика". ДГаграма класГв описуе подання даних у мо-делГ "сутнГсть-характеристика" (рис. 5).
Рис. 4. Схема конвертацП графовое БД з урахуванням Müömi "суттсть-характеристика "
Puc. 5. fliaepaMa Kjacie
ym^iKOBaHO nepeTBopeHHA 3anHTiB p03p06neH0 giarpaMy KnaciB (puc. 6) Ta iHTep^enc B3aeMogii (puc. 7).
«Enum» Query Type
primary ■ 1, filter = 2. fusion = 3. join u a,
aggregation = s nest = 6, umnest-7, group jofn=0
ft
Expression
+ id String + value String + ordeiType String + crOjectRfifersnce: String + type BtpressionType + query Type* Query Type f arguments. U&teExpfession> + parameters Usl<Expressjon> + schema List<Exoression>
«Ernjm» Ex press ion Type
and * lt OH = 2. bn and = 3. bit or -4, brt xor = s, en neg = 6. plus ^ 7,
minus=e.
multiply = divide = 10, modular = h. power-12, equal = 13. gt-14. lt= 15, ge = 16, le - 17,
not_eoual - 18, NOT =19.
concatenation = 20, function call =21. constant = 22. attribute = 23. group ^ 24, if = 25. query = 26, order =27, parameter ■ ifl, case = 29, object = 30
Puc. 6. fliaepaMa 6jr ymfiiuoeaHoeo nepemeopeHHH 3anumie
350
36ipHHK HayKOBO-TexHiHHHx npaub
«Interface» IDataReceiver
+ updateData(Data) i
1
«Interface» IQueryExecutionProvider
+ noiify(int): int
+ updateQuery(Expression): int + startExecution(int): int
«Interface» lExternalReceiver
h get8ufferSize(int): int
«Interface»
llnternalReceiver
+ updateBufferedData(Data): int
L \
«Interface»
IScheduler
+ initComponents(Expression): int
Рис. 7.1нтерфейс для ушфжованого перетворення 3anumie
Для визначення методики аналiзу фшансових показникiв perioHy роз-роблено вщповщне програмне забезпечення. Для pеалiзацГí сховища даних була вибрано 64-розрядна платформа (х64). Узагальнене сховище даних складаеться з таких компонент:
• Реляцшна база даних (Microsoft SQL Server Database Services, Oracle Database, MySQL, PostgreSQL) у 64-розрядному виконаннi;
• Багатовимiрна база даних (Microsoft SQL Server Analysis Services або Hyperion Essbase) у 64-розрядному виконаннц
• "Iерархiчна" база даних (MongoDB);
• Система керування федеративним сховищем даних, яка е окремою програмою, розробленою спецiально для забезпечення функцiонування сховища даних, та включае в себе файлове сховище.
Для розроблення системи керування федеративним сховищем даних бу-ло використано платформу Microsoft.Net, мову C# та середовище розробки Visual Studio. Бiблioтека класiв, що поставляеться з .net та мова високого piвня C#, а також методолог1я RAD (швидко'1 розробки застосувань), на якш побудоване середовище розробки Visual Studio, дае змогу швидко створювати застосування, opiентoванi на бази даних.
Насамперед здшснюеться федеративне опрацювання даних з джерел. Аналiзyемo вщносну кiлькiсть oб'ектiв або дoкyментiв, наявних у джерелах даних, до загально'1 кiлькoстi oб'ектiв, якi потрапили у федеративне сховище. У табл. 2 наведено структуру детермшованих схем БД з деталiзацiею за областями в обсяз^ достатньому для прогнозування процешв розвитку pегioнy. У табл. 2 також вказано структуровашсть даних i розмщення у схoвищi даних (порядковий номер oбластi та тип БД).
Джерело/область/таблиця Вщстань V(e, f ) Розмщення
Джерело даних MFUVUDB 0.154224 -
MFUVUDB.t aspnet Applications 0,0 RDB
MFUVUDB.t mfuvu Settlements 1.0 RDB
MFUVUDB.t vw mfuvu list sti correspond 0.666942 RDB, XML
MFUVUDB.t vw mfuvu Users 0.401167 RDB, XML
Джерело даних TransBudgDB 0.628414 -
TransBudgDB.t VXXDDMMYY 0.961365 RDB
TransBudgDB.t D BUDG LOCAL DET 0.888913 RDB
TransBudgDB.t D ECON CRED 0.9 RDB, XML
TransBudgDB.t D FIN 0.916667 RDB, XML
TransBudgDB.t DMYYMM 0.533333 RDB, XML
TransBudgDB.t D INC DET 0.903839 RDB
TransBudgDB.t district 1,0 RDB
TransBudgDB.t VW INCOME LVL3 0.5 RDB, XML
Область даних FUPortalDB 0.325218 -
FUPortalDB.t Applications 0.666667 RDB, XML
FUPortalDB.t IsAuthCorrespond 1,0 RDB
FUPortalDB.t Articles 0.375858 RDB, XML
FUPortalDB.t People 0.227109 RDB, XML
FUPortalDB.t aspnet Applications 0.666667 RDB, XML
Проаналiзовано повноту потрапляння шформаци у федералiзоване схо-вище даних (рис. 8). 25000 -
сховище федеративне
даних сховище
(консолщац1я) даних
Рис. 8. Аналiз повноти нагромаджених описань oö'eKmie
На поданш дiаграмi проаналiзовано роботу алгоритму федеративного за-питу. Роботу алгоритму порiвняно з роботою алгоритму немодифжовано' штег-раци, застосованому в Oracle Data Integrator. Даш у федеративне сховище пот-рапляють з баз даних рiзних установ, структури даних яких наперед невiдомi. Кiлькiсть запишв вхiдних баз даних, що мають потрапити у федеративне сховище даних, - 15000.
Для анаизу повноти нагромаджених об'ектв порiвнювалися традицшне сховище (використано Integrated services), Oracle Big dara SQL та запропонова-не ршення. Визначено, що традицшна консолiдацiя працюе найкраще, що е зрозумшим, але цей пiдхiд неприйнятний для великих даних. Тому дай порiв-нювались запропоноване рiшення та Oracle Big dara SQL. Визначено, що нез-начно дом^еться за кшьюстю невизначених значень, але дом^е за кiлькiстю
вфно знайдених даних за запитом, а також дае змогу знайти noTpiÔHÎ даш за ко-ротший час (даш, що надiйшли зi запiзнення).
ДалГ пpoаналiзoванo пpавильнiсть перетворення запитiв piзних типiв. З цiею метою пopiвнювалися poзpoбленi засоби в системi Iнтегpатop з сеpедoви-щем DocumentDB, у якому е можливГсть фopмування запитГв на mobî SQL та Nosql. Результати пopiвняння подано в табл. 3 у вГдсотковому значеннi пpавиль-но поданих запитiв. Загальна кГлькГсть запитiв, що тестувались - по 50 запитГв кожно'1 категopГí. Пpавильнiсть фopмування запитiв пеpевipялася експеpтнo.
Табл. 3. Перетворення 3anumie р1зних munie
Вид запиту !нтегратор DocumentDB
select select... join insert delete select select... join insert delete
РБД (Microsoft SQL Server Database Services) 98 95 93 93 98 92 94 94
XML (XBase) 86 82 - - - - - -
NoSQL (mongoDB) 91 86 84 84 89 82 81 81
ДалГ для апpoбацгï та тестування poзpoблених методГв визначили важли-вГсть об'ектГв у p^rn джеpелах даних. ПГд важливГстю poзумгли pелевантнгсть запиту. Як Г ваpтo було очГкувати, для pеляцгйних джеpел вона вища (pис. 9).
I м j I- I I . . I
:ж1ж
mi m
пгппггпю
Реляцтне джерело XML джерело
Рис. 9. Важлив^ть сутностей
Висновки
ЗдГйснено аналГз пpoблеми подання та oпpацювання pгзнoтипoвих дже-pел даних. Обфунтовано актуальнГсть poзв'язання цш пpoблеми на основГ вве-дення Великих даних, що дало змогу видГлити нев^тет pангше задачГ з о^а-цювання та консолГдацп даних з напеpед невГдомих джеpел. Рoзpoбленo модель
Великих даних "cyTHÍCTb-характеристика", яка дае змогу оргашзовувати струк-TypoBaHi та слабострyктyрованi даш i на вiдмiнy вiд баraтовимiрноi моделi не мiстить надлишковостi.
Лггература
1. Laney, D. (2012). The Importance of'Big Data': A Definition. Gartner, 242 p.
2. Beyer, M. (2011). Gartner Says Solving 'Big Data' Challenge Involves More Than Just Managing Volumes of Data. Gartner. Archived from the original on 10 July 2011.
3. Hilbert, Martin. (2013). Big Data for Development: From Information - to Knowledge Societies, SSRN Scholarly Paper No. ID 2205145). Rochester, NY: Social Science Research Network; http://papers .ssrn.com/ abstract=2205145.
4. Maté, A., Peral, J., Ferrández, A., Gil, D., & Trujillo, J. (2016). A hybrid integrated architecture for energy consumption prediction. Future Generation Computer Systems.
5. Borkar, Vinayak, & Michael, J. (2012). Carey, and Chen Li. "Inside Big Data management: ogres, onions, or parfaits?." Proceedings of the 15th international conference on extending database technology. ACM.
6. Bu, Yingyi, et al. (2010). HaLoop: efficient iterative data processing on large clusters. Proceedings of the VLDB Endowment 3.1-2, 285-296 pp.
7. Min, Chen, Mao, Shiwen & Liu, Yunhao. (2014). Big data: a survey. Mobile Networks and Applications 19.2, 171-209 pp.
8. Shakhovska, N., & Bolubash, Yu. (2015). Big Data Model "entity and characteristics". Econ-TechMod, Vol. 4, No. 2, 51-58 pp.
9. Шаховська, Н.Б. & Болюбаш, Ю.Я. (2015). Модель Великих даних "сутшсть-характерис-тика". Bíchuk Нацюнального утверситету "ЛbBÍBCbm полтехтка". - Сер.: 1нформацтт систе-ми та мережу 814, 186-196 cc.
10. Di Ciaccio, A., Coli, M., & Angulo Ibanez, J.M. (eds.) (2012). Advanced Statistical Methods for the Analysis of Large Data. Springer, Berlin
11. Fang, L., Sarma, A.D., Yu, C., & Bohannon, P. (2011). Rex: explaining relationships between entity pairs. Proc. VLDB Endowment, 5(3), 241-252 pp.
Надтшла до редакцп 26.06.2016р.
Болюбаш Ю.Я. Методы и средства обработки Больших данных в системах территориального управления
Дано определение Больших данных и описаны их основные характеристики. Проанализированы математические средства подания и обработки Больших данных и определены их ограничения. Определено формальное описание Больших данных. Показаны модели ассоциаций между сущностями и характеристиками для различных категорий Nosql баз данных. Разработан метод обмена разнотипными данными и приведение реляционных данных к модели "сущность-характеристика". Спроектирована схема данных региона. Апробированы разработанные методы и алгоритмы.
Ключевые слова: Большие данные, информационная модель, гетерогенные данные.
Bolubash Yu. Ya. The methods and tools for Big data processing in territorial administration systems
The paper presents Big data information model and describes the main characteristics. Mathematical analysis means submission and processing of large data are given and their limitations defined. The formal description of Big Data is built. There is posted models associations between entities and properties for the different categories Nosql databases. The method of heterogeneous data sharing and bringing to relational data model "entity-characterization" is given. The data scheme of region is designed. The developed methods and algorithms are tested.
Keywords: big data, information model, heterogeneous data.
