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