serge_gorshkov


Сергей Горшков - о бизнесе в сфере ИТ

о семантической интеграции, программировании, управлении...


Previous Entry Share Next Entry
Логическая витрина для доступа к большим данным
serge_gorshkov
Настал торжественный миг: мы доделали работающий и вполне развитый прототип логической витрины для больших данных. Статью о нем я в виде исключения опубликовал на Хабре - это связано с желанием привлечь аудиторию, которая много слышала про Big Data, но ничего не знает о семантике и отнологиях. Статья написана соответствующим образом, поэтому приведу здесь несколько дополнительных комментариев для читателей, которые лучше знакомы с онтологиями, чем с Big Data.

Итак, задача витрины - выполнять запросы, исходные данные для которых рассредоточены по разным источникам. В качестве примера в статье я взял относительно реалистичный кейс с промышленным оборудованием, снабженным большим количеством датчиков, которые регулярно выдают информации о его состоянии. Если показания датчиков надо хранить - они могут пригодиться для анализа аварийности, оптимизации энергоэффективности и т.д. - имеет смысл делать это в хранилищах Big Data.
Хранилищ этого класса существует немало, а мы для примера взяли два: HBase и HDFS. HDFS - это распределенная файловая система, входяшая в набор ПО Hadoop. HDFS способна хранить огромные объемы данных, распределяя файлы между узлами незаметным для пользователя образом. Она предоставляет HTTP-интерфейс для доступа к файлам, которым мы и воспользовались. HBase - еще один компонент стека Hadoop, распределенная нереляционная база данных. Информация в ней хранится в таблицах, которые состоят из строк и объединенных в группы столбцов. Каждая строка имеет уникальный текстовый ключ и не интерпретируемые базой значения столбцов. В веб-интерфейсе таблица HDFS выглядит примерно так:



HBase предоставляет REST-интерфейс для доступа к данным.

Еще один компонент стека BigData, который мы использовали - расчетный модуль на основе библиотеки алгоритмов Spark MLlib. Эта библиотека содержит реализации ряда алгоритмов машинного обучения, которые позволяют решать задачи классификации, кластеризации, оптимизации и т.д. Для решения каждой задачи необходим программный модуль (мы создали его на Python), использующий некий набор фактических данных для обучения алгоритма. После этого становится возможным решать конкретные задачи на основе полученной модели. Мы "научили" модель классифицировать штатные и предаварийные состояния оборудования, сделали ей интефейс в виде веб-сервиса, и подключили к витрине в качестве источника данных. Витрина передает сервису информацию о характеристиках состояния котла, и получает в ответ классификацию этого состояния.

Ради таких вот вычислений Big Data и создавались. Само по себе это неплохо, но по факту получилось, что эти технологии:

  • Применяются для обработки данных однообразной, несложной структуры;

  • Ориентированы на обработку данных при помощи фиксированных алгоритмов, реализуемых императивным программированием;

  • Не имеют цели предоставить пользователю доступ к исследованию самих исходных данных – человек имеет дело лишь с относительно компактными результатами их обработки.

В результате для каждого нового способа обработки данных нужно звать программиста. В этом смысле Big Data попахивают серьезным регрессом, или точнее - заходом на новый виток развития технологии, в результате чего пришлось временно вернуться к устаревшим практикам.

Вернусь к нашей витрине и скажу несколько слов о том, как создаются и выполняются запросы к источникам данных. Витрина получает обычный запрос к графу, построенный при помощи одного из интерфейсов АрхиГраф.СУЗ, вот только информации для его выполнения у нее нет - в трипл сторе лежат лишь основные данные и настройки мэппинга. Система определяет список типов объектов, встречающихся в запросе, и начинает искать в модели сведения о том, в каких источниках находятся фрагменты данных этого типа. Как было показано в примере, объекты одного типа (измерения температуры) могут быть распределены между разными источниками, и здесь требуется дополнительная логика, чтобы понять, куда именно надо обращаться. Описание каждого источника детализировано на уровне элементов данных: столбцов HBase, PostgreSQL или текстового файла из HDFS, входных и выходных параметров веб-сервиса. Определившись с нужными источниками, система обращается к ним, получает ответы, и вносит их во временный граф. Чтобы отразить эту напряженную работу мысли, в интерфейс АрхиГраф.СУЗ выводятся вот такие сообщения:



Кстати, если кому интересно - могу дать доступ к интерфейсу витрины на нашем стенде, пишите в почту или в личку.

  • 1
Сергей, из картинок в статье на Хабрахабре следует, что у вас периоды времени и результаты измерений — литералы.
Сможете вкратце рассказать о проблемах, которые привели к такому решению?

И вы не думали над тем, чтобы в подсказках интеллектуального поиска учитывался грамматический род? Вычислялся бы на лету или хранился бы в типе.

Да, периоды и результаты - литералы. А что особенного в таком решении, и почему к нему должны привести какие-то проблемы? :) Для меня это совершенно естественное решение.
Есть объект - измерение, он имеет атрибуты-литералы - время, значение, и атрибут-связь, указывающий на прибор и тип показателя. Если вкратце, в реальности может быть еще много нюансов.

Насчет рода - да, это нужная вещь, но пока не можем себе позволить сделать такую доработку.

По поводу времени: я думал, у вас период, задаваемый двумя его концами, а не точечный момент.
Для точечного момента действительно подходит xsd:datetime (а хоть бы и xsd:string), а для интервала в xsd ничего подходящего нет. Вот буквально сейчас посмотрел: есть только xsd:Duration — длина без указания точного начала и конца. Зато вот тут — https://www.w3.org/TR/owl-time/ — есть time:Interval.

По поводу результата измерения: у него ведь есть единица измерения. Например, один датчик измеряет в милли-, а другой в микро-. Вы ведь где-то разбираете подходящий паттерн ISO 15 926.
Впрочем, там же вы пишете (нашёл где):
Наш программный продукт не осуществляет, говоря вообще, их «осмысления» (то есть преобразований, связанных со смыслом передаваемой информации), за исключением мэппинга…
Отчего бы не осуществлять-то :) ?

Интервал я бы задавал двумя xsd:datetime. Про OWL Time посмотрел, вещь интересная, но не слишком, т.к. нет готовых функций для обработки интервалов, формализованных таким образом. А руками их писать - никакого профита.

Про единицу вы правы, я ее подразумевал где-то под "прочими нюансами" в предыдущем ответе.

Про осмысление - это было про другой продукт, про шину. Она не хочет ничего осмыслять, она просто транспорт :) Если говорить про СУЗ, то другое дело.

  • 1
?

Log in

No account? Create an account