Разработка методики организации процесса миграции данных из эксплуатируемой информационной системы во внедряемую. Миграция баз данных Подготовка шаблонов загрузки данных
Разработка общих требований к миграции данных
В рамках разработки общих требований к миграции данных бизнес-аналитиком должна быть определена стратегия миграции данных. Исходя из потребностей бизнеса, режима функционирования организации-заказчика, должна быть выбрана миграция «большого взрыва» или плавная миграция.
При выборе стратегии «большого взрыва» должно быть определено время, которое может быть затрачено бизнесом на простой во время миграции данных. После определения времени, которое бизнес может потратить на простой во время миграции данных может быть составлен график миграции данных. При составлении графика миграции данных должен быть выделен резервный день или дни, необходимые для повторной миграции в случае серьезных ошибок.
При выборе стратегии плавной миграции все бизнес-пользователи целевой системы должны быть разделены на группы, для которых должен быть составлен график переключения на работу с целевой системой. После деления бизнес-пользователей на группы должны быть определены соответствующие им наборы данных и сущностей. При распределении бизнес-пользователей по группам должны учитываться взаимосвязи этих групп в рамках бизнес-процесса, автоматизируемого в целевой системе.
Параллельно с выбором стратегии проведения миграции данных менеджментом проекта и/ или бизнес-аналитиком должна быть произведена выявление типовых рисков миграции данных. Для каждого выявленного риска должна быть выбрана стратегия (методы) работы с риском и разработан комплекс мероприятий по предотвращению риска. Стратегией предотвращения риска может быть одна из следующих :
- · отказ от чрезмерно рисковой деятельности (метод отказа),
- · профилактика или диверсификация (метод снижения),
- · аутсорсинг затратных рисковых функций (метод передачи),
- · формирование резервов или запасов (метод принятия).
В таблице 1, приведена матрица типовых рисков миграции данных и способы работы с каждым из таких рисков. В ячейках матрицы приведены примеры мероприятий по работе с каждым из рисков в рамках каждого метода предотвращения риска.
При составлении таблицы предполагалось, что стратегия «Отказ» не является приемлемой для проектной команды, так как предпосылкой для исследования является необходимость выполнять работы по миграции. Таким образом, отсутствует возможность полного или частичного исключения таких работ из скоупа проекта.
Таблица 1 Матрица рисков и возможных стратегий работы с рисками этапа миграции
|
Стратегия работы с риском |
Снижение |
Передача |
Принятие |
|
|
Риски составления технической спецификации |
Проработка требований к миграции совместно с бизнесом, владельцами и потребителями мигрируемых данных |
Привлечение к работам по составлению технической спецификации консультантов |
Формирование резерва бюджета и времени на проекте для работы с потенциальными запросами на изменение |
|
|
Риски тестирования |
Проработка тестовых планов и сценарием с привлечением бизнес-пользователей |
Передача пакета работ по тестированию отдельной команде с заранее определенными условиями приемки их резудьтатов |
Формирование резерва времени и бюджета на потенциальные дополнительные работы вследствие неполного тестирования миграционного ПО и размещенных данных |
|
|
Риски процесса получения и загрузки данных |
Проработка требований к тестовой выгрузке. Проведение «тестовой» миграции с использованием тестовой выгрузки |
Формирование резерва бюджета и времени для повторных получений выгрузок и итеративной загрузки |
||
|
Стратегия работы с риском |
Снижение |
Передача |
Принятие |
|
|
Риски, связанные с работой проектной команды |
||||
|
Риски размещения данных в целевой системе |
Параллельная проработка модели данных “as is” и “ to be” для нивелирования различий в форматах и способах работы с данными в источнике и приемнике |
Формирование резерва времени и бюджета для доработок функциональности системы-приемника |
Организация планирования работ по миграции данных
Входной информацией для составления планов работ по миграции является стратегия миграции данных, сформулированная в рамках разработки общих требований к миграции данных.
Результатом планирования работ по миграции данных должен набор проектных артефактов, в которых зафиксирована последовательность шагов по реализации миграции данных. Выходами этапа планирования являются следующие проектные артефакты: план работ по миграции и план коммуникаций на этапе миграции данных.
План работ по миграции определяет набор задач и ответственных за их выполнение, распределенных с помощью матрицы RACI. Проектный план работ по миграции должен содержать пакеты задач и работ для каждого из этапов миграции: от подготовительного до пост-миграционного этапа работ. С учетом результатов анализа проектного опыта была разработана ИСР, позволяющая избежать рисков и соответствующая «эталонным» теоретическим подходам к организации миграции данных.
Приведенная на Рис. 3 структура работ покрывает все этапы миграции и может быть трассирована к строкам проектного плана работ. В рамках проектного плана работ должны быть определены сроки выполнения каждой задачи и обозначены выходы каждой задачи. При составлении плана работ для каждой задачи должно быть определено условие, выполнение которого будет однозначно определять, что задача завершена.
Не менее важным проектным артефактом этапа миграции данных является план коммуникаций. План коммуникаций на этапе миграции определяет цели и виды взаимодействия между участниками проектной команды, а также между участниками проектной команды и сотрудниками заказчика - бизнес-пользователями.
Оформление плана коммуникаций в рамках этапа миграции должно основываться на составленном ранее плане работ. Для каждой задачи в рамках проектного плана должны быть определены следующие атрибуты:
- 1. Предмет (тема) коммуникации.
- 2. Необходимость взаимодействия ролевых групп внутри команды;
Кто должен участвовать в коммуникации? Какие ролевые группы?
- 3. Какой тип взаимодействия приемлем?
- 4. Что должно являться выходом коммуникации?
- 5. Необходимость взаимодействия с проектной команды и бизнес-пользователей;
- 6. Кто должен участвовать в коммуникации со стороны проектной команды и со стороны бизнеса?
- 7. Какой тип взаимодействия с бизнес-пользователями приемлем?
- 8. Что должно являться выходом коммуникации с бизнес-пользователями?
- 9. Кто должен быть осведомлен о результатах коммуникации?
Шаблон плана коммуникаций на этапе миграции данных приведен в таблице 2 ниже (Таблица 2).
Таблица 2 Шаблон плана коммуникации на этапе миграции данных
|
Тема коммуникации |
указывается основной вопрос или задача, для решения которой необходима данная коммуникация, раздел требований к миграции, объекты данных |
|
Участники со стороны проектной команды |
указываются ролевые группы и роли |
|
Необходимость взаимодействия с бизнесом |
проставляется признак: да или нет |
|
Участники со стороны бизнеса |
указывается функциональное подразделение и ответственный сотрудник |
|
Тип взаимодействия |
указывается тип взаимодействия, например: письменное, встреча, воркшоп |
Разработка и документирование бизнес-требований к миграции данных
Разработка и документирование требований к миграции данных должно осуществляться в несколько этапов. В рамках разрабатываемой методики в этап разработки бизнес-требований к миграции данных будет также включен шаг проведения и документирования результатов обследования организации-заказчика. Цель этапа разработки бизнес-требований к миграции данных - разработка полного пакета требований к специализированному ПО для миграции данных, а также к составу данных, мигрируемых в целевую систему.
1. Обследование эксплуатируемой информационной системы
Обследование эксплуатируемой информационной системы хронологически должно быть первым этапом работ в рамках разработки требований к миграции данных.
Обследование существующей информационной системы в рамках разработки требований к миграции данных может проводиться в рамках работ по обследованию бизнеса всего проекта внедрения ИС. Обследование в рамках разработки требований к миграции данных должно быть направлено на создание модели данных `as is". Модель данных `as is" позволит подготовить требования к составу мигрируемых данных из системы-источника в систему-приемник.
Модель данных `as is" описывает все объекты данных, которые используются в эксплуатируемой системе. После составления такой модели заказчику будет проще выбрать перечень объектов данных для переноса в систему-приемник. В такой модели должны быть указаны имена сущностей, а также описан их атрибутный состав и взаимосвязи между сущностями с указанием их кардинальности.
Помимо модели данных эксплуатируемой системы на этапе обследования должны быть составлены схемы бизнес-процессов, в которых используются объекты данных, выбранные для переноса в целевую систему. Модели бизнес-процессов позволят выявить недостающие объекты данных, в случае если они были упущены при анализе модели данных.
Помимо составления модели данных `as is" на этапе обследования должны быть описаны правила работы со словарями и справочниками в эксплуатируемой системе. В частности, должны быть описаны следующие моменты для каждого словаря:
- - Наименование словаря или справочника;
- - Ответственное за администрирование словаря функциональное подразделение;
- - Наличие проверки уникальности для кодов и значений записей словарей;
- - Наличие правил регулярного обновления записей в словарях;
- - Описание правил работы с записями словарей, потерявшими актуальность;
- - В случае если миграция данных производится из нескольких источников, необходимо описать, есть ли дублирование словарей в нескольких системах-источниках. В случае наличия дублей словарей в нескольких системах-источниках, требуется описание правил дедубликации и маппинга записей для каждого словаря;
Формат спецификации требований к миграции словарей из системы-источника в целевую систему приведен в таблице и пример заполнения такой спецификации приведен.
2. Разработка требований к профилю данных для миграции
Разработка требований к профилю данных для миграции должна происходить с участием групп ключевых бизнес-пользователей в соответствии с планом коммуникаций, разработанным в ходе планирования работ по миграции данных. Шаблон документа и пример заполнения для фиксирования результатов обследования приведен в таблице 4 (Таблица 4).
Бизнес-пользователи являются источниками для получения ответов на следующие вопросы о профиле данных для миграции данных:
- 1) Будут ли мигрированные данные являться входными для работы бизнес-процесса, автоматизированного в проектируемой системе? Ответом на данный вопрос должна стать таблица-описание соответствия объектов данных системы-источника и бизнес-процессов, автоматизированных в целевой системе.
- 2) Какой временной промежуток должен быть определен для миграции данных? При этом должны быть учтены положения нормативных и организационно-распорядительных документов. Ответом на данный вопрос должна стать таблица соответствия объекта данных и временного горизонта выгрузки данных из системы-источника.
- 3) Какому объекту данных целевой системы соответствует каждый из выбранных для миграции объектов данных системы-источника? Ответом на данный вопрос должна стать таблица маппинга объектов данных системы-источника и системы-приемника.
- 4) Есть ли в атрибутном составе объектов данных системы-источника поля или группа атрибутов, которые не будут использоваться в целевой системе? Ответом на данный вопрос должна стать таблица описания атрибутного состава объектов данных с проставленным флагом: используется/ не используется в целевой системе.
- 5) Есть ли в атрибутном составе объектов данных системы-источника поля или группы атрибутов, которые не соответствуют по типу данных полям в целевой системе? Ответом на данный вопрос должна стать таблица описания атрибутного состава объектов данных с проставленным флагом и расшифровкой несоответствий.
- 6) Происходила ли модернизация системы-источника, результатом которой стало значительное изменение в структуре данных, которые необходимо мигрировать? Примеры изменений:
- - Изменение состава обязательных атрибутов;
- - Изменение правил хранения объектов данных;
- - Значительное изменение структуры объекта данных, приводящее к изменению объемов данных.
Ответом на данный вопрос должно стать описание объектов данных системы-источника с описанием особенностей работы с объектом данных в течение временного промежутка, для которого производится миграция данных.
7) Какое функциональное подразделение или конкретные пользователи являются владельцами данных? Ответом на этот вопрос должна стать таблица соответствия объектов данных и сотрудников заказчика.
Сотрудники ИТ-подразделения являются источниками для получения ответов на следующие вопросы о профиле данных для миграции:
- 1) Где физически хранятся данные, выбранные бизнес-пользователями для миграции в целевую систему? Что является источником данных: корпоративное приложение, система или источники за пределами организации-заказчика? Ответом на данный вопрос должна стать таблица соответствия объектов данных и их хранилищ (имя и тип БД, имя таблицы/таблиц в БД).
- 2) Позволяет ли метаинформация мигрируемого контента разработать алгоритмы миграции? Возможно ли произвести анализ структуры данных на основе метаинформации?
- 3) Есть ли технологические ограничения системы-источника, которые отражаются на структуре данных, формах хранения и работы с данными? Ответом на данный вопрос должно стать полное описание технологических ограничений системы-источника в разрезе объектов данных для миграции.
Сотрудники ИТ-подразделения и бизнес-пользователи совместно должны произвести оценку критичности потенциальных ошибок при переносе данных из системы-источника в целевую систему. В частности, бизнес-пользователи и сотрудники ИТ-подразделений должны проанализировать взаимосвязи объектов данных на уровне используемой БД для определения перечня возможных проверок целостности данных при переносе в целевую систему.
Разработка требований к профилю данных для миграции должна завершаться получением тестовой выгрузки данных из системы-источника (систем-источников) в соответствии с разработанным профилем данных. Полученная тестовая выгрузка будет использоваться для отладки миграционного ПО и оценки качества предоставляемых данных.
- 3. Разработка требований к утилите миграции
- 1) Требования к очистке и логическим проверкам данных
После разработки требований к профилю данных для миграции необходимо разработать правила очистки или преобразования выгруженных из систем-источников данных для их корректного размещения в целевой системе. Для этой цели необходимо соотнести бизнес-требования к модели данных проектируемой системы и описание модели данных эксплуатируемой системы.
Для целей определения уровня качества данных должны применяться следующие типы логических проверок в рамках каждого мигрируемого объекта данных:
- - Заполнены ли все обязательные атрибуты?
- - Физический тип данных каждого атрибута в системе-источнике и системе-приемнике совпадают?
- - Длины значений атрибутов в объекте данных удовлетворяют требованиям в целевой системе?
- - Формат хранения данных (даты, десятичные числа) соответствуют требованиям в целевой системе?
- - Идентификаторы объектов данных в системе-источнике позволяют их однозначно различить?
Требования к логическим проверкам должны быть зафиксированы в функциональной спецификации на утилиту миграции данных.
Выявленные несоответствия в данных для загрузки могут быть устранены одним из следующих способов: данные могут быть удалены из состава выгрузки, если они не имеют бизнес-ценности или преобразованы с помощью специфических алгоритмов.
Для корректного размещения данных в целевой системе для объектов данных могут быть разработаны алгоритмы преобразований следующих видов:
- - Недостающие обязательные атрибуты могут быть заполнены заранее определенными значениями - «заглушками».
- - Значения атрибутов, длина которых не соответствует требованиям целевой системы, должны быть сокращены.
- - Формат дат системы-источника должен быть приведен к формату хранения дат системы-приемника.
- - Формат хранения десятичных числовых данных должен быть приведен к формату хранения десятичных числовых данных в целевой системе.
- - Атрибуты, физически тип данных которых не соответствует требованиям целевой системы, должны быть преобразованы. Например, текстовые значения могут быть приведены к целочисленным.
Требования к алгоритмам очистки и преобразования данных, а также виды объектов данных, для которых они будут применены, должны быть зафиксированы в функциональной спецификации на утилиту миграции данных.
2) Требования к именованию сущностей в системе-приемнике
Требования к разработке алгоритмов именования сущностей в системе-приемнике должны разрабатываться в случае, если в целевой системе невозможно применить алгоритмы, используемые для именования сущностей в системе-источнике/ системах-источниках.
Алгоритмы именования и нумерации объектов данных должны быть разработаны в следующих случаях:
- - Если из двух систем-источников производится миграция объектов данных с одинаковым бизнес-смыслом, то в целевой системе для формирования их имен и номеров должен применяться общий алгоритм.
- - Если в системе-источнике для формирования номеров сущностей применялись алгоритмы, которые более не являются актуальными в силу изменившихся нормативных или организационно-распорядительных документов.
- - Если в системе-источнике для формирования номеров сущностей применялись алгоритмы, которые не удовлетворяют бизнес-правилам работы с сущностями в проектируемой системе.
Требования к алгоритмам формирования имен и номеров мигрированных сущностей должны быть зафиксированы в функциональной спецификации на утилиту миграции данных.
3) Требования к логированию миграции данных
Для отслеживания состояния процесса миграции данных утилита миграции должна поддерживать логирование загрузки данных в целевую систему. При этом в логе утилиты миграции должна отражаться информация обо всех произведенных логических проверках и удалении данных из набора данных для загрузки в целевую систему.
Требования к логу утилиты миграции должны быть зафиксированы в функциональной спецификации на утилиту миграции.
Лог утилиты миграции должен позволять отследить каждую операцию в рамках процесса загрузки данных в целевую систему.
Каждая запись лога миграции данных должна обладать как минимум следующим набором атрибутов:
- · Вид мигрируемого объекта данных;
- · Система-источник;
- · Уникальный идентификатор объекта данных в системе-источнике;
- · Уникальный идентификатор объекта данных в системе-приемнике;
- · Дата и время проведения загрузки для данного объекта данных;
- · Сформированное утилитой миграции имя/номер для данного объекта данных, в случае если для данного объекта данных был применен алгоритм формирования имен/ номеров сущностей;
- · Флаг: был ли объект данных мигрирован в систему-приемник или был исключен из загруженных данных;
- · Причина, по которой объект был исключен из загруженных данных - состав логических проверок и правил;
- · Описание ошибки, возникшей в ходе миграции объекта данных, если такая произошла.
В атрибуте «Описание ошибки» отражается параметризованное сообщение утилиты миграции данных, в случае если утилита миграции не смогла выполнить загрузку объекта данных в целевую систему.
В случае если для объекта данных выставлен флаг - объект удален из мигрируемых данных, то в атрибуте «Причина исключения удаления объекта данных» должно отражаться параметризованное сообщение, описывающее алгоритм очистки данных, в соответствии с которым из мигрируемых данных был удален данный объект.
Фрагмент лога утилиты миграции приведен в приложении 4 (Приложение 4 - Фрагмент лога утилиты миграции).
Проведение тестирования в рамках работ по миграции данных
Работы по тестированию состоит из следующих пакетов работ:
- 1. Первичное тестирование миграционного ПО на соответствие технической спецификации;
- 2. Бизнес-тестирование миграционного ПО на соответствие требованиям бизнеса к алгоритмам трансформации данных во время миграции;
- 4. Тестирование работы функциональности системы-приемника после размещения мигрируемых данных;
Ниже приведена последовательность шагов, которые должны быть предприняты проектной командой для проведения каждого из этапов тестирования.
Первичное тестирование миграционного ПО должно выявить и устранить технические сбои и дефекты разработанной утилиты миграции. Такое тестирование должно проводиться силами команды тестировщиков в соответствии с разработанными тест-кейсами. При этом после доработок ПО в случае выявленных ошибок обязательным является проведение регрессионного тестирования утилиты.
Бизнес-тестирование миграционного ПО на соответствие требования бизнеса и алгоритмам трансформации данных должно выполняться с использованием лога утилиты миграции для обеспечения полноты проверок и тестов. Порядок действий при бизнес-тестировании может быть следующим:
- 1. Определить по логу утилиты миграции игнорированные при загрузке объекты данных.
- 2. Убедиться, что эти объекты в системе-источнике удовлетворяли условиям применения логических проверок или механизмов трансформации.
- 3. В случае выявления несоответствия зафиксировать ошибку работы утилиты миграции.
Ошибки, зафиксированные в ходе тестирования, должны фиксироваться в таком виде, чтобы можно было однозначно определить источник их появления - алгоритм или правило, сработавшее неверно.
Для бизнес-тестирования утилиты миграции могут применяться автоматизированные средства тестирования. В случае их отсутствия набор юнит-тестов должен охватывать все возможные типы объектов данных, которые были мигрированы в целевую систему, а также все спроектированные для каждого типа проверки и механизмы трансформации.
Тестовая очистка и загрузка данных предполагает работы с данными, полученными после разработки пакета требований к профилю мигриуемых данных. Тестовая выгрузка должна быть инструментом для проверки следующих характеристик миграционного ПО:
- - Работа бизнес-алгоритмов, логических проверок и механизмов преобразования на реальных данных;
- - Работоспособность миграционного ПО на приближенных к продуктивным объемах данных.
Работа с тестовой выгрузкой - завершающий этап тестирования миграционного ПО. После обработки утилитой миграции тестовой выгрузки становится возможной оценка необходимого планового времени для загрузки всего массива мигрируемых данных. Успешное размещение тестовой выгрузки в системе-приемнике должно означать внутреннюю приемку утилиты миграции и возможность перехода к работам по загрузке промышленной - полной выгрузки из системы-источника в целевую систему.
Тестовая очистка и загрузка данных в систему-приемник предполагает выполнение всех необходимых для миграции данных в целевую систему операций, включая тестирование функциональности системы-приемника. Подробнее этот этап тестирования описан ниже.
Тестирование работы функциональности системы-приемника должно обеспечить возможность убедиться в том, что все функции системы, использующие мигрированный контент работают в штатном режиме. При этом такое тестирование может осуществляться в два этапа:
- 1. Тестирование работоспособности системы-приемника;
- 2. Детальное тестирование функциональности системы-приемника.
Для проведения тестирования работоспособности системы-приемника сразу после завершения загрузки должен быть составлен краткий сценарий тестирования, в котором указывается, что именно необходимо проверить на работоспособность, например:
- - перечень экранных форм, которые необходимо открыть,
- - количество объектов в справочниках (словарях), которое должно быть видно пользователю;
- - количество объектов в реестрах системы, которое должно быть видно пользователю,
- - перечень функций системы, которые должны быть запущены (построение отчетов, поисковые механизмы, доступ к мигрированным объектам данных).
Детальное тестирование функциональности системы-приемника предполагает запуск всех автоматизируемых бизнес-процессов, для которых входными данными являются мигрированные данные. В случае если в состав загруженных данных входит более одного типа объектов данных, то тестовые сценарии должны быть предусмотрены для каждого мигрированного типа данных. Результаты тестирования функциональности системы-приемника должны фиксироваться в журнале тестирования.
В соответствии со стандартом ANSI журнал (лог) тестирования миграции данных должен иметь следующую структуру:
- 1. Идентификатор тест-кейса;
- 2. Описание операции в рамках тест-кейса;
- 3. Описание ошибки во время выполнения операции в рамках тест-кейса;
- 4. Влияние ошибки на функциональность системы;
- 5. Влияние ошибки на связанные операции тестирования.
Описание операции в рамках тест-кейса в обязательном порядке должно включать:
a) Входящие данные для операции;
b) Ожидаемые результаты;
c) Полученные результаты;
d) Дата и время выполнения операции;
e) Количество попыток выполнения операции;
f) Ответственные за тестирование члены проектной команды;
g) Окружение операции в рамках тест-кейса.
Фрагмент журнала тестирования функциональности системы-приемника приведен в приложении 5 (Приложение 5 - Журнал тестирования результатов миграции).
Миграция данных невероятно сложная и ответственная задача. Она влечет за собой определенный уровень коммерческого и технического риска. Потребность в миграции данных может возникнуть при переходе на новую систему, например при внедрении SAP или при подключении к уже продуктивной системе новых справочников или даже отдельных систем. В любом случае можно однозначно сказать, что миграция это процесс переноса данных из устаревших систем на новую платформу.
Как и в любую другую систему должна быть проведена максимально качественно и правильно. Только успешно выполненная миграция данных позволит начать успешную продуктивную эксплуатацию.
В большинстве случаев миграция данных требует индивидуального подхода и определённого опыта.
- Необходимо заранее заранее определить стратегию миграции данных. Слабое понимание процесса и не достаток опыта не повод относиться халатно к миграции данных;
- Обязательно должен быть составлен план миграции данных и назначены ответственные сотрудникам и ключевые пользователи;
- Определить какие основные данные (материалы, контрагенты, банки, и пр.) и какие транзакционнные данные (заказы, открытые позиции и пр.) будет участвовать в миграции данных;
- Определить периоды и объемы данных;
- Подготовить регламенты и методики миграции данных;
- Нормализация и структуризация данных. Так же очень важный шаг при миграции данных. Не бывает такого, чтобы было слишком рано начинать очистку данных от мусора (дубли, не полные и не однозначные записи). Пропуская этот шаг помните, что мусорные данные приведут к проблемам в эксплуатации SAP и могут стоить компаниями намного дороже, чем во время сделанная очистка данных;
- При миграции данных должны быть обязательно разработаны понятные шаблоны сбора и загрузки данных. Это так же ответственный шаг, ключевые пользователи должны однозначно понимать что и как заполнять в шаблоне;
- Разработать средства загрузки данных. Средства должны быть понятны и удобны для сотрудников НСИ, а так же содержать проверки и защиту от человеческого фактора. А так же загрузчики данных должны уметь быстро загружать данные. За частую процесс загрузки готовых шаблонов с данными занимает не более 5 дней;
- Контроль процесса миграции данных должен производиться на всех этапах, как во время тестовой миграции данных, так во время пилотного запуска и продуктивной загрузки данных.
- Заключительный этап, после продуктивной миграции данных, это проверка качества загруженных данных. Помните, что исправить все проще на ранних стадиях. По этому только убедившись в 100% качестве загруженных данных следует начинать продуктивную эксплуатацию системы.
Мы специализируемся на комплексном подходе к миграции основных данных и справочников НСИ.
- Составим план миграции, включающий ответственных и очередность загрузки справочников;
- Определим вместе с вами объемы и сроки миграции данных;
- Напишем методики и регламенты миграции данных;
- Проведем нормализацию, консолидацию и классификацию данных;
- Подготовим шаблоны для миграции данных, с понятным описанием их заполнения;
- Напишем загрузчики для миграции данных. Мы разрабатываем загрузчики стандартными средствами SAP, в частности LSMW, гарантирует качественную и стабильную загрузку данных;
- Проведем тестовую и продуктивную миграцию данных;
- Проверим качество загруженных в систему данных.
Отрасль PLM развивается уже более десяти лет и наступил тот момент, когда предприятия, опробовав решения, выбранные изначально, вполне резонно решают сменить существующую PLM на другую, либо существенно изменить конфигурацию текущей. И тут возникает вопрос миграции данных PLM из старой системы в новую. Как мы знаем, даже трансляция самих геометрических данных является непростой и неоднозначно решаемой задачей, миграция данных PLM – еще более сложный и пока малоизвестный процесс.
Как это бывает
Выбор новой системы PLM был сделан, команда руководителей с облегчением празднует результат сложных усилий этого выбора. На деле, только теперь начинается настоящая работа, планирование и осуществление миграции данных из существующих систем в новую целевую платформу PLM. Существующие данные компании содержат значительную часть интеллектуальной собственности (ИС) и, следовательно, конкурентные преимущества и капитал компании. Успех внедрения новой системы в значительной степени зависит от выполнения эффективной миграции существующих данных, интеллигентно, качественно и своевременно.Этот сценарий регулярно повторяется в том или ином виде по всему миру и в любой отрасли. С быстрыми темпами совершенствования технологий, усилением конкурентного давления, приводит к тому, что многие компании постоянно оценивают их PLM-решения и проводят улучшения. Решение может быть вызвано признанием того, что текущее решение, или, чаще, его техническое обслуживание, либо использование нескольких систем, не устраивают руководство компании. Кроме того, есть еще один общий мотив - последствия приобретений компании и осознание того, что консолидация их различных PLM решений является оправданным. Еще один сценарий – необходимость массивной перенастройки текущей платформы. Независимо от причин изменений, эффективное выполнение изменений будет зависеть от успешной миграции существующих данных на новую платформу.
Проблемы миграции данных
Миграция данных выносит на первый план многочисленные вопросы. Например, может выясниться, что это первая за многие годы ревизия того, как компания выбирала средства управления данными о продукте. Для того чтобы преодолеть очевидные недостатки в текущей модели данных, которая развивалась с течением времени, компании, возможно, придется изменить части модели или расширить ее. В любом случае, эти изменения окажут дополнительное давление на процесс перехода от старого к новому, простой перенос данных может оказаться невозможным. Один из важнейших моментов миграции заключается в том, что сначала нужно определить все данные, которые подлежат рассмотрению. Многие считают, что речь идет лишь о передаче цифровых данных, однако опытные специалисты наверняка признают, что какая-то часть критической ИС компании может все еще быть в печатном виде, либо вообще ее носителями являются головы ведущих сотрудников.После того как данные, которые подлежат миграции были идентифицированы, необходимо разработать и исполнить процессы проверки их правильности. Часто данные могут оказаться устаревшими, поскольку последние изменения не были внесены в более ранние версии данных. Кроме того, часто используются дублированные данные (или поддерживается в нескольких системах), требуя постоянной или периодической проверки согласованности и чистки данных. Определение полного объема данных для миграции требует использования знаний наиболее опытных сотрудников компании.
Возможно, одной из самых больших проблем миграции данных являются сроки миграции. Старые данные будут постоянно пополняться и модифицироваться, так как компания не может остановить свою работу и ждать завершения новой реализации PLM. Кроме того, в реальности коллектив, осуществляющий миграцию, имеет весьма ограниченные технические сроки для реального переключения, типично это - выходные или праздничные дни. Необходимость уложиться в доступное календарное время требует реализации алгоритмов миграции с помощью специальных инструментов, так как данные могут легко содержать в себе сотни тысяч (или даже миллионов) записей.
Пример решения
Обратимся к опыту тех, кто осуществлял и осуществляет миграцию данных PLM на регулярной основе. Одним из признанных специалистов в области миграции данных PLM является немецкая компания PRION Group , имеющая одиннадцатилетний опыт оказания таких услуг и эффективный инструментарий для их выполнения. Так как портфолио PRION включает в себя интерфейсы для наиболее распространенных PDM и унаследованными системами, из которого данные должны быть перенесены, в каждом конкретном случае у компании нет необходимости заново разработать ПО для миграции. Это позволяет быстро разработать план перехода с учетом особенностей конкретной компании и быстро выполнить миграцию, чтобы минимизировать ее воздействие на развитие продукта и производства. На рисунке ниже изображена схема типового процесса миграции данных по методологии PRION.Наиболее существенно то, что работоспособность этой схема многократно подтверждена выполненными проектами миграции данных PLM у многочисленных клиентов PRION. Более того, неоднократные попытки произвести прямую трансляцию данных из одной системы PLM в другую доказали 100% неработоспособность такого примитивного подхода. Среди факторов, определяющих такое положение дел: сбор данных из нескольких источников, необходимость преобразования и чистки данных, их аттестации и загрузки в новую систему (ы), которые также могут быть физически распределены. Таким образом, существуют совершенно неприемлемые при переходе на новую платформу PLM.
Для снижения этих рисков, PRION разработал средства миграции, которые используют промежуточную базу данных. Данные экспортируются в промежуточную базу данных и, перед загрузкой в новую целевую платформу PLM, преобразуются в этой базе данных. Такой подход не приводит к немедленному изменению в рабочих данных и бизнес может продолжаться как обычно, в то время как разрабатываются правила и детали процесса миграции данных. Критическим фактором для успеха миграции является создание системы управления изменениями, чтобы не только отслеживать изменения, сделанные в ходе миграции самих данных, но и изменения данных, сделанные после загрузки в новую платформу PLM. Эта система управления изменениями должна поддерживать конкретные требования заказчика от самого процесса миграции до запуска новой системы в эксплуатацию в реальных условиях.
Тот факт, что PRION может использовать многие из сценариев миграции из своей обширной библиотеки, которая была разработана для бывших клиентов снижает риски миграции и снижает затраты для будущих клиентов значительно. Этот подход помогает во многих трудных сценариев миграции, особенно когда целевая система является распределенным решением.
Для получения более детальной информации об инструментах и услугах PRION рекомендую обратиться на сайт
Проблемы контроля версий баз данных и миграций между версиями уже не раз поднимались как на Хабре (, , и др.), так и в Интернете (преимущественно, англоязычном).
В первом разделе этой статьи я рассматриваю основные проблемы, которые возникают в командах программистов при внесении любых изменений в структуру базы данных. Во втором разделе я попытался выделить основные общие подходы к тому, в каком виде изменения структуры базы данных можно хранить и поддерживать в процессе разработки.
Терминология
База данных - совокупность всех объектов БД (таблиц, процедур, триггеров и т.д.), статических данных (неизменяемых данных, хранящихся в lookup-таблицах) и пользовательских данных (которые изменяются в процессе работы с приложением).Структура базы данных - совокупность всех объектов БД и статических данных. Пользовательские данные в понятие структуры БД не входят.
Версия базы данных - определенное состояние структуры базы данных. Обычно у версии есть номер, связанный с номером версии приложения.
Миграция , в данном контексте, - обновление структуры базы данных от одной версии до другой (обычно более новой).
В этом смысле термин миграция, похоже, используется во многих источниках (особенно этому поспособствовали миграции из gem"а Active Record, входящего в состав Ruby on Rails). Однако при использовании этого термина возникает двусмысленность: человек, который не знает контекста, скорее подумает, что речь идет о переносе базы данных с одной СУБД на другую (MySQL => Oracle), а то и вовсе о миграции процессов/данных между нодами кластера. Поэтому предлагаю в случаях, когда контекст неочевиден, использовать более точный термин: версионная миграция баз данных.
Зачем это нужно?
Разработчики, которые уже сталкивались с проблемой рассинхронизации версий БД и приложения, могут пропустить этот раздел. Здесь я напомню, почему нужно соблюдать паритет версий приложения и базы данных и какая общая проблема при этом возникает.Версия базы данных должна соответствовать версии приложения
Итак, представьте себе следующую ситуацию: команда из нескольких программистов разрабатывает приложение, которое активно использует базу данных. Время от времени приложение поставляется в продакшн - например, это веб-сайт, который деплоится на веб-сервер.Любому программисту в процессе написания кода приложения может понадобиться изменить структуру базы данных, а также, сами данные, которые в ней хранятся. Приведу простой пример: допустим, есть необнуляемое (not nullable) строковое поле в одной из таблиц. В этом поле не всегда есть данные, и в этом случае там хранится пустая строка. В какой-то момент вы решили, что хранить пустые строки - семантически неправильно в некоторых случаях (см. , ), а правильно - хранить NULL"ы. Для того, чтобы это реализовать, понадобятся следующие действия:
1. Изменить тип поля на nullable:
ALTER myTable CHANGE COLUMN myField myField VARCHAR (255) NULL DEFAULT NULL ;
2. Так как в этой таблице на продакшн БД уже наверняка есть пустые строки, вы принимаете волевое решение и трактуете их как отсутствие информации. Следовательно, нужно будет заменить их на NULL:
UPDATE myTable SET myField = NULL WHERE myField = "" ;
3. Изменить код приложения так, чтобы при получении из БД данных, хранящихся в этом поле, он адекватно реагировал на NULL"ы. Записывать в это поле тоже теперь нужно NULL"ы вместо пустых строк.
Из пункта 3 можно видеть, что приложение и база данных - неразрывные части одного целого. Это означает, что при поставке новой версии приложения в продакшн, нужно обязательно обновлять и версию базы данных, иначе приложение попросту не сможет правильно работать. В данном примере, если до новой версии будет обновлено только приложение, то в какой-то момент произойдет вставка NULL в необнуляемое поле, а это очевидная ошибка.
Таким образом, обновление версии приложения требует корректной версионной миграции базы данных .
Так ли это просто?
Осознав, что паритет версий БД и приложения необходим, вам нужно удостовериться, что миграции БД до нужной версии всегда будут выполняться правильно. Но в чём здесь проблема? Ведь, на первый взгляд, сложного здесь ничего нет!Тут снова обратимся к живому примеру. Допустим, программисты в процессе разработки записывают свои изменения структуры и данных БД в отдельный файл в виде SQL-запросов (как DDL -, так и DML -запросов). А при каждом деплое последней версии приложения вы одновременно обновляете до последней версии и базу данных, выполняя запросы из того самого SQL-файла… Но погодите, с какой версии
вы обновляете БД до последней версии? «С прошлой»? Но так ли хорошо вы помните, что конкретно из себя представляла прошлая версия (её выпустили 2 месяца назад)? Если нет, то как вы собрались её обновлять? Ведь без точной информации о состоянии структуры и данных выполнить корректную миграцию невозможно: если вы непредумышленно выполните запросы, которые уже когда-то выполнялись, это может привести к потере данных или нарушению их целостности.
Простой пример - замена паролей на их MD5-суммы. Если повторно выполнить такой запрос, то данные можно будет восстановить только из бэкапа. Да и вообще, любые UPDATE "ы, DELETE "ы, и даже INSERT "ы, выполненные повторно, могут привести к крайне нежелательным последствиям. Не говоря уже о несвоевременных TRUNCATE "ах и DROP "ах (хотя такие случаи намного менее вероятны).
Кстати говоря, с этой точки зрения, недовыполнить - не меньшая опасность для работоспособности приложения, чем перевыполнить.
Таким образом, можно сделать вывод, что в процессе версионной миграции все запросы должны выполняться только один раз и, к тому же, в правильной последовательности . Последовательность важна потому, что одни изменения могут зависеть от других (как в примере с обнуляемым полем).
Общие принципы версионной миграции
В предыдущем разделе мы выделили важные критерии, которые показывают, что же требуется от процесса версионной миграции. Это:- единоразовое выполнение каждого изменения (SQL-запроса);
- строго предустановленный порядок изменений.
- чтобы любую версию базы данных можно было обновить до любой (обычно, самой последней) версии;
- чтобы набор SQL-запросов, реализующих миграцию между любыми двумя версиями, можно было получить как можно быстрее и проще;
- чтобы всегда можно было создать с нуля базу данных со структурой самой последней версии. Это очень полезно как в процессе разработки и тестирования, так и при развертывании нового продакшн-сервера;
- чтобы, в случае работы над разными ветками, при последующем их слиянии ручное редактирование файлов БД было сведено к минимуму;
- чтобы откатить БД на более раннюю версию было так же просто, как и обновить на более новую.
Основание миграции
Как оказалось, у большинства подходов есть общий принцип: им необходимо основание (baseline) - некоторое эталонное состояние БД, от которого можно отталкиваться. Эта концепция довольно хорошо описана в статье «Versioning Databases – The Baseline» Скотта Аллена.Попросту говоря, основание - это дамп структуры базы данных для версии, которая принята за базовую. Имея на руках основание , впоследствии всегда можно будет создать БД с нуля. После применения к этой БД всех миграций, созданных в процессе разработки, получим БД со структурой самой последней версии.
Метод инкрементных изменений
Этот метод хорошо описан в статье «Versioning Databases – Change Scripts» все того же Скотта Аллена. Схожий подход также описан в статье «Managing SQL scripts and continuous integration» Майкла Бэйлона.Структура файлов
Пример того, как в этом случае может выглядеть папка с файлами-миграциями:Database
|- Baseline.sql
|- 0001.03 .01.sql
|- 0002.03 .01.sql
|- 0003.03 .01.sql
|- 0004.03 .02.sql
|- 0005.03 .02.sql
|- 0006.03 .02.sql
"- 0007.03 .02.sql
В этом примере в папке хранятся все файлы, созданные при разработке версии 03 . Впрочем, папка может быть и общей для всех версий приложения.
В любом случае, самый первый файл, который появится в такой папке, - основание (Baseline.sql). После этого любое изменение в БД сабмиттится в репозиторий в виде нового файла-миграции с именем вида [номер файла].[версия].[подверсия].sql .
Фактически, в этом примере в имени файла содержится полный номер версии БД. То есть после выполнения файла-миграции с именем 0006 .03.02.sql база данных обновится с состояния, соответствующего версии 03.02.0005 , до версии 03.02.0006 .
Хранение истории версий
Следующий шаг - добавление в базу данных специальной таблицы, в которой будет храниться история всех изменений в базе данных.CREATE TABLE MigrationHistory
Id INT ,
MajorVersion VARCHAR (2),
MinorVersion VARCHAR (2),
FileNumber VARCHAR (4),
Comment VARCHAR (255),
DateApplied DATETIME ,PRIMARY KEY (Id)
)
Это всего лишь пример того, как может выглядеть таблица. При необходимости, её можно как упростить, так и дополнить.
В файле Baseline.sql в эту таблицу нужно будет добавить первую запись:
INSERT INTO
MigrationHistory (MajorVersion, MinorVersion, FileNumber, Comment, DateApplied)
VALUES ("03" , "01" , "0000" , "Baseline" , NOW())
После выполнения каждого файла-миграции в эту таблицу будет заноситься запись со всеми данными о миграции.
Текущую версию БД можно будет получить из записи с максимальной датой.
Автоматическое выполнение миграций
Завершающий штрих в этом подходе - программа/скрипт, который будет обновлять БД с текущей версии до последней.Выполнять миграцию БД автоматически довольно просто, т.к. номер последней выполненной миграции можно получить из таблицы MigrationHistory, а после этого остается только применить все файлы с бо́льшими номерами. Сортировать файлы можно по номеру, поэтому с порядком выполнения миграций проблем не будет.
На такой скрипт также возлагается задача добавления записей о выполненных миграциях в таблицу MigrationHistory.
В качестве дополнительных удобств, такой скрипт может уметь создавать текущую версию БД с нуля, сначала накатывая на БД основание , а затем выполняя стандартную операцию по миграции до последней версии.
Плюсы, минусы, выводы
Быстрое и удобное выполнение миграции до последней версии;Механизм нумерации версий. Номер текущей версии хранится прямо в БД;
Для максимального удобства нужны средства автоматизации выполнения миграций;
Неудобно добавлять комментарии к структуре БД. Если их добавлять в Baseline.sql, то в следующей версии они пропадут, т.к. основание будет сгенерировано с нуля вновь, в качестве дампа новой версии структуры. Вдобавок, такие комментарии будут быстро устаревать;
Возникают проблемы в процессе параллельной разработки в нескольких ветках репозитория. Так как нумерация файлов-миграций - последовательная, то под одинаковыми номерами в разных ветках могут возникнуть файлы с разными DDL-/DML-запросами. Как следствие, при слиянии веток придется либо вручную редактировать файлы и их последовательность, либо же в новой, «слитой» ветке начинать с нового Baseline.sql, учитывающего изменения из обеих веток.
Этот метод в различных формах довольно широко распространен. К тому же, он легко поддается упрощению и модификации под нужды проекта.
В интернете можно найти готовые варианты скриптов по инкрементному выполнению миграций и встроить в свой проект.
Метод идемпотентных изменений
Этот метод описан в статье «Bulletproof Sql Change Scripts Using INFORMATION_SCHEMA Views» Фила Хэка. Описание схожего подхода также изложено в ответе на этот вопрос на StackOverflow.Под идемпотентностью понимается свойство объекта оставаться неизменным при повторной попытке его изменить.
В тему вспоминается смешная сцена из «Друзей»:)
Основная идея этого подхода - написание миграционных файлов таким образом, чтобы их можно было выполнить на базе данных больше одного раза. При первой попытке выполнить любую из SQL-команд, изменения будут применены; при всех последующих попытках ничего не произойдет.
Эту идею проще всего уяснить на примере. Допустим, вам нужно добавить в БД новую таблицу. Если вы хотите, чтобы в том случае, если она уже существует, при выполнении запроса не возникло ошибки, - в MySQL для этих целей есть краткий синтаксис:
CREATE TABLE IF NOT EXISTS myTable
id INT (10) NOT NULL ,
PRIMARY KEY (id)
);
Благодаря ключевой фразе IF NOT EXISTS , MySQL попытается создать таблицу только в том случае, если таблицы с таким именем еще не существует. Однако такой синтаксис доступен не во всех СУБД; к тому же, даже в MySQL его можно использовать не для всех команд. Поэтому рассмотрим более универсальный способ:
IF NOT EXISTS
SELECT *
FROM information_schema.tables
WHERE table_name = "myTable"
AND table_schema = "myDb"
THEN
CREATE TABLE myTable
id INT (10) NOT NULL ,
myField VARCHAR (255) NULL ,
PRIMARY KEY (id)
);
END IF ;
В последнем примере роль параметра условного выражения играет запрос, который проверяет, существует ли таблица myTable в базе данных с именем myDb . И только в том случае, если таблица отсутствует, произойдет, собственно, ее создание. Таким образом, приведенный запрос является идемпотентным.
Стоит отметить, что в MySQL по какой-то причине запрещено выполнять DDL -запросы внутри условных выражений. Но этот запрет легко обойти - достаточно включить все подобные запросы в тело хранимой процедуры:
DELIMITER $$CREATE PROCEDURE sp_tmp() BEGIN
IF NOT EXISTS
--
-- Условие.
--
THEN
--
-- Запрос, изменяющий структуру БД.
--
END IF ;END ;
$$CALL sp_tmp();
DROP PROCEDURE sp_tmp;
Что за птица такая - information_schema?
Полную информацию о структуре базы данных можно получить из специальных системных таблиц, находящихся в базе данных с именем information_schema . Эта база данных и ее таблицы - часть стандарта SQL-92, поэтому этот способ можно использовать на любой из современных СУБД. В предыдущем примере используется таблица information_schema.tables , в которой хранятся данные о всех таблицах. Подобным образом можно проверять существование и метаданные полей таблиц, хранимых процедур, триггеров, схем, и, фактически, любых других объектов структуры базы данных.Полный перечень таблиц с подробной информацией об их предназначении можно посмотреть в тексте стандарта . Краткий перечень можно увидеть в уже упоминавшейся выше статье Фила Хэка . Но самый простой способ, конечно же, - просто открыть эту базу данных на любом рабочем сервере БД и посмотреть, как она устроена.
Пример использования
Итак, вы знаете, как создавать идемпотентные SQL-запросы. Теперь рассмотрим, как этот подход можно использовать на практике.Пример того, как в этом случае может выглядеть папка с sql-файлами:
Database
|- 3.01
| |- Baseline.sql
| "- Changes.sql
"- 3.02
|- Baseline.sql
"- Changes.sql
В этом примере для каждой минорной версии базы данных создается отдельная папка. При создании каждой новой папки генерируется основание и записывается в Baseline.sql. Затем в процессе разработки в файл Changes.sql записываются все необходимые изменения в виде идемпотентных запросов.
Предположим, в процессе разработки в разное время программистам понадобились следующие изменения в БД:
a) создать таблицу myTable;
b) добавить в нее поле newfield;
c) добавить в таблицу myTable какие-то данные.
Все три изменения написаны так, чтобы не выполняться повторно. В результате, в каком бы из промежуточных состояний не находилась база данных, при выполнении файла Changes.sql всегда будет выполнена миграция до самой последней версии.
К примеру, один из разработчиков создал на своей локальной копии БД таблицу myTable, записал изменение a) в хранящийся в общем репозитории кода файл Changes.sql, и на какое-то время забыл о нём. Теперь, если он выполнит этот файл на своей локальной БД, изменение a) будет проигнорировано, а изменения b) и c) будут применены.
Плюсы, минусы, выводы
Очень удобное выполнение миграций с любой промежуточной версии до последней - нужно всего лишь выполнить на базе данных один файл (Changes.sql);Потенциально возможны ситуации, в которых будут теряться данные, за этим придется следить. Примером может служить удаление таблицы, и затем создание другой таблицы с тем же именем. Если при удалении проверять только имя, то обе операции (удаление и создание) будут происходить каждый раз при выполнении скрипта, несмотря на то, что когда-то уже выполнялись;
Для того, чтобы изменения были идемпотентными, нужно потратить больше времени (и кода) на их написание.
Благодаря тому, что обновить базу данных до последней версии очень просто, и делать это можно вручную, этот метод показывает себя в выгодном свете в том случае, если у вас много продакшн-серверов и их нужно часто обновлять.
Метод уподобления структуры БД исходному коду
Отдельных статей, посвященных этому подходу, я, к сожалению, не нашел. Буду благодарен за ссылки на существующие статьи, если таковые имеются. UPD: В своей статье Absent рассказывает о своем опыте реализации схожего подхода при помощи самописной diff-утилиты.Основная идея этого метода отражена в заголовке: структура БД - такой же исходный код, как код PHP, C# или HTML. Следовательно, вместо того, чтобы хранить в репозитории кода файлы-миграции (с запросами, изменяющими структуру БД), нужно хранить только актуальную структуру базы данных - в декларативной форме.
Пример реализации
Для простоты примера будем считать, что в каждой ревизии репозитория всегда будет только один SQL-файл: CreateDatabase.sql. В скобках замечу, что в аналогии с исходным кодом можно пойти еще дальше и хранить структуру каждого объекта БД в отдельном файле. Также, структуру можно хранить в виде XML или других форматов, которые поддерживаются вашей СУБД.В файле CreateDatabase.sql будут храниться команды CREATE TABLE , CREATE PROCEDURE , и т.д., которые создают всю базу данных с нуля. При необходимости изменений структуры таблиц, эти изменения вносятся непосредственно в существующие DDL-запросы создания таблиц. То же касается изменений в хранимых процедурах, триггерах, и т.д.
К примеру, в текущей версии репозитория уже есть таблица myTable, и в файле CreateDatabase.sql она выглядит следующим образом:
CREATE TABLE myTable
id INT (10) NOT NULL ,
myField VARCHAR (255) NULL ,
PRIMARY KEY (id)
);
Если вам нужно добавить в эту таблицу новое поле, вы просто добавляете его в имеющийся DDL-запрос:
CREATE TABLE myTable
id INT (10) NOT NULL ,
myField VARCHAR (255) NULL ,
newfield INT(4) NOT NULL ,
PRIMARY KEY (id)
);
После этого измененный sql-файл сабмиттится в репозиторий кода.
