serge_gorshkov


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

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


Previous Entry Share Next Entry
PUSH, PULL или синхронизация?
serge_gorshkov
В процессе подготовки статьи для KESW-2013 столкнулся с тем, что разные специалисты имеют различные предпочтения по поводу модели обмена данными:

  • Pull - когда данные лежат в одном источнике, и достаются оттуда другими системами по мере необходимости,

  • Push - то же самое, плюс возможность инициировать передачу данных для других систем,

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

Грубо говоря, наша "Бизнес Семантика" - это скорее про синхронизацию (хотя возможны и другие применения), ISO 15926 - в основном про Pull (и немного про Push), а современная мода в плане логических семантических Data Warehouse (например, проект Optique, про который я рассказывал) - это чистый Pull.
Описания и оценка этих методов уложились у меня в следующий текст.



Семантические технологии медленно, но верно распространяются в бизнес-среде. Это приводит к распространению хранилищ триплетов (triple store), которое, в свою очередь, влечет за собой популяризацию идеи федеративного доступа к данным. Федеративным (federated) называется такой вариант доступа, когда каждый фрагмент данных хранится только в одной системе-источнике, а другие информационные системы по необходимости к ней обращаются. Это отличается от практики, сложившейся в мире реляционных баз данных, где распространены алгоритмы репликации данных, доставляющие копию тех или иных фрагментов информации туда, где они необходимы.
Различие обусловлено самой архитектурой хранилищ: в реляционных БД информация гранулирована, разбита на четко очерченные фрагменты – таблицы; в семантических хранилищах, как известно, фиксированная схема данных отсутствует. Каждый набор данных здесь состоит из узлов, имеющих произвольные связи как между собой, так и с узлами, находящимися вне данного хранилища. Именно поэтому можно сказать, что в общем случае содержимое хранилища триплетов невозможно разделить на логически целостные фрагменты, и реплицировать их – связи объектов все равно будут пересекать границы фрагментов. Следовательно, остро необходимы алгоритмы запроса информации, пересекающие границы физических хранилищ. В этой статье мы проведем обзор таких методов, и сфер их практического применения.


  1. Федеративные запросы SPARQL


Язык запросов к хранилищам триплетов SPARQL сам по себе содержит функционал федеративных запросов. В любой запрос можно включать части, которые содержат обращения к другим точкам доступа, и извлекают оттуда данные. Выглядит это примерно так:

SELECT ?name WHERE
{
  <http://example.org/myfoaf/I> foaf:knows ?person .
  SERVICE <http://people.example.org/sparql> { 
    ?person foaf:name ?name . } 
}


В этом запросе ссылки на людей, которых я знаю, хранятся в одной точке доступа (той, к которой адресован запрос), а имена этих людей извлекаются из другой точки доступа - http://people.example.org/sparql.

Недостаток такого метода очевиден: приложению, составляющему запрос, необходимо точно знать адрес точки доступа, откуда можно получить необходимую информацию, а также схему данных (онтологию), используемую в ней. Написание таких запросов в бизнес-приложениях приводит к вынесению части логики, связанной исключительно с физическим распределением данных, в программный код, создает ненужные привязки к конкретной информационной инфраструктуре. Понятно, что это обесценивает ряд преимуществ семантических технологий. С другой стороны, этот способ обладает несомненным достоинством – каждая единица данных находится только в одном хранилище, что исключает дублирование, сложности с репликацией данных.


  1. ISO 15926


Интеграционный стандарт ISO 15926, описывающий весь стек технологий, необходимых для универсального обмена данными между приложениями (от методологии моделирования до практических реализаций в программном обеспечении), предполагает использование как раз федеративных запросов SPARQL. Идеальная инфраструктура, построенная по принципам этого стандарта, должна включать сеть точек доступа SPARQL (фасадов), которые последовательно агрегируют информацию, по принципу «от частного – к общему». Точки доступа, соответствующие отдельным проектам внутри компании, предоставляют доступ к информации об этих проектах; точки доступа уровня подразделений агрегируют информацию о проектах, существенную для этого уровня, и предоставляют ее вышележащим точкам; фасады уровня предприятия имеют дело с тем, что в терминологии обычных БД можно было бы назвать мастер-данными. Возможен и обмен данными между предприятиями – запрос от одного фасада к другому может пересечь границу информационной инфраструктуры предприятия. Это бывает нужно, например, в классическом для примеров применения ISO 15926 случае, когда компания-покупатель отсылает поставщикам запрос определенных товаров или услуг, а те отвечают котировками.
Понятно, что в ряде случаев, в том числе в приведенном только что примере, PULL-запроса (извлечение данных) недостаточно; так как покупатель инициирует закупку, он должен сделать PUSH-запрос, то есть поместить в точки доступа всех поставщиков фрагмент графа, содержащий описание требований к закупаемым товарам и услугам. Поставщики, отвечая на этот запрос, также воспользуются PUSH-методом. Физически все эти запросы выполняются как обычные SPARQL-запросы к удаленным точкам доступа. Естественно, при этом возникает проблема, описанная в предыдущем пункте (привязка кода к информационной инфраструктуре и специфике данных, или конкретного бизнес-процесса). Также в полный рост возникает проблема безопасности: так как разграничить права доступа внутри содержимого точки доступа на данный момент возможности triple store’ов не позволяют, остается разделять сами точки. Так, в описываемом примере неизбежно возникнет точка доступа, предназначенная исключительно для обмена котировками с покупателями. Понятно, что такая схема далека от идеала контролируемой и универсальной ИТ-архитектуры.


  1. Push или Pull?


В среде разработчиков семантических приложений популярна точка зрения, что PUSH-запросов вообще должно быть как можно меньше. Это соображение отчасти справедливо; действительно, подавляющее большинство выполняемых в реальных инфраструктурах запросов является PULL-запросами (точно так же, как в реляционной БД количество SELECT’ов заведомо превышает количество запросов на обновление данных). Тем не менее, обойтись без PUSH на практике можно только в приложениях, занимающихся чистой аналитикой или агрегацией данных. В операционных приложениях, автоматизирующих текущую деятельность предприятия, запросы на передачу данных, инициируемые передающей системой, необходимы. Остается только решить, как лучше построить механизм их выполнения.


  1. SDShare


Один из приемлемых вариантов решения этой проблемы предлагает протокол SDShare. Его идеология строится на разделении данных, хранящихся в triple store, на коллекции (фрагменты графа, отражающие ту или иную более или менее целостную сущность бизнес-процесса; при этом связи могут пересекать границы фрагментов). Приложения имеют возможность «подписываться» на уведомления об изменениях в тех или иных коллекциях. Так, одно приложение может обратиться к другому с запросом – «что изменилось в коллекции такой-то?» В ответ оно получит набор фрагментов данных, изменившихся в данной коллекции. Такой подход позволяет реплицировать данные между набором фасадов, абстрагируясь от их содержания. Возвращаясь к нашему примеру, можно представить себе коллекцию «запросы поставщикам», хранящуюся в фасаде компании-покупателя. Поставщики, подписавшись на обновления этой коллекции, смогут получать обновления о новых запросах котировок. Правда, для этого им придется периодически опрашивать этот фасад.


  1. Синхронизация


Следующим шагом в совершенствовании этого подхода является создание протокола, позволяющего синхронизировать определенные фрагменты информации между системами. Синхронизацию с принудительным распространением изменений нельзя реализовать на triple store, поскольку там отсутствует механизм триггеров, необходимый для  выполнения обработчика при изменении данных. Однако, как правило, данные в хранилище триплетов помещаются из какой-либо реляционной базы данных. Следовательно, можно реализовать алгоритм распространения изменений из одной реляционной базы данных в другие хранилища, включая triple store. Такой протокол разработан и реализован в нашем приложении «Бизнес Семантика». Его архитектура использует привычные принципы сервисной шины предприятия (Enterprise Service Bus), и предусматривает подписку обменивающихся приложений на события, связанные с определенными типами данных, хранящихся в тех или иных системах. Центральный сервер координирует синхронизацию между группой информационных систем, среди которых могут быть реляционные БД (как отправляющие, так и получающие данные), так и triple store (работающие только на получение).
Такой подход удобен для решения двух классов практических задач: синхронизации мастер-данных (например, справочников клиентов, персонала, материальных активов в бизнес-приложениях), и онлайн-информирования об определенных событиях (например, о поступлении нового запроса цен от покупателя).

Таким образом, каждый способ обмена хорош для своей сферы применения; главный практический вывод состоит в том, что нельзя делать вывод о преимуществе того или иного способа обмена данными на основании конкретного применения, и переносить этот вывод на все остальные варианты использования семантических технологий для обмена между информационными системами.

  • 1
Согласен, что разные специалисты имеют различные предпочтения по поводу модели обмена данными. Например, этот документ рассматривает множество разных моделей, в том числе смешанных http://ptolemy.eecs.berkeley.edu/conferences/03/presentations/xiaojun_miniconf_03.pdf

Спасибо за ссылку на релевантную статью!
Да, на практике чаще используются смешанные модели, если только речь не идет о чистой аналитике (только pull) или, например, о мониторинге параметров каких-нибудь устройств (только push).

Давнишний пост, однако для меня ваша тема сейчас актуальна, я про ISO 15926.
Практика интеграции говорит о том, что в крупных и нагруженных системах PULL модель просто незаменима. Даже при реализации блокирующих вызовов в интерфейсах своих систем каждый разработчик использует промежуточные буферы: таблицы БД, или очереди MQ/AQ. делается только потому, чтобы развязать транзакции внутренних операций с транзакциями коммуникаций во избежание дидлоков в нескольких системах при использовании XA.

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

  • 1
?

Log in

No account? Create an account