Всем привет! На связи Александр Киваев, руководитель направления департамента управления справочной информацией в команде управления данными «Ростелекома». Если у вас в компании внедрена и эффективно работает MDM система, то считайте, что вы сорвали джэк-пот, потому что это значительно облегчит вам процесс внедрения новых информационных систем в IT инфраструктуру компании, упростит и удешевит интеграцию имеющихся систем, и позволит вам создавать качественную аналитическую и управленческую отчетность, сократив при этом время на обработку, актуализацию и верификацию данных.
Именно эти преимущества мотивируют крупные компании внедрять MDM-решения. В этой статье мы хотим рассказать об опыте внедрения системы управления мастер-данными Ростелекома, о том с какими сложностями мы столкнулись и какими способами нам удалось их решить.
MDM из коробки
В качестве основного решения для построения системы управления мастер данными мы выбрали Microsoft Master Data Services (MDS). MDS доступна для предприятий, использующих Microsoft SQL Server Enterprise Edition, начиная с версии 2014 года. MDS входит в комплект поставки и не требует дополнительных затрат на лицензирование, что стало одним из определяющих факторов выбора в пользу данного продукта.
Но вместе с получением развитой функциональности из коробки мы столкнулись с концептуальным ограничением. Дело в том, что специализированные MDM-решения построены в философии, когда система автоматизирует все аспекты процесса управления данными и является «авторитетным» источником мастер-данных для всех систем масштаба предприятия. Вместе с тем ситуация, когда MDM-система является единственным источником мастер-данных, все изменения вносятся в MDM-систему и только потом передаются в системы-потребители, это идеальная ситуация, и в реальной жизни встречается крайне редко.
Проблемы… Системы…
В Ростелекоме есть множество информационных систем и каждая из них решает свою специфическую задачу. Это могут быть как биллинги, ERP, CRM, так и совсем специфические решения.
Положение усугубляется тем, что информационные системы разрабатывали разные люди в разное время и каждый решал локальную специфическую задачу, основываясь лишь на своём понимании эффективного решения. В результате, компания Ростелеком получила разрозненные информационные системы, которые иногда не совместимы между собой. Кроме того, бизнес-процессы компании построены таким образом, что операционные системы часто сами являются источниками мастер-данных, и архитектура этих систем не позволяет переключиться на другой режим работы без значительного ухудшения процессов продаж и обслуживания клиентов.
Перед нами стояла задача каким-то способом извлечь данные из всего этого многообразия ИТ-систем, привести к единому виду и дать возможность эффективного построения аналитической отчетности, и вместе с тем не ухудшить показатели операционных процессов компании.
Требования к системе Master Data Management
Для решения наших задач нам требовалась система, которая бы предоставила средства управления справочниками, получаемыми из всех имеющихся информационных систем, и попутно позволила бы привести все справочники к единому формату. После такой обработки стало бы возможным использовать единые средства интерпретации и анализа данных.
Мы видели для себя следующий сценарий использования MDM системы:
Подготовить эталонные корпоративные справочники.
Получить данные справочников из информационных систем предприятия, которые в этом случае называются системами-источниками. Для этого можно использовать какое-либо средство из Extract Transfom Load (ETL). Помещаем полученные данные в слой, который назовём Landing.
Трансформировать данные в общий формат. Для этого выполняем приведение типов к типам данных принятым в системе MDM. Полученный результат помещаем в слой, который назовем Staging.
Перевести данные из слоя Staging в слой готовых справочников.
Установить соответствие записей, полученных от систем-источников на записи эталонных справочников. Такое действие называется мэппингом.
Предоставить системам-потребителям средства для получения данных из эталонных справочников и мэппингов.
Такой подход позволил бы получить возможность применять справочники MDM в качестве показателей, на основе которых можно строить корпоративные отчёты и витрины BI, а также дал бы возможность информационным системам компании использовать единые выверенные и гарантированно достоверные справочники в качестве эталонных значений.
Ограничения Microsoft MDS
Microsoft MDS по своим функциям не соответствует сценарию, приведенному выше. По своей сути, MDS представляет собой хоть и удобное, но лишь средство ведения справочников. Производителем подразумевается, что специалисты по корпоративным справочникам будут создавать эталонные справочники и наполнять их значениями. После этого они будут использоваться любой другой корпоративной информационной системой.
Исходя из вышесказанного, получается, что система Master Data Services решает только два пункта из приведенного выше сценария:
Ведение эталонных справочников.
Предоставление системам-потребителям средств для получения справочников.
Мы в своей работе решили использовать систему MDS, так как она была доступна без дополнительных вложений. Вместе с тем, мы дополнили её недостающими функциями, чтобы получить решение, полностью соответствующее типичному сценарию MDM.
Доработка MDS до полноценной MDM
По условиям лицензионного соглашения пользователю запрещено вносить какие-либо изменения в программный продукт MDS, но всегда есть технический способ дополнить функции стандартного решения, не затрагивая его самого, что нами и было проделано. Доработка свелась к последовательности действий:
Была создана отдельная база данных, которая выполняла функцию слоя Landing. В таблицы этой базы средствами стандартного ETL мы поместили данные справочников, полученные из систем-источников. Для каждого справочника каждого источника была подготовлена своя таблица.
В этой базе данных мы создали хранимые процедуры, которые запускаются после получения справочников из систем-источников. Хранимые процедуры выполняют выделение инкремента и помещение его из слоя Landing в стандартный слой Staging MDS (в базе данных MDS, это схема данных stg). Кроме того, хранимая процедура может выполнять автоматический мэппинг новых или измененных записей системы-источника на эталонный справочник.
Далее в хранимой процедуре мы реализовали вызов оригинальной хранимой процедуры MDS, которая переносит все данные из слоя Staging в справочник MDS.
Схема передачи данных между слоями:
В результате этих несложных действий мы получили функциональность полноценной системы MDM, вполне соответствующую типичному сценарию.
Как мы это сделали
Схема взаимодействия MDS с информационными системами компании
Для наглядности предлагаем общую картину информационных потоков между системами-источниками и MDS, между MDS и системами-потребителями:
В приведенной схеме:
Системы-источники – это все информационные системы, из которых выполняется передача данных в MDS;
Нормативно справочная информация – это система MDS;
Системы-потребители – это все информационные системы, которые получают данные от MDS.
Справочники MDS
Справочник, который мы считаем эталонным, это обычный справочник MDS, с которым работают пользователи, добавляя или изменяя записи.
Справочник, полученный от системы-источника, мы тоже считаем обычным, но с одним отличием – он имеет так называемый мэппинг на эталонный справочник, то есть ссылку на запись другого справочника. В MDS ссылка указывается в свойствах атрибута справочника – следует указать справочник, который мы считаем эталонным. Для этого атрибут должен иметь тип «На основе домена».
Следует отметить, что мы разрешили пользователям изменять только один атрибут в справочнике источника – это атрибут ссылки на эталон. Этому ограничению есть важная причина: мы должны быть уверены, что записи справочника в источнике и его копии в MDS идентичны.
Экран MDS, где устанавливается ссылка атрибута на эталонных справочник:
Таблицы базы данных слоя Landing
Слой Landing не предназначен для хранения, его функция промежуточная – получить данные от системы-источника и затем выделить инкремент относительно того, что уже находится в справочнике.
Предположим, что мы имеем эталонный справочник «Услуги», сущность называется Service. И имеем справочник услуг, полученный от системы-источника, пусть эта сущность называется SERVICE_000085.
Тогда в слое Landing мы создаем два объекта баз данных:
Таблицу lnd.SERVICE_000085;
Хранимую процедуру lnd.Load_SERVICE_000085.
В таблице создаем поля, соответствующие полям справочника в источнике и нашему эталонному справочнику:
CREATE TABLE lnd.SERVICE_000085(
code nvarchar(250) NOT NULL,
Name nvarchar(250) NOT NULL,
business_service_key nvarchar(250) NULL,
technology_type_key nvarchar(250) NULL,
access_service_type_key nvarchar(250) NULL,
[service_type_key nvarchar(250) NULL
)В хранимой процедуре пишем программный код:
CREATE PROCEDURE lnd.Load_SERVICE_000085
AS
BEGIN
--Подготовка уникального имени пакета BatchTag
declare @SourceSystem varchar(50) = 'SERVICE_000085' + '_' + getdate()
--Выполнение сравнения со справочником для выборки новых записей, полученных от системы-источника. Для сравнения используем представление справочника mdm.SERVICE_000085_V предварительно подготовленное в разделе MDS «Управление интеграцией».
--Помещение выбранного в таблицу слоя Staging.
insert into stg.SERVICE_M_000085_Leaf
(
ImportType
, ImportStatus_ID
, BatchTag
, Code
, Name
, business_service_key
, technology_type_key
, service_type_key
)
select
'0'
, '0'
, @BatchTag
, l.code
, l.Name
, l.business_service_key
, l.technology_type_key
, l.service_type_key
from lnd.SERVICE_000085 as l
left join mdm.SERVICE_000085_V as ve on l.code = ve.code
where
ve.code is null
declare @count int = @@ROWCOUNT
if (@count > 0)
begin
--Запуск стандартной хранимой процедуры MDS для помещения записей из слоя Staging в справочник
EXEC stg.udp_SERVICE_000085_Leaf
@VersionName = 'VERSION_1',
@LogFlag = 1,
@BatchTag = @BatchTag,
@UserName = 'SI\USER'
end
ENDВыполнение мэппинга справочника источника на эталонный выполнит пользователь, выбрав необходимую запись из эталонного справочника стандартными средствами MDS, как это показано на экране:
Кроме того, если требуется, то в приведенной выше хранимой процедуре можно запрограммировать автоматический мэппинг, для чего язык T-SQL имеет все возможности.
Web Services и запросы REST
MDS предлагает только один способ получения данных справочников системами-потребителями – это подключение по dblink к базе данных и выполнение запросов к представлениям (view). Однако, на сегодняшний день этот способ считается уже морально устаревшим и небезопасным. Сегодня для обмена данными компании предпочитают использовать Web Services с запросами REST, которые и удобнее и предпочтительны с точки зрения информационной безопасности.
Мы решили разработать Web Services, которые, обращаясь к базе данных MDS, выполняют запросы к представлениям справочников и полученные данные передают системе-потребителю в виде структур JSON или XML.
В рамки этой статьи не входит описания создания Web Services, но мы поделимся своим подходом, как всё организовали.
Метаданные MDS
Мы решили сделать универсальный сервис, которые в теле запроса одним параметром получает имя любого справочника, а другими параметрами – условия отбора записей.
Например, формат тела запроса REST можно сделать таким:
{"format": "формат ответа",
"name": "имя_сущности",
"where": [
{
"name": "имя_поля1",
"operator": "=",
"value": "значение для сравнения"
},
{
"name": "имя_поля2",
"operator": ">=",
"value": "значение для сравнения"
}
]
}Где:
format – параметр, задающий формат возвращаемых данных. Возможны два значения: json или xml;
"name": "имя_сущности" – наименование сущности, из которой выбираются данные;
Необязательный блок "where" содержит параметры для фильтрации данных, где: "name": "имя_поляN" – имя поля, по которому фильтруются данные справочника, "operator": "=" – оператор сравнения для фильтрации данных. Допустимые операторы:
Необязательный блок "where" содержит параметры для фильтрации данных, где:
"name": "имя_поляN" – имя поля, по которому фильтруются данные справочника;
"operator": "=" – оператор сравнения для фильтрации данных. Допустимые операторы: = равно, <> не равно, > больше, < меньше, >= больше либо равно, <= меньше либо равно;
“value”: “значение для сравнения” – значение, с которым сравниваются значение поля.
Тело запроса может выглядеть так:
{"format": "json",
"name": "service_000085",
"where": [
{
"name": "technology_type_key",
"operator": "=",
"value": "PSTN/Телефония"
},
{
"name": "lastchgdatetime",
"operator": ">",
"value": "2018.12.31 10:30"
}
]
}Далее мы опираемся на метаданные MDS. В таблице mdm.tblEntity находится перечень всех сущностей и их свойства. В таблице mdm.tblAttribute содержатся атрибуты сущностей и их свойства.
Приложение сервиса выполняет sql-запрос к метаданным MDS, чтобы получить перечень пользовательских атрибутов и их типы данных.
SQL-запрос к метаданным MDS:
select a.Name, a.AttributeType_ID, a.DataType_ID from mdm.tblAttribute as a
inner join mdm.tblEntity as e on a.Entity_ID = e.id
and e.name = 'SERVICE_000085'После чего приложение генерирует sql-запрос, где указывает имя представления справочника, заранее подготовленного в разделе MDS «Управление интеграцией», все пользовательские атрибуты и условия отбора записей.
Sql-запрос к представлению справочника может выглядеть так:
select Code, Name, ImportType, ImportStatus_ID, business_service_key, technology_type_key, technology_type_key
from mdm.SERVICE_000085_V
where technology_type_key = 'PSTN/Телефония'
and lastchgdatetime > '2018.12.31 10:30'В итоге, мы получили полноценный web-сервис, который может возвращать данные любого указанного справочника в независимости от того, когда он был добавлен в MDS и был ли изменен состав его атрибутов.
Общий итог
Часто перед компаниями стоит неочевидный выбор: разрабатывать систему MDM с нуля, рискуя никогда не прийти к успешному внедрению, или внедрять решение из коробки, жертвуя теми частями бизнес-процесса, которые не могут быть автоматизированы из-за архитектурных особенностей коробочных решений.
В нашем примере нам удалось найти баланс между двумя этими подходами и в результате система управления справочной информацией была запущена в промышленную эксплуатацию в течение одного года с момента старта проекта. Первое применение было для корпоративного Центрального Хранилища Данных. В настоящее время мы подключаем к MDS другие информационные системы, которым требуются эталонные справочники и мэппинги справочников корпоративных информационных систем на эталонные.
В ближайшем будущем у нас запланировано замещение проприетарных компонент разработанного решения на отечественные и open-source аналоги с максимальным переиспользованием имеющихся наработок. Для нас это новая планка и естественное продолжение развития MDM-решений в компании. Но об этом мы напишем в нашей следующей статье.
Статья подготовлена командой управления данными «Ростелеком»
