Analytical store for streaming data with huge volume
A concept for organizing an analytical data warehouse has been developed, which includes a method of interaction between data producers and a repository, a method of data circuit control, a method of data streaming, a method of storing initial data, a method of data processing and a method of provid...
Gespeichert in:
| Datum: | 2022 |
|---|---|
| Hauptverfasser: | , , |
| Format: | Artikel |
| Sprache: | Ukrainian |
| Veröffentlicht: |
Інститут програмних систем НАН України
2022
|
| Schlagworte: | |
| Online Zugang: | https://pp.isofts.kiev.ua/index.php/ojs1/article/view/489 |
| Tags: |
Tag hinzufügen
Keine Tags, Fügen Sie den ersten Tag hinzu!
|
| Назва журналу: | Problems in programming |
Institution
Problems in programming| id |
pp_isofts_kiev_ua-article-489 |
|---|---|
| record_format |
ojs |
| resource_txt_mv |
ppisoftskievua/67/d93ad52ff91bfd0483ec39dc14fc3a67.pdf |
| spelling |
pp_isofts_kiev_ua-article-4892022-07-12T19:05:24Z Analytical store for streaming data with huge volume Аналітичне сховище для великих потокових даних Tiurin, V.O. Doroshenko, А.Yu. Savchuk, E.V. serverless; analytical datastore; BigQuery; AWS; GCP; ETL; message; data streaming UDC 004.042 безсерверні; аналітичні сховища; BigQuery; AWS; GCP; ETL; повідомлення; потокова передача даних УДК 004.042 A concept for organizing an analytical data warehouse has been developed, which includes a method of interaction between data producers and a repository, a method of data circuit control, a method of data streaming, a method of storing initial data, a method of data processing and a method of providing secure data access. Other concepts on the market are discussed, namely: SDLF as the leading standard recommended by AWS, IronSource DL using Upsolver, SimilarWeb DL using Upsolver. A comparative analysis was conducted (mostly with SDLF, as its implementation is open, and the implementation by private companies is hidden). The advantages of the proposed concept over the existing ones are examined in detail. Recommendations on how to integrate the concept with data schema control applications are given. A service for streaming data using Apache Beam in Java has been developed. A repository architecture for analytics was designed and developed. A data schema management model was developed as well as a data schema management model and a model for secure access to data. The research that has been conducted can be improved by the experience of implementing the concept in business, as well as by collecting and systematizing knowledge about other standards that will be created.Problems in programming 2022; 1: 67-74 Розроблено концепцію архітектури з організації аналітичного сховища даних на основі інфраструкту- ри Google Cloud Platform (GCP). Проведено аналіз існуючих рішень у галузі безсерверних аналітич- них сховищ. Проведено порівняльний аналіз із найбільш розповсюдженими існуючими рішеннями та здійснено експериментальне випробування розробленої концепції. Наведено рекомендації з орга- нізації сховища даних з можливістю підтримки подій із змінною схемою даних. Розроблено систему потокової передачі даних. Розроблену концепцію повністю реалізовано у GCP з метою проведення функціонального тестування.Problems in programming 2022; 1: 67-74 Інститут програмних систем НАН України 2022-05-30 Article Article application/pdf https://pp.isofts.kiev.ua/index.php/ojs1/article/view/489 10.15407/pp2022.01.067 PROBLEMS IN PROGRAMMING; No 1 (2022); 067-074 ПРОБЛЕМЫ ПРОГРАММИРОВАНИЯ; No 1 (2022); 067-074 ПРОБЛЕМИ ПРОГРАМУВАННЯ; No 1 (2022); 067-074 1727-4907 10.15407/pp2022.01 uk https://pp.isofts.kiev.ua/index.php/ojs1/article/view/489/488 Copyright (c) 2022 PROBLEMS IN PROGRAMMING |
| institution |
Problems in programming |
| baseUrl_str |
https://pp.isofts.kiev.ua/index.php/ojs1/oai |
| datestamp_date |
2022-07-12T19:05:24Z |
| collection |
OJS |
| language |
Ukrainian |
| topic |
serverless analytical datastore BigQuery AWS GCP ETL message data streaming UDC 004.042 |
| spellingShingle |
serverless analytical datastore BigQuery AWS GCP ETL message data streaming UDC 004.042 Tiurin, V.O. Doroshenko, А.Yu. Savchuk, E.V. Analytical store for streaming data with huge volume |
| topic_facet |
serverless analytical datastore BigQuery AWS GCP ETL message data streaming UDC 004.042 безсерверні аналітичні сховища BigQuery AWS GCP ETL повідомлення потокова передача даних УДК 004.042 |
| format |
Article |
| author |
Tiurin, V.O. Doroshenko, А.Yu. Savchuk, E.V. |
| author_facet |
Tiurin, V.O. Doroshenko, А.Yu. Savchuk, E.V. |
| author_sort |
Tiurin, V.O. |
| title |
Analytical store for streaming data with huge volume |
| title_short |
Analytical store for streaming data with huge volume |
| title_full |
Analytical store for streaming data with huge volume |
| title_fullStr |
Analytical store for streaming data with huge volume |
| title_full_unstemmed |
Analytical store for streaming data with huge volume |
| title_sort |
analytical store for streaming data with huge volume |
| title_alt |
Аналітичне сховище для великих потокових даних |
| description |
A concept for organizing an analytical data warehouse has been developed, which includes a method of interaction between data producers and a repository, a method of data circuit control, a method of data streaming, a method of storing initial data, a method of data processing and a method of providing secure data access. Other concepts on the market are discussed, namely: SDLF as the leading standard recommended by AWS, IronSource DL using Upsolver, SimilarWeb DL using Upsolver. A comparative analysis was conducted (mostly with SDLF, as its implementation is open, and the implementation by private companies is hidden). The advantages of the proposed concept over the existing ones are examined in detail. Recommendations on how to integrate the concept with data schema control applications are given. A service for streaming data using Apache Beam in Java has been developed. A repository architecture for analytics was designed and developed. A data schema management model was developed as well as a data schema management model and a model for secure access to data. The research that has been conducted can be improved by the experience of implementing the concept in business, as well as by collecting and systematizing knowledge about other standards that will be created.Problems in programming 2022; 1: 67-74 |
| publisher |
Інститут програмних систем НАН України |
| publishDate |
2022 |
| url |
https://pp.isofts.kiev.ua/index.php/ojs1/article/view/489 |
| work_keys_str_mv |
AT tiurinvo analyticalstoreforstreamingdatawithhugevolume AT doroshenkoayu analyticalstoreforstreamingdatawithhugevolume AT savchukev analyticalstoreforstreamingdatawithhugevolume AT tiurinvo analítičneshoviŝedlâvelikihpotokovihdanih AT doroshenkoayu analítičneshoviŝedlâvelikihpotokovihdanih AT savchukev analítičneshoviŝedlâvelikihpotokovihdanih |
| first_indexed |
2025-07-17T10:01:25Z |
| last_indexed |
2025-07-17T10:01:25Z |
| _version_ |
1838410299504328704 |
| fulltext |
67
Інформаційні системи
Вступ
У роботі описано концепцію архі-
тектурного рішення щодо безсерверного
(serverless) аналітичного сховища даних.
Запропоновані шляхи реалізації концеп-
ції, що дають змогу створювати аналітич-
ні сховища:
- швидкими (завдяки написанню
мінімальної кількості коду);
- з доброю масштабованістю (ле-
вова частка відповідальності за масштабу-
вання передається хмарному провайдеру);
- легкими у підтримці;
- з високим рівнем захисту даних;
- з легкою інтеграцією до засобів
прийняття рішень.
Наразі подібні системи мають над-
високий попит через те, що ціна сховищ
стала відносно дешевою і компанії отрима-
ли змогу зберігати й використовувати для
аналізу великі об’єми операційних даних
[1-4]. Через те, що не усі бізнеси мають до-
свідчені відділи ІТ, багато з таких компаній
зазнають невдач у процесі створення ана-
літичного сховища [5-6]. Створення кон-
цепції подібного сховища на базі одного
з найкращих провайдерів хмарних послуг
(GCP) може стати проривним як у техно-
логічному плані, так і у плані ефективності
бізнесових рішень.
Розмір фінансових інвестицій у га-
лузь уже сягає мільярдів доларів [7-8],
проте бракує саме науково-технологічних
робіт та стандартизації й аналізу наявних
рішень. Ця проблема існує тому, що галузь
розвивається дуже швидко і ще не підхо-
плена університетами. Тому науково-тех-
нічна документація здебільшого створена
самими розробниками систем або їх парт-
нерами із впровадження, а кожна робота
розглядає лише єдиний варіант власної
реалізації. Основна мета таких робіт – це
просування власного бізнесу, а не деталі-
зований технічний аналіз запропонованих
рішень.
Створений у даній роботі проєкт
концепції несе науково-технічну новизну
в порівнянні з існуючими рішеннями, що
перевіряється на детальному аналізі й фор-
мулюванні незалежної оцінки й оформлен-
ні концепції. Ця робота також дає можли-
вість комерційного використання, впрова-
дження або консультації із впровадження
концепції та супроводу його технічної ре-
алізації.
У роботі розглянуті існуючі рішен-
ня та стандарти у сфері побудови хмарних
аналітичних сховищ даних, здійснено їх
порівняльний аналіз на основі практич-
них реалізацій та надана незалежна оцінка
сформованій концепції.
Головна мета роботи – створення
концепції аналітичних сховищ даних.
Для цього потрібно було розв’язати
наступні задачі:
• розглянути існуючі рішення;
• провести аналіз;
• розглянути технічні можливості,
які не були запропоновані;
УДК 004.042 https://doi.org/10.15407/pp2022.01.67
В.О.Тюрін, А.Ю. Дорошенко, О.В. Савчук
АНАЛІТИЧНЕ СХОВИЩЕ
ДЛЯ ВЕЛИКИХ ПОТОКОВИХ ДАНИХ
Розроблено концепцію архітектури з організації аналітичного сховища даних на основі інфраструкту-
ри Google Cloud Platform (GCP). Проведено аналіз існуючих рішень у галузі безсерверних аналітич-
них сховищ. Проведено порівняльний аналіз із найбільш розповсюдженими існуючими рішеннями
та здійснено експериментальне випробування розробленої концепції. Наведено рекомендації з орга-
нізації сховища даних з можливістю підтримки подій із змінною схемою даних. Розроблено систему
потокової передачі даних. Розроблену концепцію повністю реалізовано у GCP з метою проведення
функціонального тестування.
Ключові слова: безсерверні, аналітичні сховища, BigQuery, AWS, GCP, ETL, повідомлення, потокова
передача даних.
© В.О.Тюрін, А.Ю. Дорошенко, О.В. Савчук, 2022
ISSN 1727-4907. Проблеми програмування. 2022. № 1
68
Інформаційні системи
• оцінити економічну складову;
• запропонувати відповідне архітек-
турне рішення.
Задля реалізації системи, яка відпо-
відала б заданій меті, були проведені тео-
ретичні та практичні дослідження у п’ять
етапів:
• базова теоретична підготовка про-
єкту, що включала в себе теоретичну під-
готовку по всім архітектурним та техноло-
гічним напрямкам, які належать до сфери
побудови аналітичних сховищ даних;
• теоретична підготовка в розділах
хмарних систем, поглиблення знань та
практичних навичок у використанні різ-
них провайдерів хмарних послуг, вивчення
сервісів, котрі надаються у використання;
• технічна реалізація концепції;
• порівняльний аналіз;
• створення технічної документації.
Проєкт є безкоштовним для корис-
тувачів, проте на основі розробки може
бути створена компанія, що буде надавати
послуги із впровадження моделі. Цільо-
вий сегмент компаній, які можуть вико-
ристати цей науковий проєкт, дуже широ-
кий. Фактично це може бути будь-яка ком-
панія, яка виросла достатньо, щоб почати
використовувати свої операційні дані для
прийняття рішень.
Для технічної реалізації ідей концеп-
ції були обрані сучасні хмарні технології.
Огляд платформи AWS Serverless Data
Lake Framework (S DLF)
AWS Serverless Data Lake
Framework (SDLF) – це стандарт (готове
архітектурне рішення), засноване на ком-
понентах (ресурсах) екосистеми AWS.
Рис. 1. Архітектурна схема AWS SDLF[10]
69
Інформаційні системи
Це дозволяє швидко створювати «озеро
даних» Data Lake, що відповідає сучас-
ним потребам [9-10]. SDLF є головним
конкурентом на ринку для розроблюва-
ного стандарту.
Основними перевагами SDLF є:
• швидке розгортання (AWS Team
надає шаблони готової інфраструктури);
• безсерверна архітектура (дозво-
ляє значно скоротити необхідні навички
і відповідно чисельність команди під-
тримки);
• гнучкість до змін (є можливість
вставити свій код бізнес-логіки в поточну
архітектуру).
До недоліків належать:
• повна залежність від AWS як про-
вайдера інфраструктури (схема не може
бути реалізована в інших хмарах);
• значні приховані затримки (latency)
при високому навантаженні;
• незручний формат Landing Zone
(файли із записами); у процесі реконси-
ляції чи під час пошуку проблеми знайти
інформацію у Landing Zone майже немож-
ливо;
• дуже складна модель контролю да-
них;
• невирішеність проблеми контролю
схеми даних.
Використання Upsolver
для IronSource DataLake
IronSource DataLake – це архітек-
турне рішення для побудови аналітичного
сховища компанії. Компанія використала
Upsolver – продукт, що полегшує створен-
ня подібних систем.
IronSource використовує Upsolver
в найтяжчому для реализації місці в сис-
темі – контролі за схемами і взаємодії з
продюсерами даних. Завдяки використан-
ню ще одного продукту Kafka, керованого
подіями, та регістру схем Schema Registry
з’являється гарантія несуперечності схем
постачальника та споживача даних.
Архітектура DataLake передба-
чає рівень RAW (LANDING) зберігання
початкових даних – у даній архітектурі
цей рівень, як і в SDLF реалізовано за
допомогою Amazon S3 та файлів. Серед
переваг цього підходу можна виділити
дешевизну й зручність застосування од-
ночасно декількох Query Engines до од-
них і тих самих даних. Проте водночас є
й недоліки:
• дуже скаладна реконцеляція RAW
Layer; тобто, за наявності певних проблем
із несуперечністю даних перевірка даних
на рівні RAW стає непростою задачею для
інженерів;
Рис. 2. Архітектурна схема IronSource DataLake[11]
70
Інформаційні системи
• необхіднсть додаткових інвести-
цій у моніторінг системи для створення за-
собів контролю за збереженням несупер-
ечності;
• подвійна вендорна залежність –
компанія залежить і від AWS, як від про-
вайдера хмарних сервісів, і від Upsolver як
провайдера платформи інтеграції із поста-
чальниками даних.
SimilarWeb DataLake
SimilarWeb DataLake – це архітек-
турне рішення компанії для побудови
системи Anomaly Detection на Web сто-
рінках.
Виходячи із особливостей викорис-
тання системи очевидно, що подібне озеро
DataLake орієнтоване на короткотривале
збереження початкових даних через їх ве-
личезну кількість. Система має адаптува-
тися до неструктурованих даних через те,
що компанії необхідно фільтрувати значну
кількість веб-сторінок, розроблених різни-
ми компаніями, які, відповідно, не стан-
дартизовані.
SimilarWeb також використовує
Upsolver для вирішення проблеми пото-
кової обробки потоків даних. На схемі
можна побачити, що початкові дані збе-
рігаються в окремому сховищі S3 лише 1
день (термін, необхідний для обробки да-
них), далі події групуються у логічні гру-
пи, виділяються унікальні ключі тощо.
Зі схеми можна також побачити, що
SimilarWeb виеористовує AWS Glue Data
Catalog для контролю схеми даних. Ком-
панія будує супер-сет моделі даних (кон-
кетенація можливих полів) для подальшо-
го використання у запитах Athena. Athena
використовується як система побудови за-
питів до даних і виявлення даних, що від-
різняються від заданих правил або правил
розподілу.
Подібна система має обмеження і не
може бути повністю автоматизованою, бо
різні потоки подій можуть конфліктувати
між собою, тому їх потрібно розділяти.
Різні дані одного й того ж потоку та-
кож можуть конфліктувати один з одним,
тому для реалізації потокової обробки ком-
панія і вирішила використати готовий про-
дукт.
Таким чином, серед значних недо-
ліків цієї архітектури можна також зазна-
чити:
• подвійну залежність від провайде-
рів послуг (AWS для ресурсів та Upsolver,
що повністю контролює логіку потокової
обробки);
• відсутність Data Marts і можли-
вості повторно перевикористати вже існу-
ючі обчислення;
• обмеження Athena як провайдера
машини SQL.
Опис запропонованої концепції
Запропонована схема має наступний
алгоритм роботи:
Потокова передача даних у Pub/Sub
– вхідну точку для даних до хмари.
Потокова передача даних із Pub/Sub
до Landing Zone.
Паралельний запис кожної події в
контролюючу таблицю.
Обраховування зміни даних (дельти)
за обраний часовий проміжок.
Оновлення даних по виборці дельти.
Побудова Data Marts.
Підготовка даних для використання
кінцевими сервісами-користувачами (ма-
Рис.3. Архітектурна схема SimilarWeb DataLake[12]
71
Інформаційні системи
шинне навчання (МЛ), засоби візуалізації,
засоби прийняття рішень);
Паралельний моніторинг процесів і
ключових метрик.
Засоби безпечного доступу до даних
На сьогодні існує багато загроз, що
можуть призвести до несанкціоновано-
го доступу до даних. Такі загрози можуть
бути зовнішніми, як - от:
• хакерська атака;
• кібер-атака іншої держави або те-
рористів;
• атака зі сторони іншої компанії
або третіх сторін.
Також загрози можуть бути і вну-
трішніми від джерел (або людей), що на-
віть не знають про це:
• шахрайство (fraud);
• атака колишнього/діючого праців-
ника з певним рівнем доступу;
• бездіяльність або приховування
(працівник міг зробити помилку, що при-
звела до витоку даних і під страхом наслід-
ків він може приховати факт події);
• ненавмисне заволодіння даними
під час розробки чи підтримки системи.
Багато реалізацій аналітичних схо-
вищ мають проблеми із забезпеченням
безпеки, особливо в останньому пункті зі
списку. Через низький рівень автоматизації
такі системи вимагають постійного досту-
пу до даних користувачів для розробників
системи.
Запропонована концепція не має та-
кого недоліку, надання доступу до даних
dataset відбувається за допомогою Identity
and Access Management(IAM), тому лише
авторизовані для цієї операції можуть
отримати доступ.
Якщо лише частина даних є таєм-
ницею, наприклад, userId – не є секретом,
бо не є PII, а email користувача – має бути
захищеним, то в GCP існує ресурс Data
Catalog, який передбачено використову-
вати під час реалізації концепції для того,
Рис. 4 Запропонована архітектурна схема із використанням GCP
72
Інформаційні системи
щоб захистити окрему колонку даних. Data
Catalog дозволяє створити ярлик (label) на
колонку із даними, додати його до групи і
надати доступ до групи лише авторизова-
ним користувачам. Тож концепція значно
скорочує і визначає коло осіб, що мають
доступ до даних користувачів системи.
Для захисту від зовнішніх загроз іс-
нує практика не надання прямого доступу
до аналітичного сховища стороннім серві-
сам, навіть тієї ж самої компанії.
Запропонована концепція реалізує
цей засіб захисту – доступ до сховища не-
можливий із зовнішнього середовища, точ-
кою взаємодії із зовнішнім світом є Pub/
Sub – для завантаження даних, що пере-
даються потоком Datafl ow, який написано
інженерами, що розуміють будову сховища
і несуть за нього відповідальність. Доступ
до Data Mart для користувачів є «тільки для
читання», тобто вони не можуть змінити
дані, а весь доступ також є авторизованим
(і для людей, і для сервісів за допомогою
Service Account).
Порівняльний аналіз моделей
Запропонована концепція має зна-
чну перевагу у надійності Entry Point.
Якщо в SDLF – це сервіс, що зберігає
файли (S3), а файли з даними можуть бути
великими, то цей стандарт може мати про-
блеми із незавершеним завантаженням і
відповідно втратою даних. На відміну від
цього запропонована концепція викорис-
товує Pub/Sub [13-16], що здійснює прин-
цип “at least once delivery”, який гаран-
тує доставку повідомлення один раз або
більше, що виключає можливість втрати
даних на цьому кроці. Upsolver викорис-
товує для цих цілей Kafka Schema Registry
та дає своїм користувачам можливість
контролю схеми даних. SimilarWeb до-
датково використовує AWS Glue Schema
Registry для того, щоб мати схему ще й на
рівні машини запитів Query Engine, якою в
даному випадку є AWS Athena. Kafka є ек-
вівалентною до запропонованого рішення
за надійністю, проте значно складнішою у
налаштуванні та підтримці (навіть у без-
серверній реалізації).
Запропонована концепція має зна-
чну перевагу у методі потокової пере-
дачі даних над головним конкурентом
– SDLF. Він використовує технологію
Dataflow [17-18], що працює на шабло-
нах, які реалізують Apache Beam – про-
відний стандарт у сфері сховищ даних
ETL [17]. Це дозволяє використовувати
здобутки бібліотек із відкритим кодом і
писати складні потоки із використанням
малої кількості самописного коду. Крім
того, Dataflow запускається на контр-
ольованому кластері з машин, на відміну
від AWS Lambda [19] в SDLF. Це озна-
чає, що система краще масштабується і
коштує значно дешевше навіть за умови
великих і дуже великих даних. Як ви-
дно із досвіду IronSource та SimilarWeb
багато компаній не бажають мати справу
з потоковою обробкою великих даних й
купують вже готові сервіси. Однак інже-
нери компанії все одно мають розуміти,
як працює їх потокова обробка для того,
щоб знати, чи задовольняє реалізація
вендора їх бізнес-потреби. Додатково це
значно збільшує залежність від провай-
дера послуг. Запропонована концепція
має значну перевагу над архітектурами
IronSource та SimilarWeb, тому що вико-
ристовує бібліоеки з відкритим кодом.
Запропонована концепція має зна-
чну перевагу в організації зони Landing
над усіма конкурентами за рахунок
Dataset в BigQuery. Це дозволяє робити
запити до даних мовою SQL, перегляда-
ти їх, конвертувати, проводити реконси-
ляцію (перевірку несуперечності систе-
ми) на відміну від інших, де дані фізич-
но зберігаються у файлах, тож пошук
конкретного запису фактично неможли-
вий. Серед недоліків цього підходу мож-
на зазначити вищий рівень витрат на
сховище, проте якщо брати повну вар-
тість володіння систем ТСО, а не окремі
витрати на сховище, то різниця буде не
такою великою, бо підтримка стає про-
стішою (означає, що треба витрачати
менше людино-годин кваліфікованих
працівників), немає потреби у окремій
системі моніторингу за несуперечністю,
результати обробки даних можна пере-
використовувати.
Запропонована концепція має зна-
чну перевагу у моделі оновлення даних,
73
Інформаційні системи
адже ця операція виконується за допо-
могою відкритої бібліотеки Airfl ow [21],
створеної для керування складними ETL-
процесами і вже реалізовує дуже багато
логіки всередині, яка може бути переви-
користана на відміну від реалізації SDLF,
де процес обробки даних передано на AWS
Lambda, тобто на самописний код.
Ще однією перевагою Airflow є
використання кластеру виконувачів на
основі Kubernetes. Тобто оплата відбува-
ється за кількістю використаних годин і
потужністю інфраструктури кластеру, а
не за кількістю викликів. Таким чином
запропонована модель обробки даних
буде значно дешевшою на великих да-
них, ніж SDLF.
Вразливість моделей
до зміни схеми даних
Однією з найбільших проблем аналі-
тичних баз даних є необхідність адаптува-
тися до зміни початкових даних, водночас
зберігаючи якість кінцевих даних. Очевид-
ним недоліком SDLF є повна відсутність
контролю схеми даних, що унеможливлює
побудову повноцінного сховища.
Якщо компанія бере на використан-
ня SDLF, то підтримка схеми лягає на від-
повідальність сервісів озера даних Data
Lake. Такий підхід до архітектури може
бути правильним, проте ця особливість не
підкреслена в документації стандарту для
того, щоб мати змогу говорити про “дуже
швидке розгортання SDLF від розробки до
Production”. Однак необхідність самостій-
ної інтеграції контролю схем, наприклад, за
допомогою Kafka Schema Registry[13-15],
забере багато додаткового часу.
На відміну від SDLF, запропонована
концепція може працювати у двох режи-
мах.
Перший режим аналогічний до
SDLF. Він передбачає передачу відпові-
дальності за схему даних попередньому
сервісу, тобто архітектура передбачає, що
до сховища доходять лише валідні повідо-
млення.
Другий режим передбачає викорис-
тання Pub/Sub Schema Registry, що буде
перевіряти схему повідомлення на етапі
спроби відправки сервісом постачальника
даних. Постачальники, які не будуть від-
правляти повідомлення у схемі, підтриму-
ваної сховищем, просто не зможуть від-
правити таке повідомлення й отримають
зрозумілу відповідь про помилку.
Такий підхід має значну перевагу че-
рез те, що помилки виявляються на першо-
му ж кроці, коли постачальник намагаєть-
ся відправити повідомлення, а не на кінце-
вому, як в SDLF, коли дані вже у сховищі,
проте їх неможливо обробити, через те, що
схема змінилася або зовсім невалідна.
Важливо зазначити, що у великих
системах, де кількість унікальних типів
подій може вимірюватись сотнями і тися-
чами, в обох концепціях (запропонованому
та SDLF стандарті), слід делегувати відпо-
відальність за валідацію схем централізо-
ваному сховищу Event Store.
Висновки
У роботі розроблено концепцію ор-
ганізації аналітичного сховища даних, а
саме:
• метод взаэмодії постачальників
даних зі сховищем;
• метод контролю схеми даних;
• метод потокової передачі даних;
• метод зберігання початкових да-
них;
• метод обробки даних;
• метод надання безпечного досту-
пу до даних.
Розглянуто інші існуючі на ринку
стандарти, а саме:
• SDLF – провідний стандарт реко-
мендований AWS;
• IronSource DL із використанням
Upsolver;
• SimilarWeb DL із використанням
Upsolver.
Проведено порівняльний аналіз
(здебільшого з SDLF, позаяк його реаліза-
ція відкрита, а деталі реалізацій приватних
компаній є таємницею). Детально огляну-
то переваги запропонованої концепції над
існуючими. Наведено рекомендації щодо
способу інтеграції концепції із застосунка-
ми із контролю схеми даних.
Розроблено сервіс потокової пере-
дачі даних за допомогою Apache Beam мо-
вою Java.
74
Інформаційні системи
References
1. Електронний ресурс [01.02.2022]: https://
aws.amazon.com/data-warehouse/
2. Електроний ресурс [01.02.2022]: https://
cloud.mts.ru/cloud-thinking/blog/data-
warehouse/
3. Електроний ресурс [01.02.2022]: https://azure.
microsoft.com/en-us/resources/customer-stories
4. Електроний ресурс [01.02.2022]: https://
builtin.com/data-science/company-data-lake-
questions
5. Електроний ресурс [01.02.2022]: https://
databricks.com/discover/data-lakes/challenges
6. Електроний ресурс [01.02.2022]: https://
lingarogroup.com/blog/8-challenges-faced-
by-ctos-when-starting-data-lake-projects/
7. Електроний ресурс [01.02.2022]: https://
www.qlik.com/blog/2020-the-year-cloud-
data-warehouses-arrived
8. Електроний ресурс [01.02.2022]: https://www.
castordoc.com/blog/cloud-data-warehousing-
the-past-present-and-future
9. Електроний ресурс [01.02.2022]: https://catalog.
us-east-1.prod.workshops.aws/v2/workshops/
501cb14c-91b3-455c-a2a9-d0a21ce68114/en-US
10. Електроний ресурс [01.02.2022]: https://
docs.aws.amazon.com/prescriptive-guidance/
latest /pat terns/deploy-and-manage-a-
serverless-data-lake-on-the-aws-cloud-by-
using-infrastructure-as-code.html
11. Електроний ресурс [01.02.2022]: https://
www.upsolver.com/case-studies/ironsource-
how-built-petabyte-scale-data-lake
12. Електроний ресурс [01.02.2022]: https://aws.
amazon.com/blogs/big-data/how-similarweb-
analyze-hundreds-of-terabytes-of-data-every-
month-with-amazon-athena-and-upsolver/
13. Електроний ресурс [01.02.2022]: https://
docs.confluent.io/platform/current/schema-
registry/index.html
14. Електорний ресурс [01.02.2022]: https://
habr.com/ru/company/alfastrah/blog/547092/
15. Електроний ресурс [01.02.2022]: https://
www.bigdataschool.ru/blog/kafka-big-data-
schema-registry.html
16. Електроний ресурс [01.02.2022]: https://
cloud.google.com/pubsub/docs/schemas
17. Електроний ресурс [01.02.2022]: https://
cloud.google.com/datafl ow
18. Електроний ресурс [01.02.2022]: https://
habr.com/ru/post/122479/
19. Електроний ресурс [01.02.2022]: https://
beam.apache.org/
20. Електроний ресурс [01.02.2022]: https://aws.
amazon.com/ru/lambda/
21. Електроний ресурс [01.02.2022]: https://
airfl ow.apache.org/
Отримано: 18.02.2022
Про авторів:
Тюрін Валерій Олександрович,
магістрант Національного
Технічного Універсистету України
«КПІ імені Ігоря Сікорського».
Дорошенко Анатолій Юхимович,
доктор фізико-математичних наук,
професор, завідувач відділу теорії
комп’ютерних обчислень, професор
кафедри інформаційних систем
та технологій Національного
Технічного Універсистету України
«КПІ імені Ігоря Сікорського».
Кількість наукових публікацій
в українських виданнях – понад 190.
Кількість наукових публікацій
в зарубіжних виданнях – понад 80.
Індекс Хірша – 6.
http://orcid.org/0000-0002-8435-1451
Савчук Олена Володимирівна,
кандидат технічних наук, доцент кафедри
інформаційних систем та технологій
Національного Технічного Універсистету
України «КПІ імені Ігоря Сікорського».
Кількість наукових публікацій
в українських виданнях – понад 100.
Кількість наукових публікацій
в зарубіжних виданнях – 3.
Індекс Хірша – 2.
http://orcid.org/ 0000-0003-3176-7952
Місце роботи авторів:
Національний технічний університет
України «Київський політехнічний
інститут імені Ігоря Сікорського»,
проспект Перемоги 37
та Інститут програмних систем
НАН України, 03187, м. Київ-187,
проспект Академіка Глушкова, 40.
Тел.: (044) 526 3559
E-mail: tiurinvalery@gmail.com
doroshenkoanatoliy2@gmail.com
elenasavchuk0@gmail.com
|