Share to: share facebook share twitter share wa share telegram print page

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

Міграція даних — це процес вибору, підготовки, вилучення та перетворення даних і постійного перенесення їх з однієї комп'ютерної системи зберігання в іншу. Крім того, перевірка повноти перенесених даних і виведення з експлуатації застарілого сховища даних вважаються частиною всього процесу міграції даних.[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. ↑ а б в г Morris, J. (2012). Chapter 1: Data Migration: What's All the Fuss?. Practical Data Migration (вид. 2nd). BCS Learning & Development Ltd. с. 7—15. ISBN 9781906124847.
  2. ↑ а б в г д е Dufrasne, B.; Warmuth, A.; Appel, J. (2017). Chapter 1: Introducing disk data migration. DS8870 Data Migration Techniques. IBM Redbooks. с. 1—16. ISBN 9780738440606. Архів оригіналу за 27 серпня 2021. Процитовано 30 січня 2022.
  3. ↑ King, T. (17 серпня 2016). Data Integration vs. Data Migration; What's the Difference?. Solutions Review - Data Integration. LeadSpark, Inc. Архів оригіналу за 21 липня 2018. Процитовано 20 липня 2018.
  4. ↑ Seiwert, C.; Klee, P.; Marinez, L. (2012). Chapter 2: Migration techniques and processes. Data Migration to IBM Disk Storage Systems. IBM Redbooks. с. 7—30. ISBN 9780738436289.
  5. ↑ Fowler, M.; Beck, K.; Brant, J. (2012). Refactoring: Improving the Design of Existing Code. Addison-Wesley. с. 63—4. ISBN 9780133065268. Архів оригіналу за 30 січня 2022. Процитовано 30 січня 2022.
  6. ↑ Fronc, A. (1 березня 2015). Database-agnostic applications. DBA Presents. Архів оригіналу за 20 липня 2018. Процитовано 20 липня 2018.
  7. ↑ Plivna, G. (1 липня 2006). Data migration from old to new application: An experience. gplivna.eu. Архів оригіналу за 17 липня 2018. Процитовано 20 липня 2018.
  8. ↑ Ortac, Alper; Monperrus, Martin; Mezini, Mira (2015). Abmash: mashing up legacy Web applications by automated imitation of human actions (PDF). Software: Practice and Experience. 45 (5): 581—612. doi:10.1002/spe.2249. ISSN 0038-0644. Архів оригіналу (PDF) за 30 січня 2022. Процитовано 30 січня 2022.
  9. ↑ а б Allen, M.; Cervo, D. (2015). Multi-Domain Master Data Management: Advanced MDM and Data Governance in Practice. Morgan Kaufmann. с. 61—2. ISBN 9780128011478. Архів оригіналу за 30 січня 2022. Процитовано 30 січня 2022.
  10. ↑ van der Hoeven, Jeffrey; Bram Lohman; Remco Verdegem (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. Процитовано 30 січня 2022.
Kembali kehalaman sebelumnya