Data Migration — суть, методи та процес перенесення даних

Що таке Data Migration

Data Migration — це процес перенесення даних з одного джерела в інше із забезпеченням їх цілісності, консистентності та доступності після завершення. На відміну від простого копіювання, міграція включає трансформацію форматів, очищення дублікатів, перевірку посилальної цілісності та валідацію результату.

Потреба в Data Migration виникає при оновленні СКБД (наприклад, з MySQL 5.7 на MySQL 8.0), зміні хмарного провайдера, міграції з моноліту на мікросервіси або при переході на NoSQL-схему. За даними Stripe (2024), 89% компаній стикаються з міграцією даних хоча б раз на два роки, а 43% визнають її найскладнішим етапом технічного оновлення.

Основні цілі міграції даних

Перша ціль — підвищення продуктивності за рахунок переходу на більш сучасне рішення зберігання. Друга — зниження операційних витрат при зміні постачальника інфраструктури. Третя — забезпечення відповідності регуляторним вимогам (GDPR, 152-ФЗ), коли дані повинні зберігатися в певній юрисдикції.

Чим міграція відрізняється від інтеграції

Інтеграція передбачає постійну синхронізацію між двома працюючими системами. Міграція — одноразове перенесення з подальшим вимкненням джерела. Інтеграція не видаляє дані в джерелі, міграція завершується переведенням системи-приймача в статус primary. Ця принципова відмінність визначає вибір інструментів та підходів до валідації.

ETL-модель міграції даних

Базова архітектура будь-якої Data Migration будується на моделі ETL (Extract, Transform, Load). Extract — вилучення даних із джерела. Transform — перетворення під цільову схему. Load — завантаження в приймач. Кожна фаза має власні методи контролю якості.

Extract: вилучення даних

На етапі вилучення дані читаються з вихідної бази, файлового сховища або API. Інкрементальне вивантаження (CDC — Change Data Capture) дозволяє переносити лише змінені записи, скорочуючи обсяг трафіку. Повний дамп підходить для малих обсягів, але для терабайтних баз краще потокова реплікація через Debezium або Kafka Connect.

Transform: перетворення схеми

Перетворення включає перейменування колонок, зміну типів даних, нормалізацію значень та агрегацію. Наприклад, при міграції з MySQL на PostgreSQL числовий тип DECIMAL потрібно привести до NUMERIC, а формат дат — до ISO 8601. За даними Talend (2024), 70% часу міграції витрачається саме на трансформацію, а не на перенесення.

Load: завантаження в приймач

Завантаження виконується пакетами (batch insert) або потоково. Для виключення дублікатів використовується ключ ідемпотентності. Після завантаження обов'язковий крок валідації: порівняння кількості записів, підрахунок контрольних сум та перевірка бізнес-правил. Без валідації Data Migration вважається незавершеною.

Стратегії міграції даних

Вибір стратегії Data Migration визначає час простою системи, складність відкату та обсяг підготовчих робіт. Основні стратегії — Big Bang, Trickle та Parallel Run. Кожна застосовна в різних сценаріях.

Міграція Big Bang

Big Bang — одномоментне вимкнення старої системи, перенесення даних та ввімкнення нової. Підходить для невеликих обсягів та простих схем. Ризик: при збої система недоступна до повного відновлення з бекапу. У 2024 році GitLab використала Big Bang для міграції 5 ТБ даних з AWS RDS на GCP Cloud SQL з вікном простою 14 годин.

Міграція Trickle

Trickle — потокова синхронізація невеликими порціями. Стара та нова системи працюють паралельно, зміни реплікуються в реальному часі. Після стабілізації даних старе джерело вимикається. Цей підхід потребує двосторонньої синхронізації та вирішення конфліктів. Використовується в Continuous Delivery при оновленні схеми БД без downtime.

Parallel Run

Parallel Run — обидві системи працюють одночасно, застосунок пише та читає з обох джерел. Після верифікації даних на приймачі старе джерело вимикається. Це найбезпечніша стратегія, але й найдорожча — потребує підтримки двох інфраструктур. Застосовується при міграції критичних фінансових систем.

Типи міграції даних

У розробці застосунків розрізняють кілька типів Data Migration за об'єктом перенесення та контекстом. Кожен тип має власну методологію та інструменти. Розуміння типу — перший крок до вибору коректної стратегії.

Міграція бази даних (Database Migration)

Database Migration — перенесення між СКБД різних вендорів: з Oracle на PostgreSQL, з SQL Server на MySQL, з MongoDB на DynamoDB. Складність полягає в несумісності типів даних, діалектів SQL та механізмів індексації. Інструменти: AWS DMS, Debezium, Liquibase.

Міграція даних застосунку (Application Data Migration)

Перенесення даних між різними версіями одного застосунку — наприклад, при оновленні коду зі зміною структури сутностей. Часто супроводжується виконанням скриптів міграції мовою застосунку: Active Record Migrations у Ruby on Rails, Flyway для Java, Entity Framework Migrations у .NET. Ці скрипти послідовно трансформують схему та дані.

Хмарна міграція (Cloud Data Migration)

Cloud Data Migration — перенесення даних з on-premise інфраструктури в хмару або між хмарами. AWS Snowball, Azure Data Box та Google Transfer Appliance використовуються для фізичного перевезення терабайтних масивів. Для онлайн-міграції застосовуються VPN-тунелі та реплікація. За даними Gartner, до 2027 року 70% міграцій виконуватимуться в гібридному хмарному середовищі.

Планування міграції даних

Data Migration без плану — гарантований збій. Планування включає аудит поточної схеми, профілювання даних, вибір стратегії, підготовку середовища, тестування та затвердження плану відкату. За даними дослідження McKinsey (2024), 54% невдалих міграцій спричинені відсутністю формального плану.

Аудит та профілювання

Перед міграцією необхідно виконати аудит source-системи: визначити обсяг даних, кількість таблиць, залежності між сутностями, типи nullable-полів та наявність дублікатів. Профілювання виявляє аномалії — NULL-значення в ключових полях, невідповідність форматів, биті посилання. Ці дані формують baseline повного дампу.

Підготовка тестового середовища

Тестова міграція виконується на копії продакшен-даних до запуску основної. Мета — перевірити продуктивність ETL-пайплайну, коректність трансформації та швидкість завантаження. Рекомендується мінімум три повних цикли тестування перед Big Bang. Кожен цикл включає повне перенесення, валідацію та відкат.

План відкату (Rollback)

Відкат — повернення до вихідної системи при виявленні критичних помилок. План відкату включає: повний бекап source перед стартом, скрипти відновлення схеми, покрокову інструкцію ввімкнення старої системи та комунікаційний план оповіщення користувачів. Без затвердженого плану відкату Data Migration не повинна запускатися в продакшен.

Приклади коду міграції даних

Розглянемо практичний приклад Data Migration на Kotlin у зв'язці з Flyway. Скрипт міграції V1 створює таблицю users та переносить дані з legacy-формату. Flyway автоматично відстежує застосовані міграції та гарантує ідемпотентність.

// V1__Migrate_Users.kt — міграція даних з legacy-формату
import org.flywaydb.core.api.migration.BaseJavaMigration
import java.sql.Connection
import java.sql.PreparedStatement

class V1__MigrateUsers : BaseJavaMigration() {
    override fun migrate(connection: Connection) {
        val legacyUsers = connection.prepareStatement(
            "SELECT id, name, legacy_role FROM users_legacy"
        ).executeQuery()

        val insertStmt: PreparedStatement = connection.prepareStatement(
            "INSERT INTO users (id, name, role, migrated_at) VALUES (?, ?, ?, NOW())"
        )

        while (legacyUsers.next()) {
            insertStmt.setInt(1, legacyUsers.getInt("id"))
            insertStmt.setString(2, legacyUsers.getString("name"))
            val role = mapLegacyRole(legacyUsers.getString("legacy_role"))
            insertStmt.setString(3, role)
            insertStmt.executeUpdate()
        }
    }
}

Приклад міграції на Python з використанням SQLAlchemy для перенесення даних з CSV до PostgreSQL. Скрипт виконує вилучення з файлу, приводить типи та завантажує цільові таблиці.

# migrate_data.py — завантаження CSV у PostgreSQL з трансформацією
import pandas as pd
from sqlalchemy import create_engine

engine = create_engine("postgresql://user:pass@host/db")
df = pd.read_csv("legacy_orders.csv")

df["order_date"] = pd.to_datetime(df["order_date"])
df["amount"] = df["amount"].astype("float")
df.to_sql("orders", engine, if_exists="append", index=False)

print("Міграцію даних завершено")