serge_gorshkov


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

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


Previous Entry Share Next Entry
Semantic Days-2013: модные тенденции сезона
serge_gorshkov

"У нас было 2 data warehouse, 75 реляционных баз данных, 5 наборов справочных данных, пол-офиса ИТ-специалистов и целое множество интеграционных решений всех сортов и расцветок, а также сервер под OS/2, мэйнфрейм, общая папка с CSV-файлами и шкаф с бумажными инструкциями. Не то что бы все это было необходимо для работы. Но если начал автоматизировать бизнес, становится трудно остановиться."
Нет, это не цитата из римейка "Страха и ненависти в Лас-Вегасе". Примерно так начинались многие доклады, посвященные практическим применениям семантических технологий, прозвучавшие на конференции Semantic Days-2013, которую я имел честь посетить на прошедшей неделе. Понятно, что такая постановка проблемы не нова, и мало изменилась за последний десяток лет - интересно наблюдать за тем, как меняются подходы к ее решению. Семантические технологии уже давно ощущаются передовыми силами общества как средство радикального избавления от интеграционных проблем, а вот представления о практическом способе реализации этого пути эволюционируют.

Если раньше модно было говорить о том, что информационные системы так или иначе обмениваются между собой данными (представленными в общей семантической форме), то теперь на первый план выходит концепция, когда над существующими приложениями надстраивается некий компонент, который можно условно назвать логическим data warehouse. Все данные остаются там, где они лежат (в реляционных базах данных). Логический data warehouse содержит общую концептуальную модель информации (онтологию), содержащейся во всех объединяемых системах, и мэппинги каждого элемента онтологии на соответствующий источник данных (попросту говоря - SQL-запрос или его часть, которая позволяет получить из исходной базы данные, соответствующие элементу онтологии). Кроме того, логический data warehouse содержит пользовательский интерфейс, дающий возможность пользователю "задавать вопросы" к логической модели (проще говоря, строить SPARQL-запросы к онтологии при помощи более или менее очеловеченного интерфейса). Эти запросы затем автоматически трансформируются в SQL-запросы в соответствии с мэппингами, выполняются, и пользователь получает желаемый результат. Таким образом, интеграции как таковой вроде бы и нет, а объединить информацию из разных источников пользователю легко.

Такой подход, с некоторыми вариациями, реализован в очень интересном проекте Optique, в TopBraid Insight, некоторых конкретных практических решениях, основанных на протоколе SDShare. Суть тренда очевидна: если раньше говорилось об интеграции или интероперабельности (с целью организации прежде всего операционного взаимодействия между приложениями), то теперь на первый план выходит аналитическая функция. Как я и считал с самого начала работы с семантическими технологиями, их главное преимущество с точки зрения бизнес-ценности состоит не в том, чтобы облегчить обмен данными между приложениями (хотя и эта функция никуда не девается), а в том, чтобы предоставить пользователю такие возможности анализа данных, которые не реализуемы на реляционных базах данных или их группе, хотя бы просто в силу сложности построения соответствующих запросов.

У предложенного подхода есть очевидные недостатки, о которых, конечно, докладчики не стали особо распространяться. Во-первых, если изменится структура одной из объединяемых общей логической моделью БД, то "полетят" мэппинги, исправлять их придется вручную, а найти соответствующую точку (по крайней мере, при помощи тех прикладных средств, которые сейчас используются в Optique) будет крайне сложно. Во-вторых, получающиеся SQL-запросы могут быть избыточно сложными (насколько я понял, 50 join'ов в одном запросе - это еще не предел). В-третьих, далеко не факт, что всегда можно успешно смэпить концепт из логической модели на SQL-запрос.

Так что я бы скорее рассматривал такое решение как временный "костыль", который будет применим до тех пор, пока трипл-сторы не научатся хранить и быстро обрабатывать такой объем информации, чтобы от логического семантического data warehouse можно было перейти к физическому. Здесь есть большая сложность, связанная с тем, что, в отличие от реляционной базы данных, трипл-стор невозможно кластеризовать, и, как следствие, построить систему параллельной обработки запросов. Хотя, эту проблему обещает решить YarcData, дочерняя компания Cray, создавшая трипл-стор, способный держать в памяти (!) и обрабатывать до 512 Тб данных.

Впрочем, пока что это не главная проблема. Как было очень точно сказано в одном из докладов, "there is no "big data" problem; there is a big "data problem". Так что организации, решившей встать на путь исправления ситуации, описанной в первых строках этого поста, сначала надо навести порядок с логической (онтологической) моделью данных, а затем решать технические проблемы - по мере их возникновения.


  • 1
<Семантические технологии уже давно ощущаются передовыми силами общества как средство радикального избавления от интеграционных проблем, а вот представления о практическом способе реализации этого пути эволюционируют.>

Не могли бы вы популярным языком рассказать о симантических технологиях и их применении на практике?
Мне сейчас очень близка тема автоматизации процессов и управления базами банных. Я когда вас читаю, подсознанием понимаю, что происходит что-то важное, но что понять не могу.

поддерживаю вопрос :)

что конкретно предлагается? платформа для написания 50 джойнов?

На вопрос ответил ниже, а Optique - это действительно платформа, автоматизирующая написание 50 join'ов. Она позволяет сконструировать такой запрос бизнес-пользователю (аналитику), не привлекая программиста.
На конференции приводили пример, когда это бывает нужно. Например, Siemens производит турбины для электростанций. В турбине есть большое количество датчиков, которые выдают до 30Гб данных в сутки. Если в турбине что-то идет не так (наблюдается отклонение от нормальных параметров работы), инженерам нужно понять, что там случилось (причем, не останавливая турбину). Для этого им нужно найти похожие паттерны в данных, которые встречались когда-либо ранее. Инженер формулирует на словах свой "вопрос" к базе. Раньше он передавал его ИТшникам, которые писали на его основе SQL-запросы, и извлекали нужную информацию из базы. Потом инженер уточнял запрос или выдавал следующий, ИТшники снова извлекали, и так далее. Это было неэффективно с точки зрения трудозатрат, и долго.
Optique позволяет инженеру самому "задавать вопросы" к базе при помощи относительно понятного интерфейса, а в запросы он уже сам трансформируется. "Движком" этого решения является семантическая модель - в терминах этой модели инженер задает вопросы, они же потом становятся "кирпичиками", из которых собирается SQL-запрос к данным.

Идея такова: семантическая форма представления информации (т.е. в виде триплетов, грубо говоря) принципиально отличается от привычного нам таблично-реляционного способа представления тем, что в ней отсутствует какая-либо структура. То есть, любая реляционная БД - это "модель закрытого мира", в нее можно положить только такие данные, которые предусмотрены моделью (т.е. структурой базы). А семантическое представление реализует "модель открытого мира", т.е. в нем можно записать совершенно любую информацию, т.е. модель (структура) и сами данные - технически одно и то же. В техническом смысле, у семантических данных нет никакой структуры, это примерно как наша с вами речь. Аналогия, конечно, грубая.
Благодаря этому, такую форму представления удобно использовать для передачи информации между разными системами. В системе А своя структура базы, в системе Б - другая, а если мы будем передавать между ними информацию в семантической форме, то механизм обмена не будет никак зависеть от структуры каждой из баз. Что очень удобно.

Есть разные варианты реализации этой идеи, которые отличаются в основном подходом к тому, как строить онтологию (ту самую модель мира), как физически передавать данные между системами, и как строить алгоритмы их интерпретации. У нас на сайте есть практический пример реализации при помощи нашего продукта: http://www.business-semantic.ru/products/howitworks. Больше подробностей о технической стороне реализации - здесь: http://habrahabr.ru/post/167419/
Но, повторю, это только один из возможных вариантов.


  • 1
?

Log in

No account? Create an account