Перенос данных - Data migration

Не путать с Миграция схемы.

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

Стандартные фазы

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

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

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

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

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

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

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

Категории

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

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

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

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

Основная статья: Миграция схемы

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

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

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

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

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

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

Миграция как форма цифрового сохранения

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

Недостатки

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

Смотрите также

Рекомендации

  1. ^ а б c d е Моррис, Дж. (2012). «Глава 1: Миграция данных: в чем вся суета?». Практическая миграция данных (2-е изд.). BCS Learning & Development Ltd., стр. 7–15. ISBN  9781906124847.
  2. ^ а б c d е ж грамм час Dufrasne, B .; Warmuth, A .; Appel, J .; и другие. (2017). «Глава 1: Введение в миграцию данных с диска». Методы переноса данных DS8870. IBM Redbooks. С. 1–16. ISBN  9780738440606.
  3. ^ Ховард, П. (23 августа 2011 г.). «Отчет о миграции данных - 2011». Bloor Research International Limited. Получено 20 июля 2018.
  4. ^ Кинг, Т. (17 августа 2016 г.). «Интеграция данных против миграции данных; в чем разница?». Обзор решений - интеграция данных. LeadSpark, Inc. Получено 20 июля 2018.
  5. ^ Seiwert, C .; Klee, P .; Marinez, L .; и другие. (2012). «Глава 2: Методы и процессы миграции». Перенос данных в IBM Disk Storage Systems. IBM Redbooks. С. 7–30. ISBN  9780738436289.
  6. ^ Fowler, M .; Beck, K .; Brant, J .; и другие. (2012). Рефакторинг: улучшение дизайна существующего кода. Эддисон-Уэсли. С. 63–4. ISBN  9780133065268.
  7. ^ Фронк, А. (1 марта 2015 г.). "Приложения, не зависящие от базы данных". DBA представляет. Получено 20 июля 2018.
  8. ^ Пливна, Г. (1 июля 2006 г.). «Перенос данных из старого приложения в новое: опыт». gplivna.eu. Получено 20 июля 2018.
  9. ^ Ортак, Альпер; Монперрус, Мартин; Мезини, Мира (2015). «Абмаш: объединение устаревших веб-приложений путем автоматической имитации действий человека» (PDF). Программное обеспечение: практика и опыт. 45 (5): 581–612. Дои:10.1002 / spe.2249. ISSN  0038-0644. S2CID  16940486.
  10. ^ а б Allen, M .; Черво, Д. (2015). Многодоменное управление основными данными: продвинутое MDM и управление данными на практике. Морган Кауфманн. С. 61–2. ISBN  9780128011478.
  11. ^ ван дер Хувен, Джеффри; Брэм Ломан; Ремко Вердегем (2007). «Эмуляция для цифрового хранения на практике: результаты». Международный журнал цифрового курирования. 2 (2): 123–132. Дои:10.2218 / ijdc.v2i2.35.
  12. ^ Муира, Грегори (2007). «Расширяя границы политики традиционного наследия: поддержание долгосрочного доступа к мультимедийному контенту» (PDF). Журнал ИФЛА. 33 (4): 323–326. Дои:10.1177/0340035207086058. S2CID  110505620.

внешняя ссылка