Дата-центричная архитектура — гибкая работа с данными

Дата-центричная архитектура призвана решить проблемы сложности традиционной корпоративной ИТ-инфраструктуры, состоящей из множества приложений, обеспечивающих поддержку различных бизнес-процессов. Каждое приложение работает со своим хранилищем, часто описывающим одни и те же бизнес-объекты, хотя и с разных точек зрения. В дата-центричной архитектуре ядром являются данные, доступные через единую точку доступа. В идеальном случае через такую точку доступа приложения обращаются к данным в едином хранилище, но в процессе перехода от классической к дата-центричной архитектуре или в сложных системах с огромным объемом не консолидируемых физически данных ее роль исполняет логическая витрина. Такая витрина позволяет централизованно обращаться к данным из любых источников, в том числе хранящихся пока в отдельных бизнес-приложениях [1]. Важная часть логической витрины — модель консолидированных данных вместе с набором правил их преобразования из разных форматов и источников.

Два критически важных свойства такой модели — гибкость и целостность. Модель должна обеспечивать как интеграцию существующих данных из разных приложений, так и консолидацию новых, появляющихся по мере развития компании бизнес-алгоритмов. Гибкость и целостность модели обеспечиваются благодаря онтологиям — моделям, построенным по стандартам консорциума W3C [2] с использованием стека «семантической паутины» [3]. С точки зрения способа хранения онтологическая модель представляет собой граф, вершины и ребра которого — это понятия (концепты) с четко определенной семантикой. Вершины графа — это объекты, факты или сущности реального мира, представляемые онтологией, а ребра — связи между объектами или объектов со значениями. С логической точки зрения описание структуры информации в онтологии состоит из набора классов (представленных в виде вершин графа) — абстракций над объектами, объединяющих объекты одного типа, и свойств, которыми могут обладать объекты разных классов.

На примере компании РОЛЬФ разберем особенности использования онтологии при внедрении MDM-системы. Для обеспечения сотрудников всех уровней инструментами принятия решений на основе фактов и достоверных данных эта компания инициировала проект обновления своего ИТ-ландшафта, стратегии организации работы с большими данными и пересмотр подходов к принятию решений на основе данных (Data-Driven Decision Making). Работы по систематизации хранения данных выполнялись с помощью MDM-системы, построенной на базе семейства продуктов «АрхиГраф» [4].

Примеры гибкости применения онтологии

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

Рис. 1. Выдержка из модели работ. В прямоугольниках — классы (отмечены желтым), содержащие часто меняющиеся объекты, зеленым — классы-справочники со стабильным составом объектов; на стрелках — свойства (зеленым — литеральные, синим — связи между объектами); в параллелепипедах указаны типы данных для литеральных свойств. Использована визуальная нотация [5]

Рис. 2. Моделирование типов запчастей, необходимых для определенной работы. Кругами обозначены объекты, входящие в класс. Свойство rdf: type определено в спецификации RDF и означает принадлежность объекта классу

Рис. 3. Расширение модели для охвата количества запчастей, применимых к работе

Гибкость онтологической модели иллюстрирует пример реального сценария разработки модели работ. Задача — интеграция данных по работам для автомобилей (рис. 1). Все связи, кроме «нормочас» и «кодРаботы», — это связи между объектами. Объекты классов-справочников (помечены зеленым) загружены в модель на этапе ее разработки, а остальные объекты подгружаются непосредственно из источников данных. Связи «нормочас» и «кодРаботы» — это литеральные атрибуты, связывающие объект со значением (в данном случае — цифрой и строкой соответственно). На момент реализации описанных сценариев в классе «Работа» находится более миллиона объектов, в классе «Запчасть» — более трех миллионов.

Разберем три сценария, в которых было необходимо изменить уже имеющуюся модель, используемую бизнес-приложениями: 1) необходимость учета количества запчастей для каждой работы; 2) возможность поиска «универсальных» работ, применимых ко всем автомобилям конкретной марки; 3) обогащение информации о запчастях сведениями из работ.

Сценарий 1: учет количества запчастей

Первоначальный запрос при разработке модели предполагал необходимость фиксации только типов запчастей, необходимых для определенной работы, например, замена тормозного шланга будет связана с запчастями типов «тормозной шланг», «шайба» и «тормозная жидкость» (рис. 2). Однако в процессе работы возникли бизнес-требования, предполагающие также учет количества запчастей. Для этого в модель добавляется класс объектов, объединяющий тип запчасти с информацией о его использовании (рис. 3) — «ИспользуемаяЗапаснаяЧасть». Эти добавочные данные существуют параллельно с данными о типах запчастей, используемых при выполнении работы, и дополняют их.

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

Сценарий 2: возможность поиска «универсальных» работ

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

Рис. 4. Первоначальное представление характеристик работ в модели

Рис. 5. Реализация «универсальных» работ

В процессе функционирования системы потребовалась возможность поиска работ, относящихся ко всем автомобилям одной марки или универсальных для всех автомобилей. Такой запрос можно сконструировать путем перечисления всех возможных значений, но это неудобно и негативно сказывается на производительности системы. Чтобы избежать усложнения запросов, в модель были добавлены объекты, явно декларирующие, что значение данного свойства может быть любым, — характеристики «универсальных» работ (рис. 5). Например, для работы «ТОРМОЗНЫЕ ШЛАНГИ-ЗАМЕНА» известно, что она относится к автомобилю марки Porsche, с полным приводом и автоматической коробкой передач: для нее есть связи с соответствующими объектами классов «Марка», «ТипПривода», «ТипКоробкиПередач». Работа «ОБРАБОТКА СТЕКОЛ СРЕДСТВОМ “АНТИДОЖДЬ”» «универсальна» — одинакова для всех автомобилей, поэтому для нее аналогичные связи установлены с объектами «Любая марка» и «Любое значение» (данный объект имеет множественное наследование от всех классов, объекты которых являются значениями).

Такой подход позволил, не меняя ни структуру запроса, ни представление уже внесенных данных по работам, относящимся к конкретным автомобилям, вносить также и «универсальные» работы.

Сценарий 3: обогащение информации о запчастях от работ

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

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

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

Все три сценария демонстрируют, как онтологическое представление структуры данных позволяет быстро адаптировать ИТ-систему к требованиям бизнеса. В первом и втором сценариях был использован редактор онтологий АрхиГраф.Мир, для третьего — система управления знаниями АрхиГраф.СУЗ, позволяющая в том числе осуществлять логический вывод на основе уже имеющейся в системе информации. Оба инструмента имеют веб-интерфейс для работы бизнес-пользователей.

Принципы обеспечения гибкости представления данных

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

Разделение логики и кода

Онтологическая модель позволяет описать структуру данных как отдельный элемент ИТ-системы, связанный с исполняемым кодом, но не являющийся его частью. Онтология обеспечивает целостность представления структуры данных и относительную простоту ее изменения. Объединение в онтологии модели данных с самими данными, а также описанием элементов логики их обработки и предоставление пользовательского интерфейса для работы с моделью позволяют сократить временные издержки на внесение изменений в соответствии с требованиями бизнеса. Экономия достигается прежде всего за счет того, что изменения вносятся в модель аналитиком через пользовательский интерфейс, а не программистом — в программный код.

Ранее было приведено описание процессов построения модели предметной области, представленной объектами, объединенными в классы, и их свойствами. Объектами классов являются записи, получаемые из различных источников: информационные системы, базы данных, сервисы. Рассмотрим задачу, в которой есть три типа сущностей: Автомобиль, Работа и ЗапаснаяЧасть. Предположим, что эти сущности хранятся в трех разных информационных системах: ЗапасныеЧасти в учетной системе, например 1С; Работы — в таблицах реляционной СУБД; каталог автомобилей — доступен через внешний веб-сервис. Для консолидации таких данных требуется написать программный код, который объединит записи из трех источников. Полученный код не может быть статичным и будет изменяться при изменении бизнес-требований: смене состава данных, эволюционировании информационных систем, изменении модели и состава атрибутов. Все подобные изменения нужно отражать в коде: в случае SQL-запросов — менять наименования таблиц и переписывать условия команд SELECT, в более сложных случаях — переписывать программный код. Онтологический подход позволяет вынести управление изменениями на уровень моделирования — в приведенном примере достаточно изменить схему подключения к источникам самой модели и/или правила сопоставления модели со структурой данных источников.

Разработка с использованием модели верхнего уровня

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

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

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

Шаг 2. Выделенные концепты объединяются в группы с использованием онтологической модели верхнего уровня. Использование такой модели обеспечивает расширяемость и при этом препятствует семантическому дрифту — непредусмотренному расширению содержания класса из-за внесения в него объектов, незначительно отличающихся по смыслу от определения объектов данного класса, но в долгосрочной перспективе приводящих к размытию содержания класса и, как следствие, некорректной работе с данными.

Шаг 3. Версия демонстрируется заказчику, обсуждается соответствие модели предполагаемым сценариям использования. По результатам этого шага начинается следующая итерация.

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

На рис. 7 показана модель из обсуждаемых примеров со связями с классами онтологии верхнего уровня. Эти классы определены в онтологии Basic Formal Ontology (BFO) [6] и импортируются в разрабатываемую онтологию. Так, «Работа» является подклассом «bfo: Процесс» — сущности, по определению BFO, «являющейся максимально связным пространственно-временным целым и имеющей четко определенные начало и завершение», а «ЗапаснаяЧасть» — подклассом «bfo: Объект», то есть чем-то «существующим в трех измерениях, части которого связаны между собой определенным способом».

Рис. 7. Связи модели с онтологией верхнего уровня

В случае, когда появилась необходимость ввести класс для учета количества запчастей «ИспользуемаяЗапаснаяЧасть», его место в модели было определено исходя из того, чем сущностно являются объекты этого класса. С точки зрения онтологии BFO это «bfo: ИсполняемаяСущность» — то, что проявляется в объекте в результате какого-то процесса, в данном случае — участия запчасти в определенной работе.

В работе [7] содержатся описания приемов построения онтологической модели, а также готовые подходы к моделированию некоторых видов корпоративной информации.

***

Онтологическая модель — это прослойка между данными и приложениями, обеспечивающая бизнес-процессам доступность данных из различных источников благодаря гибкости и масштабируемости. Возможности онтологической модели в составе логической витрины данных, применяемой при переходе к дата-центричной архитектуре, иллюстрирует проект компании РОЛЬФ, где в процессе внедрения онтологической модели была проведена полная структуризация данных и настроены связи между различными типами данных (классами в онтологии), в результате бизнес-пользователям стали видны отношения работ и запчастей к автомобилям. Кроме этого, удаление дубликатов привело к сокращению времени на поиск запчастей. Аналогичную прослойку можно собрать из разнородных компонентов, однако в этом случае стыки между компонентами будут реализованы программно и любое изменение этой конструкции будет болезненным — изменение одного элемента повлечет изменения других частей системы. Онтология, как единое хранилище структуры и логики обработки данных, отодвигает на второй план детали реализации — если в процессе эволюции меняются компоненты системы и атрибутивный состав сущностей, то изменения коснутся только семантической модели. Благодаря тому, что изменения в соответствии с бизнес-требованиями вносятся в основном в модель, а не в программный код, снижается зависимость от конкретных программных компонентов и появляется единая точка управления данными и процессами их сбора, обработки и использования.

Литература

1. Сергей Горшков. Три шага к дата-центричной архитектуре // Открытые системы. СУБД. — 2019. — № 4. — С. 26–29. URL: https://www.osp.ru/os/2019/04/13055224 (дата обращения: 11.09.2023).

2. World Wide Web Consortium (W3C): https://www.w3.org/.

3. Idehen K. U. Semantic Web Layer Cake Tweak, Explained. 2017. URL: https://medium.com/openlink-software-blog/semantic-web-layer-cake-tweak-explained-6ba5c6ac3fab (дата обращения: 11.08.2023).

4. Сергей Горшков. Единая точка доступа к данным предприятия // Открытые системы. СУБД. — 2018. — № 4. — С. 33–35. URL: https://www.osp.ru/os/2018/04/13054596 (дата обращения: 20.03.2022).

5. Peroni S. Graffoo Specification. 2013. URL: https://essepuntato.it/graffoo/specification/ (дата обращения: 11.08.2023).

6. Arp R., Smith B., Spear A. D. Building Ontologies with Basic Formal Ontology. 2015. 220 с.

7. Беглер А., Шебалов Р. Руководство по созданию и поддержке семантической модели. 2022. 49 с. URL: https://trinidata.ru/files/SemanticModelDesign.pdf (дата обращения: 11.08.2023).

Алена Беглер (begler@trinidata.ru) — аналитик, Константин Кондратьев (kondratiev@trinidata.ru) — директор, компания «ТриниДата» (Екатеринбург).

Статья подготовлена на основе материалов выступления на форуме «Управление данными 2023».

DOI: 10.51793/OS.2023.97.80.003