В настоящее время наша команда в Neoflex выполняет работы по реализации нескольких проектов миграции данных, в рамках которых появляется потребность построения маппинга. Наш опыт основан на проекте крупнейшего в России банка по миграции витрин из СУБД Oracle в СУБД PostgreSQL в рамках импортозамещения отечественным ПО.
Перед разбором алгоритма маппирования разберем основные понятия.
Начнем с термина «витрина данных». Это простая форма хранилища данных, которое ориентировано на определенную тему или направление деятельности: продажи, финансы или маркетинг. Источниками данных для витрины могут служить: центральное хранилище, внутренние операционные системы, а также внешние данные. Миграция используется для повышения скорости обращения с данными и построения бизнес-отчетов, повышения уровня безопасности информации в рамках импортозамещения на отечественное ПО и т.д.
Миграция витрин — перемещение витрин, например, в новую, более технологичную СУБД, включающее в себя изменение тракта сбора данных из систем-источников в представление витрины. Стоит отдельно выделить два омофона: репликацию и интеграцию данных — эти термины также относятся к теме перемещения данных.
Интеграция может быть непрерывным процессом, который включает потоковую передачу данных в реальном времени и обмен информацией между системами. А при репликации вы периодически переносите данные в целевое расположение, не удаляя и не отбрасывая их источник. Стоит отметить, что репликация данных может быть частью процесса интеграции данных. Например, миграция исторического среза витрины — что особенно актуально при введении в целевой базе данных нового источника, не имеющего истории.
Маппирование данных — это процесс сопоставления полей данных на источнике и связанных с ними полей данных в приемнике. То есть это установление соотношения между моделями данных, которые находятся в разных местах.
Маппинг — это описание соответствия между исходными и импортируемыми данными. В большинстве случаев это таблица, где правая часть отведена под источники витрины, а левая часть содержит поля витрины. Для каждого импортируемого поля создается отдельная строка маппинга.
Также в статье используются понятия «сущность» и «атрибут».
Атрибут — это поле (столбец) таблицы данных, сущность — таблица с атрибутами. Например, в сущности «Клиент» находятся атрибуты «ИНН», «Наименование организации», «Статус действия» и т.д.
Перейдем к практическим вопросам формирования маппинга витрин.
Маппинг можно сформировать «ручным» способом или с использованием специального ПО, пару слов о котором расскажу в конце статьи.
Проведение «ручного» маппирования витрины разделим на этапы:
Фиксация витрины и сбор информации о ней;
Анализ атрибутного состава;
Поиск первоисточников и систем-источник данных;
Анализ актуальных источников;
Проверка корректности заполнения и согласование маппинга.
Разберем каждый из них.
Первый этап. Фиксация витрины и сбор информации о ней
На основании опыта взаимодействия с бизнес-заказчиками на проекте рекомендую: прежде чем приступить к маппингу витрины, необходимо зафиксировать дату начала работ у заказчика и выявить их требования к реализации витрины.
Зачем это необходимо сделать? Частым случаем бывает, что бизнес-заказчик после включения витрины в план миграции проводит по ней доработки или вносит изменения. В результате, не уведомив бизнес-заказчика о начале работы над витриной, высока вероятность «отработать» не актуальный состав витрины. За чей счет будет происходить «переработка» — становится острым вопросом при организации работ на проекте.
Исходя из проектного опыта, предлагаю совмещать письмо к бизнес-заказчику о фиксации витрины с запросом первичной информации о ней. Вопросы в письме могут быть сформулированы следующим образом:
Планируются ли внесения изменений в атрибутный состав витрины или ее логику? Соответственно, можно ли начинать работы по витрине, строить ее маппинг?
Какой бизнес-смысл витрины, в чем ее «ценность» для бизнеса?
Где расположен актуальный S2T (source to target — преимущественно табличное описание соотнесенных между собой полей источника и витрины, если проще, это маппинг на изначальной БД), прототип и скрипт разработки (попросить ссылку)?
Какие должны быть глубина истории, историчность и регламент обновления для витрины в новом источнике? . Так, глубина истории может потребовать привлечения дополнительных источников, следовательно, расширения маппинга, или объемов для хранения, или оптимизации кода.
Какая система-источник для витрины?
Какие предъявляются требованиях к прототипу, к эталону (для сравнения) и какие необходимо провести тест-кейсы?
В каком формате необходимо предоставить итоговый маппинг по витрине (попросить шаблон) ?
Полученную информацию рекомендуется зафиксировать в удобном для вас виде, но доступном для использования другими членами команды (если возникнет потребность в ней во время вашего отсутствия). Например, сохранить письмо в папке на общекомандном файловом ресурсе или создать под витрину страницу в Confluence (при наличии возможности).
Второй этап. Анализ атрибутного состава S2T витрины
Особое внимание стоит уделить правилам, нормативам и требованиям, принятым у бизнес-заказчика. Важно уточнить у коллег по проекту/бизнес-заказчиков – какие существуют шаблоны, правила оформления результатов маппирования, основные и обязательные этапы работы на конкретном проекте, предусмотренные инструменты/ПО – все это позволит быстро и результативно, а, главное, корректно составить маппинг витрины.
Начнем с того, что в S2T витрине все расчетные атрибуты должны быть разложены на первичные атрибуты, а технические поля иметь однозначный алгоритм расчета.
В корректном S2T должны содержаться все использованные в скрипте витрины поля, в том числе те, которые используются при фильтрации и наложении ограничений. Это можно проверить с помощью скрипта на сборку витрины. Однако, это достаточно трудоемкий процесс, требующий согласования с заказчиком. Вполне возможно, что подобные работы уже проведены и дополнительный анализ будет излишним и дублирующимся шагом.
Перейдем к анализу бизнес-смысла атрибутов витрины. Для этого необходимо проверить – имеют ли поля однозначный смысл и полностью ли раскрыто их значение. Если есть сомнения в понимании атрибута – запрашиваем у бизнес-заказчика его смысл. Данное действие необходимо для последующего проведения корректного анализа и сопоставления полям витрины сущностей и атрибутов в новой БД.
Например, поле витрины с бизнес-описанием «Тип компании» имеет под собой минимум два значения. Атрибут может содержать информацию о том, является ли компания юридическим, физическим лицом (ИП) или информацию, касающуюся ее организационно-правовой формы (ООО, АО, ЗАО).
При наличии в бизнес-описании полей аббревиатуры также рекомендуется запросить их расшифровку. Понятное и общепринятое на первый взгляд сокращение может иметь у заказчика совершенно иной смысл. Например, КЭП: квалифицированная электронная подпись или коэффициент эффективности предприятия.
Третий этап. Поиск первоисточников и систем-источник данных
Этап зависит от требований заказчика и может быть пропущен. Причина в том, что он включает в себя поиск таблиц-источников и систем-источников, которые используются при формировании витрины в настоящее время, т.е. уже неактуальные. В любом случае, данный этап поможет ускорить маппирование четвертого этапа, если при анализе будет обнаружен маппинг данных старого источника на новый источник. С его помощью возможно не только значительно сэкономить время составления итогового маппинга витрины, но также избежать ошибок некорректного сопоставления полей.
Суть этапа – выявить трек (data lineage), используемый при построении витрины данных до систем-источников.
Этап поиска включает в себя анализ всего жизненного пути данных, например, используя:
ER-модели хранилища данных;
Confluence бизнес-заказчика (при наличии, или иной аналогичный инструмент);
Informatica (при наличии);
опрос бизнес-подразделений.
Если для построения витрины используются поля из другой витрины (далее – витрина-источник), но ее миграция не планируется или заказчиком был введен запрет формировать на новом источнике витрину на другой витрине (т.е. делать их взаимосвязанными), то также необходимо провести анализ полей из витрины-источника. Анализ витрины-источника будет аналогичный анализу по заказанной витрине.
Четвертый этап. Анализ актуальных источников
После выявления всех источников и первоисточников для витрины необходимо произвести корректировку плана миграции витрины. На этом этапе необходимо определить актуальные атрибуты для витрины в новой БД. Как правило, для БД существует описание реализованных/запланированных к реализации сущностей – формат представления этих данных может быть любой. Для упрощения понимания описание сущностей и атрибутов в новой БД (модель данных) представим в виде Excel-файла со следующим наполнением:
Наименование сущности и ее бизнес-описание;
Наименование атрибута и его бизнес-описание атрибута;
Наименование область сущности (группы сущностей, объединенных общим смыслом).
Это упрощенное в рамках статьи описание логики хранения данных. Возможно, на проекте описание модели данных будет содержать информацию и о формате данных, и о связях сущностей, ключах и т.д.
При анализе модели данных удобно идти как от общего к частному, так и от частного к общему.
В первом случае выбираем основное поле в витрине, например, «ИНН». Находим по бизнес-описанию атрибутов основную сущность с данным атрибутом. Далее последовательно соединяем необходимые по смыслу сущности и их атрибуты. Так как мы начинали сборку витрины от атрибута «ИНН», логично, что он находится в сущности «Клиенты», также для витрины нам нужна информация по кредитным договорам и выручке клиента. Эту информацию через поля-связки мы получим в сущностях, соответственно, «Договоры» и «Справочник аналитических показателей». Не забываем про указание в самом маппинге ключевых полей для связок.
Во втором случае необходимо определить основную узконаправленную область данных сущности, исходя из бизнес-описания полей витрины (в модели данных это «область сущности»). Например, «РКО» (расчетно-кассовое обслуживание) или «Операции», если витрина отражает информацию по заключенным договорам РКО или операциям клиентов по счетам, соответственно. После анализа узконаправленные сущностей и атрибутов переходим к общераспространенным – «Клиенты».
Что делать, если не нашли в новой БД требуемых для витрины атрибутов:
Выясняем у коллег (аналитиков, руководителей, бизнес-заказчика), установлен ли алгоритм действия в данном случае, если установлен – действуем согласно алгоритму. Алгоритм может быть изложен в нормативной документации: регламенты, методички.
-
Если порядок действий не регламентирован (рекомендуемый порядок):
а) Уведомляем своего руководителя об отсутствии данных в БД;
б) Пишем уточняющих запрос по данному атрибуту в команду проектирования модели БД (действительно ли БД отсутствую данные);
с) При получении ответа об отсутствии в БД необходимых данных – уведомляем бизнес-заказчика о проблеме, совместно прорабатываем пути решения.
Важно не молчать об отсутствии данных, так как это может сказаться на реализации проекта в целом.
Пятый и заключительный этап. Проверка корректности заполнения и согласование маппинга
Необходимо проверить наличие в маппинге всех запрошенных бизнесом в S2T атрибутов, а также наличие атрибутов-связок для актуальных источников. Еще раз уточнить соответствие бизнес-логики атрибутов и самой витрины, чтобы избежать противоречий между ними. В итоге маппинг витрины (формат запросили на первом этапе) может содержать следующую информацию:
о бизнес-смысле витрины, ее историчности, глубине истории и регламенте обновления, требованиях к прототипу. Также это ссылки на источники информации по витрине;
о сущностях, на которых строится витрина сейчас;
из каких систем-источников собирается информация для витрины;
об актуальных сущностях, на которых витрина строится после миграции.
Эти данные позволят провести миграцию витрины с сохранением ее логики и «полезности» для бизнес-заказчика. Необходимо уточнить регламент наименования атрибутов и сущностей у бизнес-заказчика.
Может потребоваться провести проверку на соответствие текущих наименований атрибутов витрины требованиям (например, в части суффиксов по типу «_date» или «_rk»). Также могут существовать правила относительно форматов данных атрибутов в новой БД. Например, даты необходимо отражать со указанием временм или даты.
Стоит также обратить внимание на корректность отражения ключевых полей в витрине.Так как маппинг витрины – это важный документ проекта (артефакт), на момент его готовности стоит перепроверить соответствие формата маппинга требованиям заказчика/привести к единообразию с предыдущими маппингами.
После завершения работ с маппингом, рекомендуем направить его на согласование и утверждение заказчику – особенно критично при переименовании полей, так как у заказчика могут быть особые обстоятельства, не допускающие переименования полей витрины.
После получения согласования от заказчика работы по витрине в части маппинга можно считать оконченными.
Предлагаю сейчас ознакомиться с программами, позволяющими оптимизировать процесс маппирования.
Один из таких продуктов – nformatica PowerCenter. Это платформа интеграции данных, работающая на визуализацию данных без написания программного кода. Для формирования маппинга возможно использовать такие особенности и функции Informatica, как:
Графическое представление потоков данных, анализ взаимосвязей и отслеживание данных;
Реализация логики обработки данных в визуальной среде. Автоматизация запуска процессов также выполняется в визуальной среде;
Наличие бизнес-глоссария (может и отсутствовать, но возможность его создания предусмотрена).
Что понравилось в Informatica, так это возможность через одну таблицу проанализировать – из каких таблиц-источников она собирается, а также в какие таблицы эти данные «уходят». Также удобно наличие бизнес-описания полей и таблиц (на практике такая информация не часто встречается).
Пример отображения информации в Informatica:
Стоит обратить внимание, что не каждая связь между таблицами может быть отражена в Informatica (заказчик мог ее и не занести).
Еще одним полезным инструментом является ER-диаграмма. Так как принцип работы программ по построению диаграмм одинаковый, поэтому расскажем их плюсы для маппирования, не привязываясь к конкретному ПО.
Начнем с того, что ER-диаграмма – это схема «сущность-связь», разновидность блок-схемы, где показано – как разные «сущности» (сотрудники, договоры и т.п.) связаны между собой внутри системы. Как и в Informatica, ER-диаграмма – это наглядное представление связи таблиц через ключи. Ключи — один из способов категоризации атрибутов, применяются с целью максимально эффективно связать между собой разные таблицы в базе данных.
Пример ER-диаграммы:
Плюсы наглядного представления связи таблиц очевидны — легкое восприятие и понимание базы данных, так как все «как на ладони». Из минусов — в большинстве диаграмм не уточнен бизнес смысл полей, соответственно, что конкретно поле означает можно и не понять сразу.
Не забудьте уточнить — какие подобные инструменты использовались на вашем проекте — возможно, данные для миграции уже представлены в виде ER-диаграмм.
Есть еще два продукта от Microsoft, которые представят связи между таблицами данных в табличном виде — это Excel и Access. Первая программа наверняка вам известна, со второй уже могут быть вопросы.
У них примерно одинаковый принцип работы: при импорте связанных таблиц из реляционной базы данных ПО может создавать эти связи (через ключевые поля) в модели данных, формируемой в фоновом режиме.
Попробовав различные технологии при маппировании, приходим к выводу, что существующее и доступное ПО самостоятельно создать маппинг не может, но в качестве сокращения трудозатрат при проведении анализа может быть очень полезным.
Возможно, вы захотите поделиться личным опытом использования ПО на проекте: что для вас оказалось действительно полезным, а что — не стоило потраченного времени на изучение?