Логічна вітрина для доступу до великих даними

Технології Big Data створювалися в якості відповіді на питання «як обробити багато даних». А що робити, якщо обсяг інформації не є єдиною проблемою? В промисловості та інших серйозних застосуваннях часто доводиться мати справу з великими даними складною і змінної структури, розрізненими масивами інформації. Зустрічаються задачі, спосіб вирішення яких наперед не відомий, і аналітику необхідні засоби дослідження вихідних даних або результатів обчислення на їх основі без залучення програміста. Потрібні інструменти, що поєднують функціональну міць систем BI (а краще – перевершують її) зі здатністю до обробки величезних обсягів інформації.

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


Для розповіді нам знадобиться простий приклад складної задачі. Розглянемо якийсь промисловий комплекс, що володіє величезною кількістю обладнання, обвешанного різними датчиками і сенсорами, регулярно повідомляють відомості про його стан. Для простоти розглянемо тільки два агрегати, котел і резервуар, і три датчика температури котла і резервуара, а також тиску в котлі. Ці датчики контролюються АСУ різних виробників і видають інформацію у різні сховища: відомості про температуру і тиск в котлі надходять в HBase, а дані про температуру в резервуарі пишуться в лог-файли, розташовані у HDFS. Наступна схема ілюструє процес збору даних.

Схема процесу збору даних

Крім конкретних показань датчиків, для аналізу необхідно мати список сенсорів і пристроїв, на яких вони встановлені. Оцінимо порядок числа інформаційних сутностей, з якими ми мали б справу на реальному підприємстві:
Сутність Порядок записів Тип сховища
Одиниці обладнання Тисячі Майстер-дані
Датчики, сенсори Сотні тисяч БД PostgreSQL
Показання датчиків Десятки мільярдів в рік
(питання глибини зберігання в цій статті не ставимо)
Файли у HDFS, HBase
Способи зберігання даних різних типів залежать від їх обсягу, структури і необхідного режиму доступу. В даному випадку ми обрали саме такі засоби для створення «різнобою», але і на реальних підприємствах найчастіше немає можливості вільно їх вибирати – все залежить від сформованого ІТ-ландшафту. Аналітичній системі потрібно зібрати весь «зоопарк» під одним дахом.

Нехай ми хочемо надати аналітику можливість робити запити такого типу:
  • Які одиниці маслонаповненого обладнання працювали при температурі вище 300 градусів за останній тиждень?
  • Яке обладнання знаходиться в стані, що виходить за межі робочого діапазону?
Заздалегідь побудувати і запрограмувати всі подібні запити не вийде. Виконання будь-якого з них вимагає зв'язування даних з різних джерел, в тому числі що знаходяться за межами нашого модельного прикладу. Ззовні можуть поступати, наприклад, довідкові відомості про робочих діапазонах температури і тиску для різних видів устаткування, фасетные класифікатори, що дозволяють визначити, яке обладнання є маслонаполненным, та ін Всі подібні запити аналітик формулює в термінах концептуальної моделі предметної області, тобто рівно в тих виразах, в яких він думає про роботу свого підприємства. Для подання концептуальних моделей в електронній формі існує стек семантичних технологій: мова OWL, сховища триплетів, мова запитів SPARQL. Не маючи можливості докладно розповідати про них в цій статті, пошлемося на російськомовний джерело.

Отже, наш аналітик буде формулювати запити у звичних термінах, і отримувати у відповідь набори даних – незалежно від того, з якого джерела ці дані витягнуті. Розглянемо приклад простого запиту, на який можна знайти відповідь у нашому наборі інформації. Нехай аналітик цікавиться обладнанням, встановлені на якому сенсори одночасно виміряли температуру більше 4000 і тиск більше 5 мПа протягом заданого періоду часу. У цій фразі ми виділили жирним слова, відповідні сутностей інформаційної моделі: обладнання, сенсор, вимір. Курсивом виділені атрибути та зв'язки цих сутностей. Наш запит можна представити у вигляді графа (під кожним типом даних ми вказали сховище, в якому вони знаходяться):

Схема графа запиту

При погляді на цей граф стає зрозумілою схема виконання запиту. Спочатку потрібно відфільтрувати вимірювання температури за заданий період зі значенням більше 4000 C, і вимірювання тиску зі значенням більше 5 мПа; потім потрібно знайти серед них ті, які виконані сенсорами, встановлені на одній і тій же одиниці обладнання і при цьому виконані одночасно. Саме так і буде діяти вітрина даних.
Схема нашої системи буде такий:

Схема архітектури системи

Порядок роботи системи такий:
  • аналітик робить запит;
  • логічна вітрина даних представляє його у вигляді запиту до графу;
  • вітрина визначає, де знаходяться дані, необхідні для відповіді на цей запит;
  • вітрина виконує приватні запити вихідних даних до різних джерел, використовуючи необхідні фільтри;
  • отримує відповіді і інтегрує їх в єдиний тимчасовий граф;
  • виконує пост-обробку графа, яка полягає, наприклад, у застосуванні правил логічного виводу;
  • виконує на ньому початковий запит, і повертає відповідь аналітику.
Вся «магія», звичайно, відбувається всередині вітрини. Перерахуємо принципові моменти.

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

Інтерфейс редагування моделі

2. У нашому прикладі дані одного і того ж типу (вимірювання температури) зберігаються одночасно в двох різних джерелах – HBase і текстовому файлі HDFS. Однак для виконання наведеного запиту звертатися до файлу не потрібно, оскільки в ньому свідомо немає корисної інформації: адже у файлі зберігаються вимірювання температури резервуара, а тиск в резервуарах не вимірюється. Цей момент дає уявлення про те, як повинен працювати оптимізатор запитів.

3. Вітрина даних не лише компонує і пов'язує інформацію з різних джерел, але і робить логічні висновки на неї згідно із заданими правилами. Автоматизація отримання логічних висновків – одне з головних практичних переваг семантики. У нашому прикладі за допомогою правил вирішена проблема одержання висновків про змозі пристрою на основі даних вимірювань. Температура і тиск містяться в двох різних сутності типу «Вимір», а для опису стану пристрою необхідно їх об'єднати. Логічні правила застосовуються до вмісту тимчасового графа результатів, і породжують у ньому нову інформацію, яка була відсутня в джерелах.

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

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

Інтерфейс побудови запитів

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

За рамками нашої розповіді залишилося чимало цікавих моментів:
  • організований збір даних сенсорів в HBase з допомогою Flume;
  • запити до джерел даних можуть виконуватися не просто асинхронно, але навіть при відсутності онлайн-зв'язку з ними – на цей випадок передбачений спеціальний механізм передачі запиту і одержання відповіді;
  • результати виконання запиту можуть не просто видаватися користувачеві у вигляді таблиці або вивантажуватися в Excel, але і потрапляти безпосередньо в BI-системи у вигляді набору даних для подальшого аналізу;
  • способи конвертації ідентифікаторів і посилань на об'єкти в різних джерелах, питання транспорту повідомлень між компонентами системи, і багато іншого.
Зрозуміло, реальні промислові застосування вітрини даних куди складніше описаного прикладу. Нашою метою в цій статті була демонстрація того, що використання семантичних технологій та концептуального моделювання в тандемі з засобами Big Data дозволяє розширити число доступних аналітику способів використання даних, вирішувати прикладні задачі в самих неординарних умовах. У поєднанні з можливостями контролю прав доступу до сховища триплетів і виконання тригерів на ньому, про яких ми вже розповідали, описані засоби дозволяють задовольняти досить вишуканим функціональним вимогам.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.