S2t маппинг что это

Основные аспекты формирования маппинга витрины для миграции

В настоящее время наша команда в Neoflex выполняет работы по реализации нескольких проектов миграции данных, в рамках которых появляется потребность построения маппинга. Наш опыт основан на проекте крупнейшего в России банка по миграции витрин из СУБД Oracle в СУБД PostgreSQL в рамках импортозамещения отечественным ПО.

Перед разбором алгоритма маппирования разберем основные понятия.

Начнем с термина «витрина данных». Это простая форма хранилища данных, которое ориентировано на определенную тему или направление деятельности: продажи, финансы или маркетинг. Источниками данных для витрины могут служить: центральное хранилище, внутренние операционные системы, а также внешние данные. Миграция используется для повышения скорости обращения с данными и построения бизнес-отчетов, повышения уровня безопасности информации в рамках импортозамещения на отечественное ПО и т.д.

Миграция витрин — перемещение витрин, например, в новую, более технологичную СУБД, включающее в себя изменение тракта сбора данных из систем-источников в представление витрины. Стоит отдельно выделить два омофона: репликацию и интеграцию данных — эти термины также относятся к теме перемещения данных.

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

Маппирование данных — это процесс сопоставления полей данных на источнике и связанных с ними полей данных в приемнике. То есть это установление соотношения между моделями данных, которые находятся в разных местах.

Маппинг — это описание соответствия между исходными и импортируемыми данными. В большинстве случаев это таблица, где правая часть отведена под источники витрины, а левая часть содержит поля витрины. Для каждого импортируемого поля создается отдельная строка маппинга.

Также в статье используются понятия «сущность» и «атрибут».

Атрибут — это поле (столбец) таблицы данных, сущность — таблица с атрибутами. Например, в сущности «Клиент» находятся атрибуты «ИНН», «Наименование организации», «Статус действия» и т.д.

Перейдем к практическим вопросам формирования маппинга витрин.

Маппинг можно сформировать «ручным» способом или с использованием специального ПО, пару слов о котором расскажу в конце статьи.

Проведение «ручного» маппирования витрины разделим на этапы:

1. Фиксация витрины и сбор информации о ней;
2. Анализ атрибутного состава;
3. Поиск первоисточников и систем-источник данных;
4. Анализ актуальных источников;
5. Проверка корректности заполнения и согласование маппинга.

Разберем каждый из них.

Первый этап. Фиксация витрины и сбор информации о ней

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

Зачем это необходимо сделать? Частым случаем бывает, что бизнес-заказчик после включения витрины в план миграции проводит по ней доработки или вносит изменения. В результате, не уведомив бизнес-заказчика о начале работы над витриной, высока вероятность «отработать» не актуальный состав витрины. За чей счет будет происходить «переработка» — становится острым вопросом при организации работ на проекте.

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

1. Планируются ли внесения изменений в атрибутный состав витрины или ее логику? Соответственно, можно ли начинать работы по витрине, строить ее маппинг?
2. Какой бизнес-смысл витрины, в чем ее «ценность» для бизнеса?
3. Где расположен актуальный S2T (source to target — преимущественно табличное описание соотнесенных между собой полей источника и витрины, если проще, это маппинг на изначальной БД), прототип и скрипт разработки (попросить ссылку)?
4. Какие должны быть глубина истории, историчность и регламент обновления для витрины в новом источнике? . Так, глубина истории может потребовать привлечения дополнительных источников, следовательно, расширения маппинга, или объемов для хранения, или оптимизации кода.
5. Какая система-источник для витрины?
6. Какие предъявляются требованиях к прототипу, к эталону (для сравнения) и какие необходимо провести тест-кейсы?
7. В каком формате необходимо предоставить итоговый маппинг по витрине (попросить шаблон) ?

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

Второй этап. Анализ атрибутного состава S2T витрины

Особое внимание стоит уделить правилам, нормативам и требованиям, принятым у бизнес-заказчика. Важно уточнить у коллег по проекту/бизнес-заказчиков – какие существуют шаблоны, правила оформления результатов маппирования, основные и обязательные этапы работы на конкретном проекте, предусмотренные инструменты/ПО – все это позволит быстро и результативно, а, главное, корректно составить маппинг витрины.

Начнем с того, что в S2T витрине все расчетные атрибуты должны быть разложены на первичные атрибуты, а технические поля иметь однозначный алгоритм расчета.

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

Перейдем к анализу бизнес-смысла атрибутов витрины. Для этого необходимо проверить – имеют ли поля однозначный смысл и полностью ли раскрыто их значение. Если есть сомнения в понимании атрибута – запрашиваем у бизнес-заказчика его смысл. Данное действие необходимо для последующего проведения корректного анализа и сопоставления полям витрины сущностей и атрибутов в новой БД.

Например, поле витрины с бизнес-описанием «Тип компании» имеет под собой минимум два значения. Атрибут может содержать информацию о том, является ли компания юридическим, физическим лицом (ИП) или информацию, касающуюся ее организационно-правовой формы (ООО, АО, ЗАО).

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

Третий этап. Поиск первоисточников и систем-источник данных

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

Суть этапа – выявить трек (data lineage), используемый при построении витрины данных до систем-источников.

Этап поиска включает в себя анализ всего жизненного пути данных, например, используя:

• ER-модели хранилища данных;
• Confluence бизнес-заказчика (при наличии, или иной аналогичный инструмент);
• Informatica (при наличии);
• опрос бизнес-подразделений.

Если для построения витрины используются поля из другой витрины (далее – витрина-источник), но ее миграция не планируется или заказчиком был введен запрет формировать на новом источнике витрину на другой витрине (т.е. делать их взаимосвязанными), то также необходимо провести анализ полей из витрины-источника. Анализ витрины-источника будет аналогичный анализу по заказанной витрине.

Четвертый этап. Анализ актуальных источников

После выявления всех источников и первоисточников для витрины необходимо произвести корректировку плана миграции витрины. На этом этапе необходимо определить актуальные атрибуты для витрины в новой БД. Как правило, для БД существует описание реализованных/запланированных к реализации сущностей – формат представления этих данных может быть любой. Для упрощения понимания описание сущностей и атрибутов в новой БД (модель данных) представим в виде Excel-файла со следующим наполнением:

• Наименование сущности и ее бизнес-описание;
• Наименование атрибута и его бизнес-описание атрибута;
• Наименование область сущности (группы сущностей, объединенных общим смыслом).

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

При анализе модели данных удобно идти как от общего к частному, так и от частного к общему.

В первом случае выбираем основное поле в витрине, например, «ИНН». Находим по бизнес-описанию атрибутов основную сущность с данным атрибутом. Далее последовательно соединяем необходимые по смыслу сущности и их атрибуты. Так как мы начинали сборку витрины от атрибута «ИНН», логично, что он находится в сущности «Клиенты», также для витрины нам нужна информация по кредитным договорам и выручке клиента. Эту информацию через поля-связки мы получим в сущностях, соответственно, «Договоры» и «Справочник аналитических показателей». Не забываем про указание в самом маппинге ключевых полей для связок.

Во втором случае необходимо определить основную узконаправленную область данных сущности, исходя из бизнес-описания полей витрины (в модели данных это «область сущности»). Например, «РКО» (расчетно-кассовое обслуживание) или «Операции», если витрина отражает информацию по заключенным договорам РКО или операциям клиентов по счетам, соответственно. После анализа узконаправленные сущностей и атрибутов переходим к общераспространенным – «Клиенты».

Что делать, если не нашли в новой БД требуемых для витрины атрибутов:

1. Выясняем у коллег (аналитиков, руководителей, бизнес-заказчика), установлен ли алгоритм действия в данном случае, если установлен – действуем согласно алгоритму. Алгоритм может быть изложен в нормативной документации: регламенты, методички.
2. Если порядок действий не регламентирован (рекомендуемый порядок): а) Уведомляем своего руководителя об отсутствии данных в БД; б) Пишем уточняющих запрос по данному атрибуту в команду проектирования модели БД (действительно ли БД отсутствую данные); с) При получении ответа об отсутствии в БД необходимых данных – уведомляем бизнес-заказчика о проблеме, совместно прорабатываем пути решения.

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

Пятый и заключительный этап. Проверка корректности заполнения и согласование маппинга

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

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

Эти данные позволят провести миграцию витрины с сохранением ее логики и «полезности» для бизнес-заказчика. Необходимо уточнить регламент наименования атрибутов и сущностей у бизнес-заказчика.

Может потребоваться провести проверку на соответствие текущих наименований атрибутов витрины требованиям (например, в части суффиксов по типу «_date» или «_rk»). Также могут существовать правила относительно форматов данных атрибутов в новой БД. Например, даты необходимо отражать со указанием временм или даты.

Стоит также обратить внимание на корректность отражения ключевых полей в витрине.Так как маппинг витрины – это важный документ проекта (артефакт), на момент его готовности стоит перепроверить соответствие формата маппинга требованиям заказчика/привести к единообразию с предыдущими маппингами.

После завершения работ с маппингом, рекомендуем направить его на согласование и утверждение заказчику – особенно критично при переименовании полей, так как у заказчика могут быть особые обстоятельства, не допускающие переименования полей витрины.

После получения согласования от заказчика работы по витрине в части маппинга можно считать оконченными.

Предлагаю сейчас ознакомиться с программами, позволяющими оптимизировать процесс маппирования.

Один из таких продуктов – Informatica PowerCenter. Это платформа интеграции данных, работающая на визуализацию данных без написания программного кода. Для формирования маппинга возможно использовать такие особенности и функции Informatica, как:

• Графическое представление потоков данных, анализ взаимосвязей и отслеживание данных;
• Реализация логики обработки данных в визуальной среде. Автоматизация запуска процессов также выполняется в визуальной среде;
• Наличие бизнес-глоссария (может и отсутствовать, но возможность его создания предусмотрена).

Что понравилось в Informatica, так это возможность через одну таблицу проанализировать – из каких таблиц-источников она собирается, а также в какие таблицы эти данные «уходят». Также удобно наличие бизнес-описания полей и таблиц (на практике такая информация не часто встречается).

Пример отображения информации в Informatica:

Стоит обратить внимание, что не каждая связь между таблицами может быть отражена в Informatica (заказчик мог ее и не занести).

Еще одним полезным инструментом является ER-диаграмма. Так как принцип работы программ по построению диаграмм одинаковый, поэтому расскажем их плюсы для маппирования, не привязываясь к конкретному ПО.

Начнем с того, что ER-диаграмма – это схема «сущность-связь», разновидность блок-схемы, где показано – как разные «сущности» (сотрудники, договоры и т.п.) связаны между собой внутри системы. Как и в Informatica, ER-диаграмма – это наглядное представление связи таблиц через ключи. Ключи — один из способов категоризации атрибутов, применяются с целью максимально эффективно связать между собой разные таблицы в базе данных.

Плюсы наглядного представления связи таблиц очевидны — легкое восприятие и понимание базы данных, так как все «как на ладони». Из минусов — в большинстве диаграмм не уточнен бизнес смысл полей, соответственно, что конкретно поле означает можно и не понять сразу.

Не забудьте уточнить — какие подобные инструменты использовались на вашем проекте — возможно, данные для миграции уже представлены в виде ER-диаграмм.

Есть еще два продукта от Microsoft, которые представят связи между таблицами данных в табличном виде — это Excel и Access. Первая программа наверняка вам известна, со второй уже могут быть вопросы.

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

Попробовав различные технологии при маппировании, приходим к выводу, что существующее и доступное ПО самостоятельно создать маппинг не может, но в качестве сокращения трудозатрат при проведении анализа может быть очень полезным.

Возможно, вы захотите поделиться личным опытом использования ПО на проекте: что для вас оказалось действительно полезным, а что — не стоило потраченного времени на изучение?

Big Data Mapping: что такое маппирование больших данных

В этой статье рассмотрено, что такое маппирование больших данных, как это связано с Data Science, когда и как часто выполняется этот процесс, а также, какие программные инструменты позволяют автоматизировать Big Data mapping.

Что такое маппирование данных и где это используется

Представим, что в одной из корпоративных систем сведения о семейном положении сотрудника хранятся так, что «1» в поле «дети» означает их наличие. В другой системе эти же данные записаны с помощью значения «True», а в третьей – словом «да». Таким образом, разные системы для обозначения одних и тех же данных используют разные отображения. Чтобы привести информацию к единообразию, следует сопоставить обозначения одной системы обозначениям в других источниках, т.е. выполнить процедуру мэппинга данных (от английского map – сопоставление). В широком смысле маппирование – это определение соответствия данных между разными семантиками или представлениями одного объекта в разных источниках. На практике этот термин чаще всего используется для перевода или перекодировки значений [1].

Дисциплина управления данными, Data Management, трактует маппинг как процесс создания отображений элементов данных между двумя различными моделями, который выполняется в начале следующих интеграционных задач [2]:

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

Таким образом, маппирование данных представляет собой процесс генерации инструкций по объединению информации из нескольких наборов данных в единую схему, например, конфигурацию таблицы. Поскольку схемы данных в разных источниках обычно отличаются друг от друга, информацию из них следует сопоставить, выявив пересечение, дублирование и противоречия [3].

С прикладной точки зрения можно следующие приложения маппинга данных [4]:

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

В Big Data мэппинг выполняется при загрузке информации в озеро данных (Data Lake) и корпоративное хранилище (DWH, Data Warehouse). Чем Data Lake отличается от DWH, рассмотрено здесь. В этом случае маппинг реализуется в рамках ETL-процесса (Extract, Transform, Load) на этапе преобразования. При этом настраивается соответствие исходных данных с целевой моделью (рис. 1). В случае реляционных СУБД для идентификации одной сущности в разных представлениях нужно с ключами таблиц и настройкой отношений (1:1, *:1, 1:* или *:*) [5].

В Data Science маппирование данных входит в этап их подготовки к ML-моделированию, когда выполняется формирование датасета в виде матрицы значений для обработки соответствующими алгоритмами. В частности, когда Data Scientist обогащает исходный датасет данными из сторонних источников, он занимается маппингом данных. Проводить процедуру дата мэппинга можно вручную или автоматически с помощью соответствующих подходов и инструментов, которые рассмотрены далее.

Особенности процесса дата мэппинга

На практике трудоемкость мэппинга зависит от следующих факторов [3]:

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

Облегчить процесс маппирования можно за счет метаданных – сведениях о признаках и свойствах объектов, которые позволяют автоматически искать и управлять ими в больших информационных потоках. В частности, если каждое приложение будет выполнять публикацию метаданных, что позволит создать их стандартизированный реестр, то маппинг будет полностью автоматизированным [2]. Однако в большинстве случаев процесс мапирования данных не полностью автоматизирован и состоит из следующих этапов [4]:

1. определение данных, которые нужно переместить, включая таблицы, поля в каждой таблице и формат поля после его перемещения. При регулярной интеграции также определяется частота передачи данных.
2. сопоставление исходных полей с полями назначения;
3. преобразование значений, включая кодирование формулы или правила преобразования;
4. тестирование полученных результатов переноса (обогащения) путем сравнения их с образцами данных из первичных источников.
5. развертывание production-решений по регулярной консолидации данных в соответствии с планом переноса или интеграции.

При работе с большими объемами данных выделяют 3 основных подхода к маппированию [2]:

• ручное кодирование, когда приходится писать код для консолидации данных из разных таблиц или форматов. Сюда же можно отнести сопоставление данных в графическом режиме, когда GUI специализированных программ позволяет пользователю рисовать линии от полей в одном наборе данных до соединения с другим источником. При этом «под капотом» автоматически генерируется программный код преобразования на SQL, XSLT, Java, C++ и прочих языках программирования. Такие графические средства часто встречаются в ETL-инструментах в качестве основного средства задания мэппингов для перемещения данных. Например, SAP BODS, Informatica PowerCenter и Talend Data Fabric (рис. 2).

• data-driven мэппинг, который сочетает оценку фактических значений данных в разных источниках данных с использованием эвристики и статистики для автоматического обнаружения сложных взаимосвязей между ними. Этот интеллектуальный подход используется для поиска преобразований между разными датасетами, выявления подстрок, конкатенаций, математический зависимостей, условных операторов и прочих логический преобразований. Также он позволяет найти исключения, которые не соответствуют обнаруженной логике преобразования. Обычно именно этот подход используется в специализированных системах подготовки данных к ML-моделированию, например, SAS, IBM SPSS и т.д.
• семантический маппинг похож на вышеописанный data-driven метод, но здесь к интеллектуальному сопоставлению также подключается реестр метаданных. Например, если в исходной системе указано FirstName, а в системе-приемнике есть поле PersonGivenName, сопоставление будет успешно выполнено, если эти элементы данных перечислены как синонимы в реестре метаданных. Семантическое сопоставление способно выявить только точные совпадения между столбцами данных, но не обнаружит никакой логики преобразования или исключений между столбцами. На практике этот подход применяется при интеграции реляционных СУБД и построении DWH.

Также стоит упомянуть полуавтоматическое маппирование в виде конвертирования схем данных, когда специализированная программа сравнивает источники данных и целевую схему для консолидации. Затем разработчик проверяет схему маппирования и вносит исправления, где это необходимо. Далее программа конвертирования схем данных автоматически генерирует код на C++, C # или Java для загрузки данных в систему приемник (рис. 3) [3].

Далее рассмотрим, какие инструментальные средства реализуют вышеперечисленные подходы.

Инструменты маппирования больших данных

Как и большинство прикладных решений, все средства для маппинга данных можно разделить на 3 категории [6]:

• проприетарные (on-premise), например, Centerprise Data Integrator, CloverDX, IBM InfoSphere, Informatica PowerCenter, Talend Data Integration. Как правило, эти продукты широко используются в корпоративном секторе.
• открытые (open-source), которые дешевле предыдущих аналогов и являются более легковесными с точки зрения функциональных возможностей. Однако их вполне достаточно для индивидуальных исследований Data Science. Наиболее популярными в этой категории считаются Pentaho, Pimcore, Talend Open Studio.
• облачныесервисы, такие как, Informatica Cloud Data Integration, Oracle Integration Cloud Service, Talend Cloud Integration, Dell Boomi AtomSphere, DX Mapper, Alooma, Jitterbit. Современные Cloud-решения считаются безопасными, быстрыми, масштабируемыми, относительно недорогими и удобными для использования. Поэтому их можно применять как в корпоративных, так и в личных целях.

Большинство перечисленных продуктов поддерживают все 3 подхода к маппированию: ручной (GUI и кодирование), data-driven и семантический. Однако, семантический мэппинг требует наличия реестров метаданных, что имеется далеко не в каждом предприятии. А публичные реестры метаданных, такие как национальные, отраслевые или городские репозитории [7] не всегда напрямую коррелируют, например, с задачами построения локального DWH. Но, наряду с открытыми государственными данными и другими публичными датасетами, их можно использовать в исследовательских DS-задачах.

При выборе конкретного инструмента для маппинга больших данных стоит учитывать следующие факторы:

• cложность данных – объемы, разнообразие форматов и схем. Этот критерий непосредственно связан со спецификой задачи. Например, если требуется обогатить не слишком большой датасет для ML-моделирования, сопоставив данные из нескольких источников, Data Scientist может воспользоваться простым облачным сервисом или написать собственный скрипт. Однако, в случае регулярной загрузки информации из множества СУБД в корпоративное хранилище или озеро данных, необходимо выбирать надежное ETL-средство enterprise-уровня.
• расширяемость– наглядный GUI повышает удобство пользования, однако, на практике часто возникает задача кастомизации автоматически сгенерированных соответствий. Поэтому инструмент маппирования должен включать возможность править созданные мэппинги, настраивать правила и писать собственные преобразования в виде программных скриптов.
• стоимость, включая все затраты на приобретение, использование, техническую поддержку и прочие расходы.

Резюме

Итак, маппирование данных – это важная часть процесса работы с данными, в том числе и для Data Scientist’а. Эта процедура выполняется в рамках подготовки к ML-моделированию, в частности, при обогащении датасетов. В случае одноразового формирования датасета из нескольких разных источников сопоставление данных можно выполнить вручную или с помощью самописного Python-скрипта. Однако, такой подход не применим в промышленной интеграции нескольких информационных систем или построении корпоративных хранилищ и озер данных. Поэтому знание инструментов дата мэппинга пригодится как Data Scientist’у, так и Data Engineer’у. Наконец, сопоставление данных с целью избавления от дублирующихся и противоречивых значений входит в задачи обеспечения качества данных (Data Quality) [4]. В свою очередь, Data Quality относится к области ответственности стратега по данным и инженера по качеству данных. Таким образом, понимание процесса маппирования необходимо каждому Data-специалисту.

1. https://ru.wikipedia.org/wiki/Мапирование
2. https://en.wikipedia.org/wiki/Data_mapping
3. https://www.xplenty.com/blog/data-mapping-an-overview-of-data-mapping-and-its-technology/
4. https://www.talend.com/resources/data-mapping/
5. https://habr.com/ru/post/248231/
6. https://dzone.com/articles/what-is-data-mapping
7. https://en.wikipedia.org/wiki/Metadata_registry

Основные аспекты формирования маппинга витрины для миграции

В настоящее время наша команда в Neoflex выполняет работы по реализации нескольких проектов миграции данных, в рамках которых появляется потребность построения маппинга. Наш опыт основан на проекте крупнейшего в России банка по миграции витрин из СУБД Oracle в СУБД PostgreSQL в рамках импортозамещения отечественным ПО.

Перед разбором алгоритма маппирования разберем основные понятия.

Начнем с термина «витрина данных». Это простая форма хранилища данных, которое ориентировано на определенную тему или направление деятельности: продажи, финансы или маркетинг. Источниками данных для витрины могут служить: центральное хранилище, внутренние операционные системы, а также внешние данные. Миграция используется для повышения скорости обращения с данными и построения бизнес-отчетов, повышения уровня безопасности информации в рамках импортозамещения на отечественное ПО и т.д.

Миграция витрин — перемещение витрин, например, в новую, более технологичную СУБД, включающее в себя изменение тракта сбора данных из систем-источников в представление витрины. Стоит отдельно выделить два омофона: репликацию и интеграцию данных — эти термины также относятся к теме перемещения данных.

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

Маппирование данных — это процесс сопоставления полей данных на источнике и связанных с ними полей данных в приемнике. То есть это установление соотношения между моделями данных, которые находятся в разных местах.

Маппинг — это описание соответствия между исходными и импортируемыми данными. В большинстве случаев это таблица, где правая часть отведена под источники витрины, а левая часть содержит поля витрины. Для каждого импортируемого поля создается отдельная строка маппинга.

Также в статье используются понятия «сущность» и «атрибут».

Атрибут — это поле (столбец) таблицы данных, сущность — таблица с атрибутами. Например, в сущности «Клиент» находятся атрибуты «ИНН», «Наименование организации», «Статус действия» и т.д.

Перейдем к практическим вопросам формирования маппинга витрин.

Маппинг можно сформировать «ручным» способом или с использованием специального ПО, пару слов о котором расскажу в конце статьи.

Проведение «ручного» маппирования витрины разделим на этапы:

1. Фиксация витрины и сбор информации о ней;

2. Анализ атрибутного состава;

3. Поиск первоисточников и систем-источник данных;

4. Анализ актуальных источников;

5. Проверка корректности заполнения и согласование маппинга.

Разберем каждый из них.

Первый этап. Фиксация витрины и сбор информации о ней.

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

Зачем это необходимо сделать? Частым случаем бывает, что бизнес-заказчик после включения витрины в план миграции проводит по ней доработки или вносит изменения. В результате, не уведомив бизнес-заказчика о начале работы над витриной, высока вероятность «отработать» не актуальный состав витрины. За чей счет будет происходить «переработка» — становится острым вопросом при организации работ на проекте.

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

1. Планируются ли внесения изменений в атрибутный состав витрины или ее логику? Соответственно, можно ли начинать работы по витрине, строить ее маппинг?

2. Какой бизнес-смысл витрины, в чем ее «ценность» для бизнеса?

4. Где расположен актуальный S2T (source to target — преимущественно табличное описание соотнесенных между собой полей источника и витрины, если проще, это маппинг на изначальной БД), прототип и скрипт разработки (попросить ссылку)?

5. Какие должны быть глубина истории, историчность и регламент обновления для витрины в новом источнике? . Так, глубина истории может потребовать привлечения дополнительных источников, следовательно, расширения маппинга, или объемов для хранения, или оптимизации кода.

6. Какая система-источник для витрины?

7. Какие предъявляются требованиях к прототипу, к эталону (для сравнения) и какие необходимо провести тест-кейсы?

8. В каком формате необходимо предоставить итоговый маппинг по витрине (попросить шаблон) ?

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

Второй этап. Анализ атрибутного состава S2T витрины.

Особое внимание стоит уделить правилам, нормативам и требованиям, принятым у бизнес-заказчика. Важно уточнить у коллег по проекту/бизнес-заказчиков – какие существуют шаблоны, правила оформления результатов маппирования, основные и обязательные этапы работы на конкретном проекте, предусмотренные инструменты/ПО – все это позволит быстро и результативно, а, главное, корректно составить маппинг витрины.

Начнем с того, что в S2T витрине все расчетные атрибуты должны быть разложены на первичные атрибуты, а технические поля иметь однозначный алгоритм расчета.

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

Перейдем к анализу бизнес-смысла атрибутов витрины. Для этого необходимо проверить – имеют ли поля однозначный смысл и полностью ли раскрыто их значение. Если есть сомнения в понимании атрибута – запрашиваем у бизнес-заказчика его смысл. Данное действие необходимо для последующего проведения корректного анализа и сопоставления полям витрины сущностей и атрибутов в новой БД.

Например, поле витрины с бизнес-описанием «Тип компании» имеет под собой минимум два значения. Атрибут может содержать информацию о том, является ли компания юридическим, физическим лицом (ИП) или информацию, касающуюся ее организационно-правовой формы (ООО, АО, ЗАО).

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

Третий этап. Поиск первоисточников и систем-источник данных.

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

Суть этапа – выявить трек (data lineage), используемый при построении витрины данных до систем-источников.

Этап поиска включает в себя анализ всего жизненного пути данных, например, используя:

● ER-модели хранилища данных;

● Confluence бизнес-заказчика (при наличии, или иной аналогичный инструмент);

● Informatica (при наличии);

Если для построения витрины используются поля из другой витрины (далее – витрина-источник), но ее миграция не планируется или заказчиком был введен запрет формировать на новом источнике витрину на другой витрине (т.е. делать их взаимосвязанными), то также необходимо провести анализ полей из витрины-источника. Анализ витрины-источника будет аналогичный анализу по заказанной витрине.

Четвертый этап. Анализ актуальных источников.

После выявления всех источников и первоисточников для витрины необходимо произвести корректировку плана миграции витрины. На этом этапе необходимо определить актуальные атрибуты для витрины в новой БД. Как правило, для БД существует описание реализованных/запланированных к реализации сущностей – формат представления этих данных может быть любой. Для упрощения понимания описание сущностей и атрибутов в новой БД (модель данных) представим в виде Excel-файла со следующим наполнением:

— Наименование сущности и ее бизнес-описание;

— Наименование атрибута и его бизнес-описание атрибута;

— Наименование область сущности (группы сущностей, объединенных общим смыслом).

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

При анализе модели данных удобно идти как от общего к частному, так и от частного к общему.

В первом случае выбираем основное поле в витрине, например, «ИНН». Находим по бизнес-описанию атрибутов основную сущность с данным атрибутом. Далее последовательно соединяем необходимые по смыслу сущности и их атрибуты. Так как мы начинали сборку витрины от атрибута «ИНН», логично, что он находится в сущности «Клиенты», также для витрины нам нужна информация по кредитным договорам и выручке клиента. Эту информацию через поля-связки мы получим в сущностях, соответственно, «Договоры» и «Справочник аналитических показателей». Не забываем про указание в самом маппинге ключевых полей для связок.

Во втором случае необходимо определить основную узконаправленную область данных сущности, исходя из бизнес-описания полей витрины (в модели данных это «область сущности»). Например, «РКО» (расчетно-кассовое обслуживание) или «Операции», если витрина отражает информацию по заключенным договорам РКО или операциям клиентов по счетам, соответственно. После анализа узконаправленные сущностей и атрибутов переходим к общераспространенным – «Клиенты».

Что делать, если не нашли в новой БД требуемых для витрины атрибутов:

1. Выясняем у коллег (аналитиков, руководителей, бизнес-заказчика), установлен ли алгоритм действия в данном случае, если установлен – действуем согласно алгоритму. Алгоритм может быть изложен в нормативной документации: регламенты, методички.
2. Если порядок действий не регламентирован (рекомендуемый порядок): а) Уведомляем своего руководителя об отсутствии данных в БД; б) Пишем уточняющих запрос по данному атрибуту в команду проектирования модели БД (действительно ли БД отсутствую данные); с) При получении ответа об отсутствии в БД необходимых данных – уведомляем бизнес-заказчика о проблеме, совместно прорабатываем пути решения.

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

Пятый и заключительный этап. Проверка корректности заполнения и согласование маппинга.

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

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

Эти данные позволят провести миграцию витрины с сохранением ее логики и «полезности» для бизнес-заказчика. Необходимо уточнить регламент наименования атрибутов и сущностей у бизнес-заказчика.

Может потребоваться провести проверку на соответствие текущих наименований атрибутов витрины требованиям (например, в части суффиксов по типу «_date» или «_rk»). Также могут существовать правила относительно форматов данных атрибутов в новой БД. Например, даты необходимо отражать со указанием временм или даты.

Стоит также обратить внимание на корректность отражения ключевых полей в витрине.Так как маппинг витрины – это важный документ проекта (артефакт), на момент его готовности стоит перепроверить соответствие формата маппинга требованиям заказчика/привести к единообразию с предыдущими маппингами.

После завершения работ с маппингом, рекомендуем направить его на согласование и утверждение заказчику – особенно критично при переименовании полей, так как у заказчика могут быть особые обстоятельства, не допускающие переименования полей витрины.

После получения согласования от заказчика работы по витрине в части маппинга можно считать оконченными.

Предлагаю сейчас ознакомиться с программами, позволяющими оптимизировать процесс маппирования.

Один из таких продуктов – nformatica PowerCenter. Это платформа интеграции данных, работающая на визуализацию данных без написания программного кода. Для формирования маппинга возможно использовать такие особенности и функции Informatica, как:

— Графическое представление потоков данных, анализ взаимосвязей и отслеживание данных;

— Реализация логики обработки данных в визуальной среде. Автоматизация запуска процессов также выполняется в визуальной среде;

— Наличие бизнес-глоссария (может и отсутствовать, но возможность его создания предусмотрена).

Что понравилось в Informatica, так это возможность через одну таблицу проанализировать – из каких таблиц-источников она собирается, а также в какие таблицы эти данные «уходят». Также удобно наличие бизнес-описания полей и таблиц (на практике такая информация не часто встречается).

Пример отображения информации в Informatica:

Стоит обратить внимание, что не каждая связь между таблицами может быть отражена в Informatica (заказчик мог ее и не занести).

Еще одним полезным инструментом является ER-диаграмма. Так как принцип работы программ по построению диаграмм одинаковый, поэтому расскажем их плюсы для маппирования, не привязываясь к конкретному ПО.

Начнем с того, что ER-диаграмма – это схема «сущность-связь», разновидность блок-схемы, где показано – как разные «сущности» (сотрудники, договоры и т.п.) связаны между собой внутри системы. Как и в Informatica, ER-диаграмма – это наглядное представление связи таблиц через ключи. Ключи — один из способов категоризации атрибутов, применяются с целью максимально эффективно связать между собой разные таблицы в базе данных.

Плюсы наглядного представления связи таблиц очевидны — легкое восприятие и понимание базы данных, так как все «как на ладони». Из минусов — в большинстве диаграмм не уточнен бизнес смысл полей, соответственно, что конкретно поле означает можно и не понять сразу.

Не забудьте уточнить — какие подобные инструменты использовались на вашем проекте — возможно, данные для миграции уже представлены в виде ER-диаграмм.

Есть еще два продукта от Microsoft, которые представят связи между таблицами данных в табличном виде — это Excel и Access. Первая программа наверняка вам известна, со второй уже могут быть вопросы.

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

Попробовав различные технологии при маппировании, приходим к выводу, что существующее и доступное ПО самостоятельно создать маппинг не может, но в качестве сокращения трудозатрат при проведении анализа может быть очень полезным.

Возможно, вы захотите поделиться личным опытом использования ПО на проекте: что для вас оказалось действительно полезным, а что — не стоило потраченного времени на изучение?

Архитектор данных/инженер данных

Архитектор должен иметь высшее техническое образование или быть студентом старших курсов технического вуза (МАИ, СПбПУ, МГУ и т. п.). Кроме того, ему потребуются: • базовые знания СУБД • опыт создания/ведения моделей данных (например, ER-моделей) и ETL-проектирования (карты загрузки данных S2T, маппинг) • опыт отрисовки потока данных Приветствуется опыт работы у ИТ-интеграторов

Какой будет загрузка на проекте?

Срок выполнения работ — 1,5 месяца и предполагает неполную загрузку (до 60 рабочих часов в месяц)

Каким будет формат взаимодействия?

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

На какую помощь можно рассчитывать?

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