Архітектурні особливості Smart City

Архітектурні  особливості 

в інформаційній системі 

обробки даних  

розумного міста(Smart City)

Проблемні питання:

1.Які виникають проблеми при  підтримці послуг високонавантаженої системи Smart City?

 2.Які можливі рішення для досягнення кінцевої узгодженості між послугами системи Smart City?

Міські   органи влади можуть аналізувати великі обсяги інформації, виявляти типові для людини операції і визначати індивідуальні потреби громадянина, що дозволить їм краще надавати такі послуги:

- визначення прав на соціальні пільги;

- пошук роботи;

- сплата податків і штрафів;

- продовження ліцензій;

- видача сертифікатів і дозволів;

- запис на прийом до лікаря;

- прийом в школи і університети;

- запис на отримання житла;

- управління дорожнім рухом;

- обробка скарг;

- віртуальні муніципалітети;

- реєстрація виборців.

Найбільший корисний ефект від створення електронного уряду може бути отриманий за рахунок тих послуг для населення, які надаються разом з такими послугами, як доступ до Інтернету і електронна пошта, комерційні портали і веб-вузли електронної комерції. Успішні проекти електронних державних служб привертають не тільки тих людей, які вже підключені до Інтернету, але і приводять в онлайн-середовище людей, які там ще не були..

Міські організації все більше покладаються на свої інтелектуальні активи на протилежність матеріальним, якими вони управляють. Рішення з управління знаннями стають ключовими у побудові та підтримці інтелектуальних капітальних активів та застосуванні їх для створення

економічних цінностей. Рішення у сфері управління знаннями дають можливість індивідам, командам людей і цілим спільнотам досягати набагато більшого у створенні, фіксації, передачі та оволодінні знаннями.

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

зробити наступне:

- стимулювати інновації;

- сприяти розвитку співпраці;

- заохочувати і використовувати можливості навчання;

- збільшити соціальний капітал;

- залучати і зберігати людський капітал;

- створювати і використовувати структурний капітал;

- відкривати можливість електронного управління;

- збільшити продуктивність;

- ділитися найкращою практикою і процесами;

- забезпечити лідерство і прийняття рішень;

- збільшити рівень задоволення клієнтів;

- створити конкурентноспроможну перевагу і ринкову диференціацію.

Основною проблемою з послугами та базами даних є значна кількість запитів, які виробляються мільйонами пристроїв і як їх досить швидко обробляти та зберігати. 

Основна характеристика інформаційної системи Smart City: 1)низька затримка; 

2)висока масштабованість; 

3)стійкість до збоїв. 

 База даних Smart City повинна мати:

1) декілька стратегій для запитів баз даних; 

2)синхронізацію сервісу; 

3) моніторинг  подій.

Існує декілька типів архітектури та бази даних, які вже використовуються в більш простих підсистемах. Необхідно вирішити ключовий аспект - як синхронізувати(паралельне та послідовне опрацювання) дані між різними службами в інформаційній системі Smart City. 

Для вирішення цих проблем необхідно переробити вже існуючу технологію, яка використовується для більш простих завдань, приєднатися до них і застосувати нове рішення.

Проблеми БД Smart City при використанні будуть виникати тоді, коли треба отримувати або застарілі типи даних, або  нові типи дані не зможуть працювати з системою.

Кожне оновлення  БД  вимагає відправлень в обидва боки – до певної центрального вузлу або до певного кворуму серверів, а якщо комунікація відбувається повільно (наприклад, через географічну відстань між клієнтом і сервером або між репліками) то постраждає продуктивність і час відповіді між клієнтами системи.

Всі компоненти розумного міста мають бути інтегровані за допомогою сервіс-орієнтованої архітектури. Міська архітектура є, по суті, масштабною розподіленою системою, яка по своїй суті є складною і децентралізованою.

Різні платформи, неоднорідна обстановка та різноманітність мереж датчиків призведуть до проблем сумісності. Сервісно-орієнтована архітектура з її відкритими стандартами, такими як JSON, GraphQL, XML забезпечує не тільки взаємодію між різними платформами, але також підтримує модульний дизайн, повторне використання програмного забезпечення, взаємодію та інтеграцію додатків. Таку архітектуру легко впроваджувати, а деякі частини системи можна зробити на основі Event-Driven архітектури. Для оброблення подій та ініціалізації веб-сервісів (для безпосередньої роботи) можуть бути використані три стратегії:

проста, потокова і комплексна.

-Просте опрацювання полягає в ініціалізації веб-сервісів по мірі реєстрації відповідних подій. Основна перевага такої системи — це робота в режимі реального часу. Мінус очевидний

– не враховується фактор пріоритету.

-Потокове опрацювання  враховує існуючі залежності веб-сервісів і об’єднує кілька

сервісів в один загальний потік. Цей підхід виправдовує себе в системах з великими

накладними витратами на пошук і отримання інформації з баз даних.

-Комплексне опрацювання  – це так зване управління за відхиленнями. Будь-яка подія

розцінюється як вихід системи зі стану рівноваги. Ініціалізація веб-сервісів переслідує єдину мету – повернути систему в стан рівноваги (задовольняючи потреби клієнтів системи).

Для забезпечення нормальної роботи систем є сенс вважати помилки при роботі систем не як рідкісні випадки, а як передбачувану частину нормальної роботи.

Наприклад, зв'язок між мобільним клієнтом і сервером може вийти з ладу, оскільки користувач проїжджає через тунель або здійснює посадку на літак.

 Найчастіше, помилки роблять програму непридатною для використання, іноді не вказуючи на те, що пішло не так, і коли ми можемо очікувати нормального функціонування для відновлення. У гіршому випадку, збої можуть призвести до постійної невалідного стану даних або їх повної втрати.

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

Ці аспекти дуже важливі при розгляді того, як краще провести компроміс між стабільністю та доступністю. Проте на абстрактному рівні всі ці системи базуються на принципах узгодженості: спільні дані оновлюються в різних запитах, оновлення передаються асинхронно, а конфлікти постійно вирішуються.

Для реалізації асинхронних протоколів використовуються різні технології MessageBrokers (МВ) [1]. Метою брокерів повідомлень є отримання вхідних повідомлень від додатків та виконання дій на них в майбутньому. У типовій архітектурі повідомлення, які вважаються бізнес-критичними, надсилаються в MB, де зберігаються повідомлення та розсилаються відповідним слухачам на надійний гарантований спосіб.

Якщо в компоненті відбувається помилка обробки, перш ніж обробляти повідомлення, MB буде вимагати повідомлення після того, як компонент буде перезавантажено, або передасть іншому аналогічному серверу, який зможе впоратися з ним.

Для обробки подій, що можуть відправлятись на смарт пристрої можна застосовувати процесор подій. Цей компонент дозволяє розпізнавати послідовності повідомлень, які можуть сигналізувати тип події. Один тип послідовності може представляти загрозу безпеці. Інша послідовність може означати можливість щось продати комусь. Послідовність повідомлень має відбуватися протягом певного періоду часу. У світі IoT сервер CEP – (Complex Event Processing) може шукати послідовність повідомлень, які можуть вказувати на те, що хтось переміщується з кімнати в кімнату, щоб світло було включено або вимкнено, або навіть більш складні розрахування. Двигун CEP може зробити пристрої IoT розумними, визнаючи поведінку в деяких випадках і навіть в пристроях. Історичні дані для IoT сервісів зростають швидко і часто досягають десятків петабайт. Популярним рішенням роботи з даними є зберігання історичних даних на репліках. У такому  випадку, коли дані можуть зберігатись у декількох джерелах, потрібно використовувати map-reduce алгоритм. Крім того, історичні дані потрібно індексувати та використовувати шардінг для досягнення прийнятної швидкості запитів. Якщо сервіс буде використовувати хмарні технології, то важливу частину цих задач бере на себе постачальник послуг.

Для синхронізації БД, якщо, наприклад, потрібно побудувати навколо вже існуючого сховища пошуковий індекс, краще використовувати наступні техніки:

Використання невеликої програми, яка буде відслідковувати зміну даних в БД (update, delete) використовуючи певний стовбець (зазвичай Modified Date) та відправляти їх для  оновлення в іншу БД. Такий спосіб є підходящим для невеликих систем, де дані оновлюються не так часто і в більшості своїй є статичними.

Реплікація журналу (CDC – change data capturing): найшвидший спосіб - більш-менш золотий стандарт у реплікації даних. Вона включає в себе запит внутрішньої змінної журналу вашої бази даних кожні кілька секунд, копіювання змін у сховище даних та їх частому використанню. Всі зміни до вказаних вами таблиць і об'єктів завантажуються за замовчуванням, використовуючи журнал змін, тому нічого не втрачається. CDC - це не тільки швидший, надійніший спосіб, він також впливає значно менше на продуктивність бази даних під час запиту та допомагає уникати завантаження повторюваних подій. Однак, це потребує

більше налаштувань і у випадку, якщо БД не підтримує його за замовчуванням, тоді доведеться

самому використовувати допоміжне програмне забезпечення.

CDC - це найкращий спосіб для баз даних, які постійно оновлюються, він повністю підтримує видалення.

Так як всі процеси в системі потрібно контролювати для розуміння працездатності та помилок програмного забезпечення, потрібен моніторинг за бізнес - активністю сервісів. Цю роль можна покласти на сервіс моніторингу BAM (business activity monitor).

Він призначений для обробки великих потоків повідомлень з різних джерел, включаючи файли журналів або джерела, які, можливо, не орієнтовані на повідомлення. Сервер BAM може обчислювати ключові бізнесові або операційні показники на основі всіх потоків повідомлень. Він може обчислювати показники SLA (Service Level Agreement), середні й підсумкові значення, а також генерувати події на основі значень, в діапазон яких потрапляли ці показники. Ця функціональність може використовуватися для цілей операцій або для бізнес-показників.

Часто потоки потрапляють у велику вітрину даних для подальшої обробки та аналітики. У середовищі IoT сервер BAM - це збирач даних для пристроїв IoT. Він передає дані в сховище даних, а також виконує обчислення та видає нову інформацію та події. Тут ви можете вказати, що ви хочете сумувати всю електроенергію, яка використовується у домі або в бізнесі, або в середньому за енергію протягом години. BAM може публікувати ці розрахунки періодично як події.

Висновки. 

Існує декілька типів архітектури та баз даних, які вже використовуються в більш простих системах, тому для побудови модулів Smart City з потрібними вимогами, доцільно реконструювати вже існуючі технології та об'єднати їх для застосування у модулях Smart City.

Основними вимогами до модулів та систем зберігання даних у високонавантажених системах Smart City є:

- Консистентність даних системи у часі між собою (Eventual Consistency) та можливість до швидких відновлень у разі падіння,

- Підтримання сховищами реплікацій журналу та механізмів обробки повідомлень,

- Взаємодія модулів у системі не напряму, а через посередника – наприклад, брокера повідомлень,

- Моніторинг активності сервісів, які використовуються, для розширення аналітики бізнес-процесів.