Integration of heterogeneous data in corporate information systems

Интеграция разнородных данных в корпоративных информационных системах

Единое информационное пространство является ключевым фактором успешности современного бизнеса. Одной из важнейших целей сообщества разработчиков баз данных является переход от управления традиционными БД к задаче управления наборами структурированных, полу структурированных и неструктурированных данных, распределенных по многим репозиториям корпоративных систем. Поэтому возникает задача интеграции гетерогенных данных.

В данной работе рассматривается система хранения структурированных данных в различных базах данных. Такие системы называют гетерогенными системами. Гетерогенные системы обычно возникают в тех случаях, когда узлы, уже эксплуатирующие свои собственные системы с базами данных, со временем интегрируются в распределенную систему.

Задача построения гетерогенных систем возникла из области распространения мастер-данных (distribution of master data) или Master Data Management (MDM) ^[1]. Все департаменты организации нуждаются в наиболее полной информации, которую необходимо собрать, используя все критичные для бизнеса мастер-данные (клиенты, продукты, поставщики, НСИ и т.д.). Потребителя таких данных интересуют не столько сами данные, сколько их объединения или агрегаты (например, клиента вместе со счетами и инструментами, которыми он торгует).

Данные распространяются согласно трем основным сценариям: выгрузка массива данных по расписанию (bulk load), подписка на обновления (publish-subscribe), поисковые запросы (request-response).

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

Создание общего для всех пользователей интерфейса, который будет гибким и расширяемым, может решить данную проблему. В качестве такого интерфейса можно рассмотреть язык запросов для сценариев bulk load и request-response. Чтобы обеспечить достаточную скорость выполнения, требуется за этим интерфейсом иметь промежуточный буфер с быстрым доступом и иметь способ маршрутизации запросов к этому буферу. Таким образом, можно достигнуть баланса между переиспользованием ресурсов (если 2 клиента делают одни и те же запросы) и производительностью этих запросов.

Для хранения данных в таких системах можно использовать БД различного типа. Опыт показывает, что Oracle лучше справляется с более непредсказуемыми и сложными запросами ^[2], а NoSQL база данных - с простыми типовыми запросами.

Рассмотрим далее MongoDB, которая является наиболее распространенной NoSQL БД. Она представляет собой документо-ориентированное нереляционное хранилище данных, использующее для хранения данных формат BSON – расширение формата JSON (JSON – JavaScript Object Notation, BSON – Binary JSON) ^[3].

NoSQL базы данных обладают достаточно интересными свойствами, которых нет у реляционных баз данных. Однако у NoSQL решений есть существенные недостатки, которые не позволяют полностью отказаться от использования реляционной БД: ненадежность, отсутствие запросов типа join, отсутствие транзакций (кроме Neo4J), у каждой NoSQL БД свой (более узкий, чем у реляционных БД) спектр задач.

Объединение в гетерогенной БД реляционной БД Oracle и базы данных MongoDB обусловлено необходимостью эффективного выполнения запросов поиска данных. Разные модели данных позволяют выполнять один и тот же запрос за разное время на разных серверах, что при оптимальном выборе сервера может дать существенный выигрыш в производительности системы.

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

Вопрос интеграции данных достаточно актуален. Компания Oracle создала архитектуру системы интеграции больших данных на основе ETL (ETL (от англ. Extract, Transform, Load — дословно «извлечение, преобразование, загрузка») ^[4]. Процесс ETL поддерживают компании Microsoft SQL Server/SSIS, Hadoop/Apache Hive & Spark, IBM Однако, ETL-технологии как правило построены на использовании вспомогательного ПО и предназначенные для реляционных БД. В некоторых случаях проблему можно решить с помощью предметного языка запросов к хранилищу разнородных данных как показано в ^[5].

В данной работе проблема разнородной структуры запросов к базам данных решалась с помощью расходящейся разработки, опирающейся на предметно-специфичный язык (англ. DSL-Based Development). DSL (domain-specific language) добавляет разработчику еще один уровень абстракции – уровень представления данных^[6]. Это увеличивает гибкость создания системы^[7].

Созданная гетерогенная система состоит из четырех подсистем (рисунок 1): подсистемы синтаксического анализа и построения семантической модели, подсистемы принятия решений, базы данных и интерфейса пользователя.

Рисунок 1. Архитектура системы

Синтаксический анализатор обрабатывает информацию, поступающую от пользователя. Подсистема построения семантической модели строит модель и формирует объект-документ MongoDB и запрос на вставку(Insert) для БД ORACLE.

В нашей системе за принятие решения, в какой БД будет выполняться запрос, отвечает модуль «принятия решения». Этот модуль на основании статистики времени выполнения подобных запросов отправляет текущий запрос на соответствующую базу данных. Для поддержания запросов, требующих рассмотрения нескольких документов, скорее всего, будет использоваться SQL база данных, а для запросов требующих рассмотрения одного документа, – MongoDB. Интерфейс пользователя позволяет искать нужную информацию в гетерогенной системе.

Проблема потери данных в разрабатываемой системе не актуальна, т.к. данные часто обновляются, не являются ценными и не являются частными данными пользователя. Синхронизация данных достигается во время обновления. Приоритетным в нашей системе является время выполнения запроса.

Рассмотрим подробнее все модули системы. Для оценки скорости обработки запросов созданной системы гетерогенная база была заполнена информацией о фильмах, хранящихся в online порталах сети Internet.

Подсистема синтаксического анализа и построения семантической модели.

Поисковые запросы пользователя выполняются по схеме, представленной на рисунке 2.

Синтаксический анализатор (парсер) — это программа или часть программы, выполняющая синтаксический анализ. В ходе синтаксического анализа исходный текст преобразуется в дерево разбора (синтаксическое дерево), которое отражает синтаксическую структуру входной последовательности и хорошо подходит для дальнейшей обработки. Синтаксическое дерево является гораздо более полезным представлением сценария, чем слова, поскольку с ним можно работать различными способами, по-разному обходя дерево. Синтаксическое дерево чаще всего формируется в стеке вызовов и обрабатывается при его обходе ^[7].

Рисунок 2 Сценарий обработки поисковых запросов

Для создания синтаксических анализаторов использовался генератор парсеров ANTLR^[8] (от англ.ANother Tool for Language Recognition — «ещё одно средство распознавания языков»). ANTLR позволяет автоматически генерировать программу‑парсер по LL(*) грамматикам. В системе создан ANTLR скрипт, описывающий грамматику для синтаксического анализатора и интерфейс, служащий для реализаций правил этой грамматики. Запросы к базе формируются с помощью querydsl ^[9].

На рисунке 3. приведен ANTLR скрипт, описывающий грамматику для синтаксического анализатора.

Рисунок 3. ANTLR скрипт, описывающий грамматику для синтаксического анализатора.

Запросы, созданные на разработанном языке запросов, с помощью генератора запросов преобразуются либо в BSON-запрос к MongoDB либо в SQL запрос. Ниже приведены примеры запросов с использованием созданной грамматики (схема данных БД ORACLE приведена на рисунке 7, иерархия классов MongoDB на рисунке 6).

Пример 1. Найти информацию о фильме по названию

find film name=’name’.

BSON-запрос к MongoDB.

> db.film.find({name : "name"});

SQL запрос.

Select * from FILM_SEACHERS_FILMS

where FILM_NAME = ‘name’

Пример 2. Найти название фильма, в котором роли исполняли Харди и Уильямс.

find film persons(‘role’ is{‘Харди’,’Уильямс’}}

BSON-запрос к MongoDB.

> db.film.find( { {role: ‘role’},persons:[ “Харди”,”Уильямс”]

SQL запрос.

Select f.FILM_NAME

from FILM_SEACHERS_PERSON_TO_FILM ptf

join FILM_SEACHERS_FILMS f on f.ID = ptf.FILM_ID

join FILM_SEACHERS_PERSONS p on p.ID = ptf.PERSON_ID

join FILM_SEACHERS_PROFS pr on pr.ID = ptf.PROF_ID

where p.NAME in (‘Харди’,’Уильямс’)

and pr.PROF_NAME =’role’;

В созданной системе существует два сценария обработки входной информации. Первый сценарий, рассмотренный выше, предназначен для поиска информации в гетерогенной системе. Второй сценарий предназначен для заполнения баз данных по интернет контенту. База была заполнена информацией о фильмах, хранящихся в online порталах сети Internet.

На рисунке 4 приведен ANTLR скрипт для распознавания html страницы сайта Megogo.com. Скрипт предназначен для распознавания персон.

Рисунок 4. ANTLR скрипт для распознавания html страницы сайта Megogo.com.

На вход созданному ANTLR анализатору (парсеру) приходит html страница и этот парсер, согласно написанной грамматике, строит синтаксическое дерево. Пример такого дерева для формирования списка персон, относящихся к фильму, показан на рисунке 5.

Рисунок 5 . Дерево для формирования списка персон

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

В разработанной системе создана реализация такого интерфейса. Она позволяет заполнить семантическую модель во время обхода дерева. Семантическая модель представляет собой иерархию классов, показанную на рисунке 6. Эта иерархия в случае MongoDB совпадает с набором классов, описывающих документы MongoDB.

Рисунок 6. Иерархия классов MongoDB

Подсистемы принятия решений.

DecisionMaker - сервис возвращающий базу данных, в которой запрос выполнять выгоднее. В данной работе реализован следующий подход.

Имеется таблица созданная в Oracle Database, в которой записывается время выполнения запроса в каждой БД. В данном случае запрос представляется шаблоном, в котором все конкретные значения полей заменяются на «?». DecisionMaker создает шаблон запроса и ищет этот шаблон в таблице. Из двух БД выбирается та, в которой этот запрос выполняется за наименьшее время.

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

Если DecisionMaker не принял никакого решения, то запрос выполняется в обеих БД параллельно. Данные о выполнении этого запроса записываются в таблицу.

Созданная архитектура системы может быть применена для любой предметной области. При реализации системы возникает проблема заполнения информацией баз данных. Данные может вводить пользователь, данные можно брать из сторонних систем. Одним из источников информации являются интернет ресурсы. Для использования такого ресурса необходимо написать собственную грамматику для разбора web страниц.

Базы данных и интерфейс пользователя.

Созданная система реализована для поиска фильмов в online порталах сети Internet.

Схема данных для хранения информации о фильмах и персонах, связанных с киноиндустрией, для ORACLE database показана на рисунке 7.

Рисунок 7. Схема базы данных ORACLE

Модель в MongoDB представляет собой набор следующих сущностей, показанных на рис.6. Для работы с MongoDb используется ORM(Object-relational mapping) Google.morphia. ORM - технология программирования, которая связывает базы данных с концепциями объектно-ориентированных языков программирования, создавая «виртуальную объектную базу данных». В случае использование Google.morphia достаточно создать ряд объектов, описав их с помощью соответствующих классов.

Интерфейс системы был создан с помощью следующих технологий:JSP, css, JavaScript, Spring.

Для оценки скорости обработки запросов созданной системы гетерогенная база была заполнена информацией о фильмах, хранящихся в online порталах сети Internet.

Для разработки системы используется язык Java и потребовались следующие библиотеки, средства и базы данных: Spring , Google.morphia , QUERYDSL, MongoDB, ORACLE database.

Все эксперименты проводились на ноутбуке под управлением операционной системы Ubuntu 17.04 (64-bit) с процессором Intel(R) Core(TM) i7-2630QM CPU. Описание тестирования приведено в ^[10].

Результаты тестирования созданной базы приведены ниже (Таблица1).

Таблица 1. Статистика системы

Анализ приведенной таблицы показал, что запросы, требующие соединения двух или более документов в MongoDB выполняются в разы медленнее, чем в Oracle Database. Однако, простейшие запросы (по критериям одной сущности, например фильма), в MongoDB выполняются на порядок быстрее. Например, запрос “find film” MongoDB выполняет в 66 раз быстрее, чем Oracle Database.

Заключение

В статье представлен метод интеграции гетерогенных данных, обеспечивающий сокращение времени передачи информации и повышение ее достоверности. Описано несколько языков, для распознавания информации от каждого источника и одна семантическая модель. Представлен также единый способ хранения информации из разных источников. Разработана семантическая модель, позволяющая отражать данные из сети интернет в базы данных. Разработан язык для поиска информации. Создана LL грамматика для анализа web страниц.