[SQL, Администрирование баз данных, Хранение данных] Тысяча и один справочник в Master Data Management Ростелекома

Автор Сообщение
news_bot ®

Стаж: 6 лет 8 месяцев
Сообщений: 27286

Создавать темы news_bot ® написал(а)
28-Янв-2021 17:32

Всем привет! На связи Александр Киваев, руководитель направления департамента управления справочной информацией в команде управления данными «Ростелекома». Если у вас в компании внедрена и эффективно работает 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 системы:1.   Подготовить эталонные корпоративные справочники.2.   Получить данные справочников из информационных систем предприятия, которые в этом случае называются системами-источниками. Для этого можно использовать какое-либо средство из Extract Transfom Load (ETL). Помещаем полученные данные в слой, который назовём Landing.3.   Трансформировать данные в общий формат. Для этого выполняем приведение типов к типам данных принятым в системе MDM. Полученный результат помещаем в слой, который назовем Staging.4.   Перевести данные из слоя Staging в слой готовых справочников.5.   Установить соответствие записей, полученных от систем-источников на записи эталонных справочников. Такое действие называется мэппингом.6.   Предоставить системам-потребителям средства для получения данных из эталонных справочников и мэппингов.Такой подход позволил бы получить возможность применять справочники MDM в качестве показателей, на основе которых можно строить корпоративные отчёты и витрины BI, а также дал бы возможность информационным системам компании использовать единые выверенные и гарантированно достоверные справочники в качестве эталонных значений. Ограничения Microsoft MDS Microsoft MDS по своим функциям не соответствует сценарию, приведенному выше. По своей сути, MDS представляет собой хоть и удобное, но лишь средство ведения справочников. Производителем подразумевается, что специалисты по корпоративным справочникам будут создавать эталонные справочники и наполнять их значениями. После этого они будут использоваться любой другой корпоративной информационной системой.Исходя из вышесказанного, получается, что система Master Data Services решает только два пункта из приведенного выше сценария:·         Ведение эталонных справочников.·         Предоставление системам-потребителям средств для получения справочников.Мы в своей работе решили использовать систему MDS, так как она была доступна без дополнительных вложений. Вместе с тем, мы дополнили её недостающими функциями, чтобы получить решение, полностью соответствующее типичному сценарию MDM. Доработка MDS до полноценной MDMПо условиям лицензионного соглашения пользователю запрещено вносить какие-либо изменения в программный продукт MDS, но всегда есть технический способ дополнить функции стандартного решения, не затрагивая его самого, что нами и было проделано. Доработка свелась к последовательности действий:1.   Была создана отдельная база данных, которая выполняла функцию слоя Landing. В таблицы этой базы средствами стандартного ETL мы поместили данные справочников, полученные из систем-источников. Для каждого справочника каждого источника была подготовлена своя таблица.2.   В этой базе данных мы создали хранимые процедуры, которые запускаются после получения справочников из систем-источников. Хранимые процедуры выполняют выделение инкремента и помещение его из слоя Landing в стандартный слой Staging MDS (в базе данных MDS, это схема данных stg). Кроме того, хранимая процедура может выполнять автоматический мэппинг новых или измененных записей системы-источника на эталонный справочник.3.   Далее в хранимой процедуре мы реализовали вызов оригинальной хранимой процедуры 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 и запросы RESTMDS предлагает только один способ получения данных справочников системами-потребителями – это подключение по 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-решений в компании. Но об этом мы напишем в нашей следующей статье.Статья подготовлена командой управления данными «Ростелеком»
===========
Источник:
habr.com
===========

Похожие новости: Теги для поиска: #_sql, #_administrirovanie_baz_dannyh (Администрирование баз данных), #_hranenie_dannyh (Хранение данных), #_upravlenie_dannymi_v_rostelekom (управление данными в ростелеком), #_sql, #_microsoft_sql_server, #_spravochniki (справочники), #_dannye_v_kompanii (данные в компании), #_hranenie_dannyh (хранение данных), #_blog_kompanii_rostelekom (
Блог компании Ростелеком
)
, #_sql, #_administrirovanie_baz_dannyh (
Администрирование баз данных
)
, #_hranenie_dannyh (
Хранение данных
)
Профиль  ЛС 
Показать сообщения:     

Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы

Текущее время: 01-Ноя 05:31
Часовой пояс: UTC + 5