Сценарии интеграции приложений (3)

Я довольно редко пишу о сценариях интеграции и потому не могу закончить с интеграцией данных и перейти к интеграции приложений и сквозным бизнес-процессам. Тем не менее, интеграция данных это важно. ESB, SOA и прочие трехбуквенные сокращения, занимая наше внимание, отвлекают нас от других, намного более важных трехбуквенных сокращений, таких как ODS и DWH. ODS и DWH – «рабочие лошадки» ИТ архитектуры предприятия, способные избавить нас от множества лишних информационных систем и оппортунистических связей между ними.

Начнем с довольно древней, но правильной картинки и определений:
Буковками i/t на картинке обозначены процессы интеграции и преобразования, которые сегодня назвали бы ETL (Extract, Transform, Load). ODS (Operational data store) — база данных, разработанная для интеграции данных из разнородных источников и последующего использования этих данных приложениями. Одним из таких приложений является DWH (Data warehouse). Вот здесь появляется некоторая путаница. Понятие DWH, обычно переводимое на русский язык как хранилище данных, ассоциируется у большинства людей с отчетностью. В частности, в Википедии прямо так и написано, что DWH – это база данных для отчетности. Все остальные технологии, расположенные «за DWH», например витрины данных (Data mart) воспринимаются как инструменты аналитики, а не операционных процессов. Операционным процессам же остается Operational data store. В этом нет ничего страшного, если воспринимать ODS в широком смысле, т.е. не просто как хранилище транзакций за последние X дней, но как полноценный источник данных, как для пользователей, так и для приложений. Причем данных, касающихся не только операций, но и информации о задействованных в них ресурсах.

В простой корпоративной информационной среде данные принято читать напрямую из систем см. паттерн «Общая база данных» в Сценарии интеграции приложений (1) Однако, довольно быстро нагрузка на базу данных вырастает и такая возможность улетучивается. Обычно, это событие связано с появлением в компании аналитиков, которые любят покопаться в данных запросами в стиле “SELECT *…”, не очень представляя при этом, что же именно они ищут. Собственно эти пользователи и являются инициаторами создания в компании хранилища данных, в котором они могут удовлетворить своё любопытство посредством многомерных кубов и прочих изощренных инструментов анализа. Тем временем остальным служащим компании, не занятым в формировании отчетов и гадании на кофейной гуще, тоже надо работать. И им тоже нужны данные. Но компания уже прикупила DWH, потратила кучу денег и вкладываться еще раз в какое-то там хранилище не собирается. Потому задача предоставления актуальных данных остальным пользователями ложится на плечи интеграторов. Типичная задача: пользователь одной системы хочет получить данные из другой. Напрямую в базу данных второй системы уже не пускают – наелись с доступностью и временем отклика. Тогда программист из первой системы дает страшную клятву администратору второй, что данные выгружать он будет раз в сутки, в час наименьшей нагрузки, при помощи оттестированного запроса. Они ударяют по рукам и вскоре во второй системе появляется еще одна вьюха (view). В «продвинутых» компаниях рано или поздно появляется единый инструмент для интеграции данных, который по расписанию читает одни базы данных и пишет в другие, но ситуацию это улучшает не сильно, потому как сам подход не особо правильный.

Правильным, с точки зрения ИТ архитектуры предприятия является следующий подход:

Берем и ставим в компании одну большую базу данных. Называем её DWH, если это название еще не занято или же ODS, что более правильно, но менее понятно. Прорабатываем набор программных и пользовательских интерфейсов. При проектировании программных интерфейсов следует быть осторожным в предоставлении прямого доступа к данным, а предпочтение отдавать веб-сервисам в стиле REST или SOAP В качестве пользовательского интерфейса присмотритесь к Oracle APEX. По мере поступления запросов от пользователей на интеграцию данных наполняем наше хранилище. Т.е. разница с описанным выше подходом заключается в том, что мы не разрешаем приложениями загружать в себя данные из других приложений. Данные можно читать и даже изменять в ODS, но нельзя копировать в свою БД. На самом деле, такие механизмы как теги(метки), аннотации, комментарии, коллекции, категории будут более чем уместны в таком ODS. Реализовать это совсем не сложно, особенно при наличии RESTful интерфейса. Впрочем, это скорее бантики. Важнее организовать процедуры подключения и использования такого ресурса, включая квотирование и разграничение доступа. Ну и, безусловно, структуру ODS надо тщательно проектировать. Простое копирование данных из систем источников не подходит. Нужен хороший архитектор данных, способной создать робастые схемы и прилично разбирающийся в предметной области.

Реклама

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s