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

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

Принципиально новая архитектура, свободная от данных проблем, должна быть построена на следующих принципах [1]:

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

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

Путь к дата-центричной архитектуре

На практике переход к архитектуре, ориентированной на данные, предполагает выполнение ряда шагов.

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

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

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

Третий шаг. Развитие возможностей управления поведением приложений нового типа со стороны модели. Такие приложения не просто ориентированы на работу с гибкой моделью данных, но и часть описания алгоритмов их работы также находится в онтологии. Допустим, в результате изменения бизнес-требований необходимо создать новый вид бизнес-объектов и описать процедуры работы с ним. Аналитик создает в онтологической модели класс, объектами которого станут информационные объекты, представляющие бизнес-объекты нового вида. Этот класс помещается в определенное место в иерархии классов — к его объектам будут применимы все атрибуты, применимые к вышестоящим классам. Например, если новый класс «Трансформатор» станет подклассом класса «Устройства преобразования напряжения», его объекты будут обладать атрибутами «Верхнее напряжение» и «Нижнее напряжение». Новый класс «Снятие показаний приборов учета» станет подклассом «Событие» и приобретет атрибут «Дата и время». Кроме того, к новому классу будут применимы все алгоритмы и настройки, уже существующие в модели для вышестоящих классов. Во многих случаях этого вполне достаточно, чтобы система начала работать с новым типом бизнес-объектов без дополнительных настроек. Если для новых бизнес-объектов требуются особые правила обработки, аналитик может определить их в модели. Правила могут описываться разными способами: с помощью специальных метамоделей, таких как модели правил отображения данных или построения отчетности; с помощью правил логического вывода, которые лучше подходят для формализации алгоритмов с ветвлением и выполнением форматно-логических проверок.

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

Платформа «АрхиГраф»

Платформа «АрхиГраф» предназначена для создания логической витрины данных и построения кластера физического хранения информации под управлением онтологической модели. Главная идея платформы состоит в объединении всей корпоративной информации в рамках одной или нескольких онтологических моделей. Основным хранилищем подобных моделей являются графовые базы данных класса RDF triple store, обеспечивающие богатые возможности поиска по графам и управления ими при помощи языка SPARQL. Однако такие СУБД довольно медленны и не предназначены для хранения больших объемов данных. С другой стороны, традиционные средства, такие как реляционные и документоориентированные СУБД, обеспечивают быструю обработку больших объемов информации за счет развитых инструментов оптимизации, включая индексацию и сегментацию таблиц и коллекций объектов. Требуется промежуточный слой физического хранения данных в реляционных базах данных и NoSQL-базах, которые с точки зрения приложений выглядели бы как графовые СУБД. Это позволит совместно использовать преимущества способов управления данными, целостности структуры и состава данных, характерные для онтологий и графовых СУБД, с совершенными механизмами оптимизации производительности традиционных хранилищ.

Рис. 1. Структура платформы «АрхиГраф»

В платформе «АрхиГраф» имеется промежуточный слой (рис. 1), позволяющий распределить данные между множеством кластеров реляционных и NoSQL СУБД, а также хранилищ Hadoop, управлять их распределением и применять различные способы оптимизации скорости доступа к данным. Доступ к данным со стороны приложений осуществляется через программные интерфейсы REST, SPARQL, GraphQL, очереди обмена сообщениями RabbitMQ, Kafka, с помощью протокола Websocket.

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

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

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

Как и в любой развитой системе работы с данными, в платформе имеются средства ведения журналов запросов для просмотра администратором; фиксируется история модели и хранения данных, что позволяет отследить состояние модели и информационных объектов в любой момент времени; предусмотрена подача заявок на внесение изменений в информационные объекты; возможна подписка на уведомления о создании или изменении информационных объектов через очереди MQ или Kafka.

Рис. 2. Кластеризация платформы «АрхиГраф» и хранилищ данных

Сервисы «АрхиГраф» выполняются в контейнерах под управлением Kubernetes, что обеспечивает практически неограниченное масштабирование при росте нагрузки (рис. 2). Хранилища данных могут также кластеризоваться с помощью своих собственных средств, таких как pgpool или Stolon для СУБД Postgres, причем к платформе «АрхиГраф» можно подключить любое количество подобных кластеров.

Несколько кластеров могут размещаться в различных территориально распределенных ЦОД, а для управляемой синхронизации данных используются специальные механизмы синхронизации через подписки: можно указать, какие данные должны синхронизироваться, а какие — оставаться оригинальными в пределах каждого кластера.

Сценарии использования

Платформа «АрхиГраф» используется сегодня в ряде проектов: в системе построения корпоративной отчетности, системе информационного обмена между несколькими субъектами энергетического рынка, системе консолидации корпоративных знаний. Опишем один из сценариев использования платформы для построения логической витрины данных как первого шага на пути к дата-центричной архитектуре.

Рис. 3. Процесс сбора и анализа информации в логической витрине данных

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

Три шага к дата-центричной архитектуре

Рис. 4. Конвейер обработки событийных данных, поступающих в систему

В качестве примера другого сценария можно привести конвейер по связыванию разнородной событийной информации, поступающей из разных источников (рис. 4), — такие задачи возникают в системах информационного обмена или сбора отчетности, а также в ситуационных центрах. Для обработки разнообразных потоков данных создаются компоненты, в реальном времени собирающие данные от источников и преобразующие их в соответствии с информационной моделью при помощи специальной метамодели, которая описывает соответствие элементов разных информационных структур. Такая метамодель позволяет определить широкий спектр преобразований — от разбора JSON-коллекций и XML-файлов до импорта таблицы Excel. После получения графа с набором информационных объектов и их свойств, поступивших в составе обрабатываемого сообщения, к нему применяются правила валидации, записываемые в синтаксисе SHACL (Shapes Constraint Language). После этого нужно применить следующий набор правил, которые обновят общесистемное хранилище данных в соответствии с поступившей информацией, — здесь также используется SHACL. Использование логически корректных правил позволяет гарантировать логическую целостность и корректность информации в общесистемном графе.

***

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

Литература

1. Data-Centric Manifesto. URL: http://datacentricmanifesto.org/principles/ (дата обращения: 05.12.2019).

2. Dave McComb. The Data-Centric Revolution: Restoring Sanity to Enterprise Information Systems. O'Reilly, 2019.

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

Сергей Горшков (serge@trinidata.ru) — директор, компания «ТриниДата» (Екатеринбург). Статья подготовлена на основе материалов выступления на форуме «Управление данными — 2019».