В больших проектах, которые объединяют множество компонентов, нередко возникают проблемы унификации подходов и понимания связей между всеми сервисами. В результате долгое время у ИТ-команд существовал запрос на новую модель описания структуры данных и семантики приложения. Она появилась благодаря адаптации онтологии под нужны ИТ.
Меня зовут Алексей Гуляев. Я архитектор решений в команде VK Tech. В этой статье я расскажу об онтологии в ИТ, вариантах ее использования и нашем кейсе применения онтологического подхода для решения внутренней задачи.
Сначала о проблеме: об основных вызовах для разработчиков в контексте работы со сложной структурой приложений
Современные приложения, как правило, состоят из множества сервисов и компонентов — это повышает удобство администрирования и отказоустойчивость, а также упрощает масштабирование. Вместе с тем, это создает и некоторые трудности. Например, даже одинаковые сущности, используемые в разных компонентах, могут иметь разные названия и неочевидные взаимосвязи: допустим, не всегда понятно, «Клиент» из CRM, это тот же «Пользователь» из Auth или нет? И чем больше компонентов задействовано в приложении, тем выше риск возникновения таких недопониманий и связанных с этим проблем.
Чтобы избавиться от подобных сложностей, с которыми сталкиваются многие разработчики, важно сформировать явное представление о терминах, связях, структуре данных и семантике приложения.
Для этого можно задействовать принципы онтологии.
Чем могут быть полезны принципы онтологии в ИТ
Классически под «онтологией» понимают систематическое представление знаний определенной области в виде понятий, отношений между ними и правил вывода. Но этот термин вполне можно адаптировать под ИТ. Так, в разработке онтологию можно рассматривать как формальную спецификацию понятий и связей между ними, используемую для описания структуры данных и семантики приложений. Если проще — в ИТ онтология помогает превратить бизнес-логику в машиночитаемый код.
Чтобы понять, как это работает, рассмотрим несколько примеров.
Аналогия 1: Справочник++
Принципы онтологии можно применять в справочниках, причем не для простого описания терминов, а для формального описания предметной области, которое позволит преобразовать бизнес-правила в код.
Например, для решения бизнес-задачи нам важно, чтобы выполнялось три правила:
все клиенты — пользователи;
клиент должен иметь хотя бы один заказ;
заказ всегда содержит хотя бы один товар.
В онтологии в синтаксисте TURTLE эти правила можно описать всего несколькими строками кода.
Примечание: TURTLE (Terse RDF Triple Language) — лаконичный синтаксис для представления RDF-данных (Resource Description Framework), разработанный специально для удобства написания и чтения RDF-триплетов вручную. Формат широко используется в проектах, ориентированных на разработку онтологий и семантических сетей.
:Client a owl:Class ;
rdfs:label "Клиент" ;
rdfs:subClassOf :User ; # Все клиенты - пользователи
# Клиент ДОЛЖЕН иметь хотя бы один заказ
rdfs:subClassOf [
a owl:Restriction ;
owl:onProperty :hasOrder ;
owl:someValuesFrom :Order ;
owl:minCardinality "1"^^xsd:nonNegativeInteger
] .
:Order a owl:Class ;
rdfs:label "Заказ" ;
# Заказ ДОЛЖЕН содержать хотя бы один товар
rdfs:subClassOf [
a owl:Restriction ;
owl:onProperty :containsItem ;
owl:someValuesFrom :Product ;
owl:minCardinality "1"^^xsd:nonNegativeInteger
] .Здесь видно, что:
класс — «Client» является подклассом «User»;
есть дополнительное ограничение: — клиент должен быть связан хотя бы с одним объектом (owl:minCardinality "1"^^xsd:nonNegativeInteger).
Примечание: С заказом аналогично — должна быть связь минимум с одним товаром.
Таким образом, онтология позволяет выстроить не просто словарь, а исполняемую спецификацию, которая будет понятна и компьютеру, и человеку.
Аналогия 2: ООП на стероидах
Онтология позволяет описывать классы, экземпляры классов и их свойства.
Помимо этого, она позволяет определять и более сложные связи, например, принадлежность к конкретной категории.
Разберем на примере. Допустим, у нас есть три индивида:
Иван;
Марина;
Петр.
Изначально задана связь типа «Родитель»: Иван — родитель Марины, а Марина — родитель Петра.
Соответственно, при построении онтологии в синтаксисе мы указываем, что:
никто не может быть своим собственным родителем;
если А родитель В, то В не может быть родителем А.
:hasParent a owl:ObjectProperty ;
rdfs:label "имеет родителя" ;
rdfs:domain :Person ;
rdfs:range :Person ;
owl:irreflexive true ; # Никто не может быть своим собственным родителем
owl:asymmetric true . # Если А родитель В, то В не может быть родителем АСюда же мы можем добавить и дополнительную связь. Например, «Предок». Причем можно задействовать свойство транзитивности, которое позволяет автоматически распространять правило на все последующие сущности.
:hasAncestor a owl:ObjectProperty ;
rdfs:label "имеет предка" ;
rdfs:domain :Person ;
rdfs:range :Person ;
owl:transitive true ; # Ключевое свойство: если А предок В, а В предок С, то А предок С
owl:irreflexive true . # Никто не может быть своим собственным предкомТо есть связь «Предок» (Иван предок Петра) будет автоматически построена онтологической моделью если в модели будет указано что Иван предок Марины, а Марина предок Петра.
Аналогия 3: Схема БД++
Реляционный подход позволяет описать все сущности и даже связи между ними, что успешно используется в реляционных базах данных.
Вместе с тем, в подобной структуре разбираться с классами, их наследованием и другими связями не всегда удобно.
При построении графа онтологии это становится значительно проще и нагляднее. Причем в таком случае даже связи («один к одному», «один ко многим», «многие ко многим») будут нести дополнительную нагрузку в части описания структуры данных и приложения.
Одним из важных преимуществ онтологии в контексте БД является и механизм наследования сабклассов. Рассмотрим, как именно это работает, на примере DDL (Data Definition Language) — части SQL, предназначенной для управления структурой данных в БД.
Допустим, у нас есть 3 таблицы в DDL. Разобраться в такой структуре можно, но не всегда просто без глубокого погружения.
CREATE TABLE users (
id SERIAL PRIMARY KEY
);
CREATE TABLE user_roles (
id SERIAL PRIMARY KEY,
user_id INTEGER REFERENCES users(id),
role_type VARCHAR(20) NOT NULL CHECK (role_type IN ('customer', 'employee', 'supplier')),
UNIQUE(user_id, role_type)
);
CREATE TABLE orders (
id SERIAL PRIMARY KEY,
customer_id INTEGER REFERENCES users(id),
assigned_employee_id INTEGER REFERENCES users(id)
);В онтологии всё значительно прозрачнее и очевиднее. Так:
добавляем класс "User" — пользователь;
объявляем класс "Customer", который является наследником пользователя;
добавляем ограничение, согласно которому пользователь становится клиентом только в том случае, если сделал хотя бы один заказ.
:User rdf:type owl:Class ;
rdfs:label "Пользователь" .
:Customer rdf:type owl:Class ;
rdfs:subClassOf :User ,
[ rdf:type owl:Restriction ;
owl:onProperty :createdOrder ;
owl:someValuesFrom :Order ] ;
rdfs:label "Клиент" .
:createdOrder rdf:type owl:ObjectProperty ;
rdfs:domain :Customer ;
rdfs:range :Order ;
rdfs:label "Создал заказ" .Основное отличие SQL-кода от онтологии в данном случае заключается в том, что код SQL указывает то, как именно данные сохраняются, а онтология — описывает характер данных и их связи.
Ключевые элементы
Таким образом, онтология базируется на нескольких ключевых сущностях, к которым относят:
классы (Concepts) (например, "User");
экземпляры (индивиды) (например, "Ivanov_Ivan");
-
свойства:
атрибуты (Data Properties), к которым относятся простые значения: строки, числа и другие (например, e-mail);
отношения (Object Properties), которые описывают связь одного индивида с другим (например, hasOrder);
отношения между классами.
Когда онтологический подход может быть полезен
Применение онтологического подхода упрощает решение нескольких важных технических и бизнесовых задач.
Борьба с «Вавилонской Башней» и упрощение интеграции. Онтологический подход позволяет упорядочить и сформировать понятную структуру данных и всех используемых сервисов. Благодаря этому не только легче понимать всё, что происходит в проекте, но и проще интегрировать новые компоненты, налаживая с ними требуемые связи.
Валидация. Онтология и онтологический подход помогают в валидации, задавая чёткую структуру данных и строгие правила их взаимодействия. Онтология определяет классы объектов, их свойства и связи, а также устанавливает обязательные условия и ограничения. Специальные инструменты, называемые резонерами, автоматически проверяют соблюдение этих правил, исключают противоречия и ошибки, обеспечивая целостность и правильность данных.
Шаг к «умным» данным. Онтология добавляет к данным смысловые связи и контекст. Это позволяет компьютерам лучше понимать содержание и применять более прогрессивные интеллектуальные методы анализа и автоматизацию.
Форматы и инструменты
Работу с онтологией можно упрощенно выстроить на использовании нескольких инструментов и технологий.
Для представления классически используется RDF (Resource Description Framework) — универсальный стандарт представления данных, применяемый для работы с онтологиями. Он используется для описания ресурсов и их свойств в форме простых утверждений («триплетов»), состоящих из трех элементов: субъект, предикат и объект.
В качестве основного языка применяется OWL (Web Ontology Language) — язык разметки для построения и описания онтологий, который разработан специально для формализации знаний и стандартов их представления в рамках Семантического Веба (Semantic Web).
При этом хранить онтологию можно любым удобным способом. Например, для этого подойдут:
триплсторы (Triplestores) — например, GraphDB, Stardog, которые созданы специально для RDF/OWL и умеют в логический вывод;
Apache Jena, которая позволяет выполнять SPARQL запросы по протоколу HTTP, поэтому дает возможность балансировать нагрузку стандартными средствами (nginx);
любые базы данных, в том числе PostgreSQL.
Пример применения онтологии для решения задачи: построение портала данных бизнеса
Теперь перейдем от теории к практике. Рассмотрим прикладную задачу, ради которой мы изначально и начали изучать онтологический подход.
Так, у нас был проект, в рамках которого нужно было организовать хранение и публикацию данных показателей в рамках отчетных кампаний, где данные показателя хранятся в кубах. При этом модель данных бизнеса формулируется на стороне и поступает к нам в виде набора правил, по которым осуществляется хранение, публикация и версионирование данных.
Упрощенная модель, которую мы использовали на этапе MVP, имела примерно следующий вид:
Изначально мы пытались решить поставленную задачу с помощью реляционного подхода, но столкнулись с проблемами, которые для нас оказались критическими. Среди них:
Много промежуточных таблиц для связей M:M (many to many), соответственно, было много запросов с обилием вложенных JOIN’ов.
Для работы каждому участнику требуется погружаться как в предметную область, так и в схему данных, что было проблематично из-за сложности самой реализации.
Путь от изменений модели данных на стороне бизнеса до реализации модели в схеме БД стоил очень дорого, поскольку требовалось вносить много изменений, пересобирать миграции и выполнять еще большой пул смежных задач.
Для поставки правил формирования отчетности из внешнего источника нам фактически пришлось придумать свой формат EMBD с поддержкой версионности, что обычно просто избыточно.
Именно поэтому мы перешли к онтологии и применили гибридный подход, при котором:
Онтология для Портала Данных Бизнеса в Apache Jena представлена в виде внешнего справочника — артефакта, поставляемого в виде файла формата turtle, который становится контрактом между бизнесом и разработкой.
Значения куба хранятся отдельно в Postgres, что позволяет не перегружать онтологию.
Благодаря такой реализации мы решили сразу несколько задач:
развязали сложную предметную модель и данные;
получили возможность использовать хорошо документированный и известный синтаксис EMBD, а не самописный «велосипед»;
значительно упростили создание редактора;
получили возможность применять нейросети для решения различных бизнес-задач на основе онтологии.
В результате у нас получился граф онтологии, который упрощенно (его часть) выглядит примерно следующим образом:
И для работы с таким графом онтологии (напоминаю, что выше показана только его часть) можно применять довольно простые запросы. Например:
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX emdb: <http://odb.b2gcomm.taxmon.ru/onto/1.0/emdb.owl#>
SELECT
?cp
?Code
?DisplayName
?ProvisionTerms
WHERE {
emdb:1_I_F164272 emdb:r_I_2 CP ?cp .
?cp emdb:r_CP_2_DictCPV ?cpv .
?cp emdb:ProvisionTerms ?ProvisionTerms .
?cpv emdb:Code ?Code .
?cpv emdb:DisplayName ?DisplayName .
}
ORDER BY ?CodeЭтот запрос мы отправляем постом в Apache Jena, после чего она дает ответ из запрошенной онтологической модели.
Библиотеки для нашего стека
Мы оценили эффективность и удобство онтологического подхода. Поэтому в перспективе планируем всё активнее применять его в своих процессах. Так, мы уже определили для себя оптимальный набор библиотек под разные решения в свой стек.
Python. Для Python мы выбрали RDFLib — библиотеку для языка программирования Python, предназначенную для работы с ресурсными описаниями формата RDF согласно спецификациям W3C. Она позволяет создавать, читать, изменять и сохранять RDF-графики и файлы, поддерживая множество форматов сериализации RDF (например, RDF/XML, N-Triples, JSON-LD).
Golang. В Golang можно задействовать базовый RDF — стандартный способ представления данных в виде набора троек («субъект-предикат-объект»), широко применяемый в семантическом вебе для описания ресурсов и связей между ними. Помимо этого, для работы с онтологией можно применить JSON-GOLD (Graph Object Linked Data) — расширение стандарта JSON, которое объединяет преимущества формата JSON с возможностями семантического веба и связывания данных RDF (Resource Description Framework).
PostgreSQL. Для работы с данными PostgreSQL подойдет JSONB, который представляет собой эффективный механизм для хранения и обработки данных в формате JSON. Однако в контексте работы с онтологиями этот тип данных приобретает особое значение, поскольку он позволяет хранить и манипулировать данными в полуструктурированном формате, идеально подходящем для задач моделирования знаний и семантического анализа. Также можно задействовать триплет-таблицы — например, делать JOIN'ы по subject и object, а для обхода графа использовать рекурсивные CTE (WITH RECURSIVE).
Apache Jena. В случае Apache Jena всё довольно просто — файлы онтологий загружаются в Jena и выполняются запросы SPARQL по HTTP.
Что в итоге
Онтологический подход — вполне эффективное решение, которое можно применять во многих сценариях. Так, его можно рассмотреть, если у вас в проекте:
сложная предметная область со множеством связей;
часто меняющиеся требования к данным;
проблемы интеграции множества источников;
нужен более «умный» поиск или важна гибкость модели;
требуется, чтобы данные «понимались» приложением на более глубоком уровне.
Но есть и ограничения. Например, онтология — не лучший вариант, когда:
модель данных очень проста (CRUD над парой таблиц);
критична сверхвысокая производительность;
команда абсолютно не готова к восприятию новой парадигмы.
При этом, мы уже начинаем применять подход для решения части наших задач. О том, что из этого получится — обязательно расскажем в одной из следующих статей.
А вы пробовали онтологию в своих проектах? Делитесь опытом.