Успех эксплуатации любого продукта корпоративного уровня, способного на протяжении продолжительного времени работать на предприятиях, во многом зависит от его архитектуры. Это особенно актуально для систем, отвечающих за управление основными данными предприятия. Универсальная платформа для создания таких систем должна, с одной стороны, обеспечивать настройку для работы с данными на конкретным предприятии, а с другой, быть независимой от специфики прикладной отрасли, сферы применения построенного на ее основе продукта и его информационного окружения. Ясно, что для платформы важны все детали — от выбора языка разработки и базового стека технологий до организации корпоративных систем хранения данных и механизма обеспечения ее постоянного развития с целью масштабирования и учета вновь возникающих нормативных требований, например GDPR. Универсальная платформа для создания систем управления данными должна удовлетворять следующим требованиям:

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

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

Одна из таких универсальных платформ для построения систем управления корпоративными данными — «Юнидата» (рис. 1), предоставляющая инструменты создания модели данных и средства расширения функционала при интеграции в различные ИТ-ландшафты: от ведения материально-технических ресурсов до безопасной обработки больших объемов персональных данных.

Рис. 1. Архитектура платформы «Юнидата»

Ядро платформы построено в соответствии с концепцией управления основными данными предприятия (Master Data Management, MDM) и отвечает за хранение всех данных о «золотых» записях и ведение истории изменений. Это означает совмещение процессов и инструментов поддержки качества, полноты, целостности и актуальности данных предприятия (сведения о клиентах, продуктах, поставщиках, сотрудниках и т. п.), загружаемых из различных корпоративных информационных систем. Интерфейс можно расширить путем разработки собственных методов — например, когда необходимо написать композитный запрос, чтобы сократить нагрузку на источник данных.

Ядро окружают следующие модули: RDM (Reference Data Management) — управление статичными, редко меняющимися или внешними данными; BG (Business Glossary) — описание бизнес-терминов с поддержкой открытого технического словаря (ECCMA Open Technical Dictionar, eOTD) и специфических для различных отраслей вариантов реализации словарей; DL (Data Lineage) — визуализация всех потоков данных и связанных с ними процессов от источников данных к их потребителям; BRMS (Business Rule Management System) — настройка процессов автоматического принятия решений на основе входных параметров и модели с целью устранения дублей, поиска, создания и редактирования данных; CS (Classification Schemes) — ведение онтологии данных предприятия на базе иерархических классификаторов; MM (Metadata Management) — управление структурами данных источников и получателей в соответствии с моделью данных в MDM; PUB SUB (Publish and Subscribe) — взаимодействие платформы с внешними системами; BPM (Business Process Management) — управление бизнес-процессами, предусматривающими участие человека; DQ (Data Quality) — обеспечение качества данных (исправление ошибок, обогащение из внешних источников, устранение дублей и пр.).

Универсальность продуктов, создаваемых на базе платформы, обеспечивается благодаря средствам создания моделей данных предприятия. При этом используются: реестры — записи, содержащие динамично изменяющиеся основные данные предприятия; справочники — записи с условно-постоянной информацией простой структуры (нормативно-справочная информация, НСИ); атрибуты — поля записи; связи — взаимосвязь между записями различных реестров; источники/получатели — системы, поставляющие или получающие данные; классификаторы — иерархические справочники с динамическим набором атрибутов и правилами наследования.

Взаимодействие платформы с внешним миром осуществляется по стандартным протоколам: SOAP API — основной интерфейс, контракты которого описаны c помощью WSDL/XSD; REST API — дополнительный интерфейс, используемый для расширения функционала и поддержки пользовательского интерфейса; JMS — средства интеграции с очередями сообщений, например Rabbit MQ, Apache ActiveMQ; LDAP — идентификация, аутентификация и авторизация пользователей при интеграции с доменной системой управления, например Kerberos или Windows AD.

Технологический стек платформы построен на базе открытого ПО, подразумевающего свободные лицензии на компоненты, не ограничивающие их коммерческое использование (MIT, Apache, GPL); жизнеспособность компонента, который должен развиваться, а его распространение должно иметь понятную политику поддержки (возможно, платную); популярность компонента в ИТ-сообществе, способствующую снижению затрат на сопровождение, документацию и сроки внедрения. Платформа построена на базе следующих технологических компонентов: Tomcat — контейнер сервлетов c открытым исходным кодом от Apache, обеспечивающий безопасность передачи данных с помощью поддержки сертификатов SSL; PostgreSQL — реляционная СУБД для хранения больших массивов данных на схеме, не зависящей от модели данных и с возможностью использования в других SQL-базах; Elasticsearch — поисковый движок, обеспечивающий требуемую скорость поиска в больших массивах данных и обнаружения дублей. Для разработки Java-приложения используется стандартный стек технологий: Spring — управление зависимостями, HazelCast — распределенный кэш, для кластерной конфигурации, Apache-библиотеки.

Компоненты имеют интерфейсы для внедрения в систему мониторинга на крупных предприятиях, такую как Zabbix. Разворачивание всех компонентов платформы может быть реализовано с помощью таких популярных инструментов, как контейнеры Docker и система автоматизации развертывания Kubernetes. Помимо этого, в реальной жизни может возникать множество нестандартных запросов — например, интеграция с почтовыми серверами или массовые рассылки информации об изменениях, для выполнения которых возможностей стандартных интерфейсов недостаточно. Здесь может использоваться Java-фреймворк Apache Camel, основанный на стандартных шаблонах взаимодействия корпоративных приложений (Messaging Bridge, Message Bus, Message Broker и т. п.).

В качестве примера создания системы управления данными на базе платформы «Юнидата» можно рассмотреть решение для поставщика телекоммуникационного оборудования, имеющего свой набор информационных систем с уникальными маршрутами потоков данных между ними. Зачастую данные в каждом отделе хранятся и ведутся по собственным стандартам и с использованием различных технологий, а между собой они связаны лишь номерами типов поставляемого оборудования конкретному заказчику. Связка клиент-заказ-наряд в масштабе всего предприятия отсутствует — каждый отдел хранит данные, нужные именно ему, что порождает дублирование, потерю синхронизации и риск утечки персональных данных. Несмотря на уникальную структуру и потоки данных, на уровне системы управления данными архитектура решения здесь унифицирована, что и позволяет применить платформу «Юнидата». На рис. 2 приведен пример информационных потоков при доставке оборудования заказчикам: база клиентов ведется в отделе продаж, имеет SQL-интерфейс; система выполнения заказов в отделе логистики имеет доступ через REST-интерфейс.

Рис. 2. Пример решения на платформе «Юнидата»

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

***

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

Роман Стрекаловский (roman.strekalovskiy@unidata-platform.ru) — ведущий архитектор, компания «Юнидата». Статья подготовлена на основе материалов выступления на форуме «Управление данными — 2019» и конференции «Качество данных — 2020».