Миграция данных

Материал из Циклопедии
Перейти к навигации Перейти к поиску

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

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

Стандартные фазы[править]

По состоянию на 2011 год, «почти 40 процентов проектов миграции данных были с задержкой, превысили бюджет или полностью провалились». Таким образом, для эффективной миграции данных важное значение имеет правильное планирование. Хотя особенности плана миграции данных могут отличаться — иногда значительно — от проекта к проекту, компьютерная компания IBM считает, что большинство проектов миграции данных имеет три основных фазы: планирование, миграция и пост-миграция. Каждая из этих фаз имеет свои шаги. Во время планирования анализируются зависимости и требования, разрабатываются и тестируются сценарии миграции, а также создается план проекта, содержащий предварительную информацию. Во время фазы миграции план вводится в действие, а во время пост-миграции полнота и тщательность миграции проверяется, документируется, закрывается, включая любой необходимый вывод из эксплуатации устаревших систем. Для программ от средней до высокой сложности эти этапы миграции данных могут повторяться несколько раз, прежде чем новая система будет считаться полностью проверенной и развернутой.

Планирование: данные, приложения и т.д., которые будут перенесены, выбираются на основе бизнес-, проектных, технических требований и зависимостей. Анализируются требования к оборудованию и пропускной способности. Разработаны возможные сценарии миграции и возврата, а также соответствующие тесты, сценарии автоматизации, отображение и процедуры. Требования к очистке и преобразованию данных также определяются для форматов данных, чтобы улучшить качество данных и устранить лишнюю или устаревшую информацию. Решается и разрабатывается архитектура миграции, получены все необходимые лицензии на программное обеспечение и запущены процессы управления изменениями[1][2].

Миграция: требования к аппаратному и программному обеспечению проверяются, а процедуры миграции настраиваются в соответствии с потребностями. Также может происходить определенный вид предварительного тестирования, чтобы обеспечить надлежащее функционирование требований и настроенных параметров. Если все в порядке, начинается миграция, включая первичные акты извлечения данных, когда данные считываются со старой системы, и загрузки данных, когда данные записываются в новую систему. Дополнительные шаги проверки обеспечивают полное выполнение разработанного плана миграции[1][2].

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

Проект против процесса

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

Интеграция данных, напротив, является постоянной частью ИТ-архитектуры и отвечает за то, как данные потоки между различными приложениями и хранилищами данных — и является процессом, а не проектной деятельностью. Стандартные технологии ETL, предназначенные для доставки данных из операционных систем в хранилища данных, подойдут к последней категории[3].

Категории[править]

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

Миграция хранилища[править]

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

Миграция базы данных[править]

Аналогично, может потребоваться перейти от одного поставщика базы данных к другому или обновить версию используемого программного обеспечения базы данных. В последнем случае менее вероятно, что потребуется физическая миграция данных, но это может произойти с серьезными обновлениями. В этих случаях может потребоваться процесс физического преобразования, поскольку основной формат данных может значительно измениться. Это может повлиять или не повлиять на поведение на прикладном уровне, в основном в зависимости от того, изменились ли язык или протокол манипулирования данными[5]. Однако некоторые современные программы написаны так, что почти полностью не зависят от технологии баз данных[6], поэтому переход с Sybase, MySQL, DB2 или SQL Server на Oracle должен потребовать лишь цикла тестирования, чтобы убедиться, что как функциональная, так и нефункциональная производительность не пострадала.

Миграция приложений[править]

Смена поставщика программы — например, новой платформы CRM или ERP — неизбежно повлечет за собой значительную трансформацию, поскольку почти каждая программа или пакет работает на своей собственной специфической модели данных, а также взаимодействует с другими программами и системами в среде интеграции корпоративных программ[7]. Кроме того, чтобы разрешить продажу программы на как можно более широком рынке, коммерческие готовые пакеты обычно настраиваются для каждого клиента с помощью метаданных. Интерфейсы прикладного программирования (API) могут предоставляться поставщиками для защиты целостности данных, которые они должны обрабатывать. Также можно создать сценарий для веб-интерфейсов поставщиков для автоматического переноса данных[8].

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

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

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

Миграция как форма цифрового сохранения[править]

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

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

Примечания[править]

  1. ↑ 1,0 1,1 1,2 1,3 Morris, J. Chapter 1: Data Migration: What's All the Fuss? // Practical Data Migration. — 2nd. — BCS Learning & Development Ltd, 2012. — P. 7–15. — ISBN 9781906124847.
  2. ↑ 2,0 2,1 2,2 2,3 2,4 2,5 Dufrasne, B., Warmuth, A. Chapter 1: Introducing disk data migration // DS8870 Data Migration Techniques. — IBM Redbooks, 2017. — P. 1–16. — ISBN 9780738440606.
  3. ↑ King, T. Data Integration vs. Data Migration; What's the Difference?. LeadSpark, Inc (17 серпня 2016). Архивировано из первоисточника 21 липня 2018. Проверено 20 липня 2018.
  4. ↑ Seiwert, C., Klee, P. Chapter 2: Migration techniques and processes // Data Migration to IBM Disk Storage Systems. — IBM Redbooks, 2012. — P. 7–30. — ISBN 9780738436289.
  5. ↑ Fowler, M., Beck, K. Refactoring: Improving the Design of Existing Code. — Addison-Wesley, 2012. — P. 63–4. — ISBN 9780133065268.
  6. ↑ Fronc, A. Database-agnostic applications. DBA Presents (1 березня 2015). Архивировано из первоисточника 20 липня 2018. Проверено 20 липня 2018.
  7. ↑ Plivna, G. Data migration from old to new application: An experience. gplivna.eu (1 липня 2006). Архивировано из первоисточника 17 липня 2018. Проверено 20 липня 2018.
  8. ↑ Ortac, Alper (2015). «Abmash: mashing up legacy Web applications by automated imitation of human actions». Software: Practice and Experience 45 (5): 581–612. DOI:10.1002/spe.2249. ISSN 0038-0644. Проверено 30 січня 2022.
  9. ↑ 9,0 9,1 Allen, M., Cervo, D. Multi-Domain Master Data Management: Advanced MDM and Data Governance in Practice. — Morgan Kaufmann, 2015. — P. 61–2. — ISBN 9780128011478.
  10. ↑ van der Hoeven, Jeffrey (2007). «Emulation for Digital Preservation in Practice: The Results». The International Journal of Digital Curation 2 (2): 123–132. DOI:10.2218/ijdc.v2i2.35. Проверено 30 січня 2022.
Руниверсалис

Одним из источников, использованных при создании данной статьи, является статья из википроекта «Руниверсалис» («Руни», руни.рф) под названием «Миграция данных», расположенная по адресу:

—«https://руни.рф/index.php/Миграция_данных»

Материал указанной статьи полностью или частично использован в Циклопедии по лицензии CC BY-SA.

Всем участникам Руниверсалиса предлагается прочитать «Обращение к участникам Руниверсалиса» основателя Циклопедии и «Почему Циклопедия?».

Источник — http://cyclowiki.org/w/index.php?title=Миграция_данных&oldid=2229633