Миграция данных: процесс, типы и золотые правила

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

Однако многие компании рассматривают даже массовую миграцию данных как низкоуровневую задачу, выполняемую в два клика. Такая первоначальная недооценка приводит к дополнительным расходам времени и денег. Недавние исследования показали, что 55 процентов проектов миграции данных превышали бюджет, а 62 процента оказались сложнее, чем ожидалось, или фактически потерпели неудачу.

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

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

Что такое миграция данных?

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

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

модернизация или замена устаревшего программного обеспечения ,
расширение системы и емкости хранения,
внедрение дополнительной системы, работающей параллельно с существующим приложением,
переход к централизованной базе данных для устранения разрозненности данных и обеспечения взаимодействия ,
перенос ИТ-инфраструктуры в облако, или
слияния и поглощения (M&A), когда ИТ-ландшафты должны быть объединены в единую систему.

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

Миграция данных против интеграции данных

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

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

Миграция данных против репликации данных

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

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

Теперь мы обсудим только миграцию данных – разовый и односторонний процесс переезда в новый дом, оставляя старый пустым.

Основные типы миграции данных

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

Миграция хранилища

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

Примеры таких миграций: перенос данных

от бумажных до цифровых документов,
от жестких дисков (HDD) до более быстрых и надежных твердотельных накопителей (SSD) или
от мэйнфреймов до облачного хранилища.

Основная причина этого перехода – насущная потребность в модернизации технологий, а не недостаток места для хранения. Когда дело доходит до крупномасштабных систем, процесс миграции может занять годы. Скажем, Sabre, вторая по величине глобальная распределительная система (GDS), уже более десяти лет переносит свое программное обеспечение и данные с мэйнфреймов на виртуальные серверы. Ожидается, что его миграционный период будет полностью завершен в 2023 году.

Перенос базы данных

База данных – это не просто место для хранения данных. Он обеспечивает структуру для организации информации определенным образом и обычно управляется через систему управления базами данных (СУБД). Итак, в большинстве случаев миграция базы данных означает

обновление до последней версии СУБД (т.н. однородная миграция ),
переход на новую СУБД от другого провайдера – например, с MySQL на PostgreSQL или с Oracle на MSSQL (так называемая гетерогенная миграция )

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

Перенос приложений

Когда компания меняет поставщика корпоративного программного обеспечения – например, отель внедряет новую систему управления имуществом или больница заменяет свою устаревшую систему EHR – это требует перемещения данных из одной вычислительной среды в другую. Ключевой проблемой здесь является то, что старая и новая инфраструктуры могут иметь уникальные модели данных и работать с разными форматами данных.

Миграция центра обработки данных

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

Миграция бизнес-процессов

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

Миграция в облако

Миграция в облако – популярный термин, охватывающий все вышеупомянутые случаи, если они связаны с перемещением данных из локальной среды в облако или между различными облачными средами. Gartner ожидает, что к 2024 году облако привлечет более 45 процентов ИТ-расходов и будет доминировать над постоянно растущим числом ИТ-решений.

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

Подходы к миграции данных

Выбор правильного подхода к миграции – это первый шаг к обеспечению бесперебойной работы проекта без серьезных задержек.

Миграция данных большого взрыва

Преимущества: менее затратный, менее сложный, занимает меньше времени, все изменения происходят один раз

Недостатки: высокий риск дорогостоящего отказа, требует простоя.

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

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

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

Вердикт. Подход большого взрыва подходит для небольших компаний или предприятий, работающих с небольшими объемами данных. Это не работает для критически важных приложений, которые должны быть доступны 24/7.

Тонкая миграция данных

Преимущества: меньшая подверженность неожиданным сбоям, нулевое время простоя

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

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

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

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

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

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

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

Процесс миграции данных

Независимо от подхода, проект миграции данных проходит одни и те же ключевые фазы, а именно:

планирование
аудит и профилирование данных,
резервное копирование данных,
дизайн миграции,
казнь
тестирование и
постмиграционный аудит.

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

Планирование: составьте план переноса данных и придерживайтесь его

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

Шаг 1 – уточните объем. Ключевая цель этого шага – отфильтровать любые избыточные данные и определить минимальный объем информации, необходимый для эффективной работы системы. Таким образом, вам необходимо провести высокоуровневый анализ исходной и целевой систем, проконсультировавшись с пользователями данных, на которых непосредственно повлияют предстоящие изменения.

Шаг 2 – оцените исходную и целевую системы. План перехода должен включать тщательную оценку операционных требований текущей системы и способов их адаптации к новой среде.

Шаг 3 – установите стандарты данных. Это позволит вашей команде выявлять проблемные области на каждом этапе процесса миграции и избегать неожиданных проблем на этапе после миграции.

Шаг 4 – оцените бюджет и установите реалистичные сроки. После уточнения объема работ и оценки систем легче выбрать подход (большой взрыв или тонкая струйка), оценить ресурсы, необходимые для проекта, установить графики и сроки. Согласно Oracle оценок, предприятие масштаб миграции данных проект длится от шести месяцев до двух лет в среднем.

Аудит и профилирование данных: используйте цифровые инструменты

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

Аудит и профилирование – утомительная, трудоемкая и трудоемкая деятельность, поэтому в крупных проектах следует использовать инструменты автоматизации. Среди популярных решений – Open Studio for Data Quality, Data Ladder, SAS Data Quality, Informatica Data Quality и IBM InfoSphere QualityStage, и это лишь некоторые из них.

Резервное копирование данных: защитите свой контент перед его перемещением

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

Дизайн миграции: наймите специалиста по ETL

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

Хотя для переноса данных можно использовать несколько технологий, предпочтительным является извлечение, преобразование и загрузка (ETL). Имеет смысл нанять разработчика ETL или специального инженера-программиста с глубокими знаниями в процессах ETL, особенно если ваш проект имеет дело с большими объемами данных и сложным потоком данных.

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

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

Исполнение: фокус на бизнес-целях и удовлетворенности клиентов

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

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

Тестирование миграции данных: проверка качества данных на разных этапах

Фактически, тестирование не является отдельным этапом, поскольку оно проводится на этапах проектирования, выполнения и после миграции. Если вы выбрали капельный подход, вам следует протестировать каждую часть перенесенных данных, чтобы своевременно устранить проблемы.

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

Пост-миграционный аудит: подтверждение результатов с ключевыми клиентами

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

Золотые правила миграции данных

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

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

Миграция данных часто рассматривается как неизбежное зло, а не как процесс добавления ценности. И это, кажется, корень многих, если не всех трудностей. Рассмотрение миграции как важного инновационного проекта, заслуживающего особого внимания, – это половина дела.