Data Migration — podstata, metody a proces přenosu dat

Co je Data Migration

Data Migration je proces přenosu dat z jednoho zdroje do druhého s zajištěním jejich integrity, konzistence a dostupnosti po dokončení. Na rozdíl od prostého kopírování zahrnuje migrace transformaci formátů, čištění duplicit, kontrolu referenční integrity a validaci výsledku.

Potřeba Data Migration vzniká při aktualizaci SŘBD (např. z MySQL 5.7 na MySQL 8.0), změně cloudového poskytovatele, migraci z monolitu na mikroslužby nebo při přechodu ze schématu na NoSQL. Podle Stripe (2024) se 89 % společností setkává s migrací dat alespoň jednou za dva roky a 43 % ji považuje za nejobtížnější fázi technické aktualizace.

Hlavní cíle migrace dat

Prvním cílem je zvýšení výkonu přechodem na modernější úložné řešení. Druhým — snížení provozních nákladů změnou poskytovatele infrastruktury. Třetím — zajištění souladu s regulatorními požadavky (GDPR, 152-FZ), když data musí být uložena v určité jurisdikci.

Čím se migrace liší od integrace

Integrace předpokládá trvalou synchronizaci mezi dvěma fungujícími systémy. Migrace — jednorázový přenos s následným vypnutím zdroje. Integrace neodstraňuje data ve zdroji, migrace končí přepnutím přijímacího systému do stavu primary. Tento zásadní rozdíl určuje výběr nástrojů a přístupů k validaci.

Model ETL migrace dat

Základní architektura každé Data Migration je postavena na modelu ETL (Extract, Transform, Load). Extract — extrakce dat ze zdroje. Transform — transformace na cílové schéma. Load — načtení do přijímače. Každá fáze má vlastní metody kontroly kvality.

Extract: extrakce dat

Ve fázi extrakce jsou data čtena z zdrojové databáze, úložiště souborů nebo API. Inkrementální vývoz (CDC — Change Data Capture) umožňuje přenášet pouze změněné záznamy, čímž se snižuje objem provozu. Úplný dump je vhodný pro malé objemy, ale pro terabajtové databáze je preferována průběžná replikace prostřednictvím Debezium nebo Kafka Connect.

Transform: transformace schématu

Transformace zahrnuje přejmenování sloupců, změnu datových typů, normalizaci hodnot a agregaci. Například při migraci z MySQL na PostgreSQL je třeba číselný typ DECIMAL převést na NUMERIC a formát dat na ISO 8601. Podle Talend (2024) je 70 % času migrace věnováno transformaci, nikoli přenosu.

Load: načtení do přijímače

Načtení se provádí v dávkách (batch insert) nebo proudově. Pro eliminaci duplicit se používá klíč idempotence. Po načtení je povinný krok validace: porovnání počtu záznamů, výpočet kontrolních součtů a kontrola obchodních pravidel. Bez validace je Data Migration považována za neúplnou.

Strategie migrace dat

Volba strategie Data Migration určuje dobu prostoje systému, složitost vrácení a rozsah přípravných prací. Hlavní strategie — Big Bang, Trickle a paralelní spuštění (Parallel Run). Každá je použitelná v různých scénářích.

Migrace Big Bang

Big Bang — jednorázové vypnutí starého systému, přenos dat a zapnutí nového. Vhodné pro malé objemy a jednoduchá schémata. Riziko: při selhání je systém nedostupný až do úplného obnovení ze zálohy. V roce 2024 GitLab použila Big Bang pro migraci 5 TB dat z AWS RDS na GCP Cloud SQL s oknem prostoje 14 hodin.

Migrace Trickle

Trickle — průběžná synchronizace v malých dávkách. Starý a nový systém pracují paralelně, změny jsou replikovány v reálném čase. Po stabilizaci dat je starý zdroj vypnut. Tento přístup vyžaduje obousměrnou synchronizaci a řešení konfliktů. Používá se v Continuous Delivery při aktualizaci schématu databáze bez prostojů.

Parallel Run

Parallel Run — oba systémy pracují současně, aplikace zapisuje a čte z obou zdrojů. Po ověření dat v přijímači je starý zdroj vypnut. Toto je nejbezpečnější strategie, ale také nejdražší — vyžaduje údržbu dvou infrastruktur. Používá se při migraci kritických finančních systémů.

Typy migrace dat

Při vývoji aplikací se rozlišuje několik typů Data Migration podle objektu přenosu a kontextu. Každý typ má vlastní metodologii a nástroje. Pochopení typu je prvním krokem k výběru správné strategie.

Migrace databáze (Database Migration)

Database Migration — přenos mezi SŘBD různých dodavatelů: z Oracle na PostgreSQL, z SQL Server na MySQL, z MongoDB na DynamoDB. Složitost spočívá v nekompatibilitě datových typů, SQL dialektů a indexačních mechanismů. Nástroje: AWS DMS, Debezium, Liquibase.

Migrace dat aplikace (Application Data Migration)

Přenos dat mezi různými verzemi stejné aplikace — například při aktualizaci kódu se změnou struktury entit. Často je doprovázen spouštěním migračních skriptů v jazyce aplikace: Active Record Migrations v Ruby on Rails, Flyway pro Java, Entity Framework Migrations v .NET. Tyto skripty postupně transformují schéma a data.

Cloudová migrace (Cloud Data Migration)

Cloud Data Migration — přenos dat z on-premise infrastruktury do cloudu nebo mezi cloudovými platformami. AWS Snowball, Azure Data Box a Google Transfer Appliance se používají pro fyzický přepravu terabajtových objemů. Pro online migraci se používají VPN tunely a replikace. Podle Gartner bude do roku 2027 70 % migrací prováděno v hybridním cloudovém prostředí.

Plánování migrace dat

Data Migration bez plánu — zaručené selhání. Plánování zahrnuje audit aktuálního schématu, profilování dat, výběr strategie, přípravu prostředí, testování a schválení plánu vrácení. Podle výzkumu McKinsey (2024) je 54 % neúspěšných migrací způsobeno chybějícím formálním plánem.

Audit a profilování

Před migrací je nutné provést audit zdrojového systému: určit objem dat, počet tabulek, závislosti mezi entitami, typy nullable polí a přítomnost duplicit. Profilování odhaluje anomálie — hodnoty NULL v klíčových polích, neshody formátů, poškozené reference. Tato data tvoří baseline úplného dumpu.

Příprava testovacího prostředí

Testovací migrace se provádí na kopii produkčních dat před hlavním spuštěním. Cílem je ověřit výkon ETL pipeline, správnost transformace a rychlost načítání. Doporučují se alespoň tři úplné cykly testování před Big Bang. Každý cyklus zahrnuje úplný přenos, validaci a vrácení.

Plán vrácení (Rollback)

Vrácení — návrat k původnímu systému při detekci kritických chyb. Plán vrácení zahrnuje: úplnou zálohu zdroje před startem, skripty pro obnovení schématu, podrobný návod k zapnutí starého systému a komunikační plán pro uživatele. Bez schváleného plánu vrácení by Data Migration neměla být spuštěna v produkci.

Příklady kódu migrace dat

Podívejme se na praktický příklad Data Migration v Kotlin v kombinaci s Flyway. Migrační skript V1 vytváří tabulku users a přenáší data z legacy formátu. Flyway automaticky sleduje aplikované migrace a zaručuje idempotenci.

// V1__Migrate_Users.kt — migrace dat z legacy formátu
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()
        }
    }
}

Příklad migrace v Pythonu pomocí SQLAlchemy pro přenos dat z CSV do PostgreSQL. Skript provádí extrakci ze souboru, převádí typy a načítá cílové tabulky.

# migrate_data.py — načtení CSV do PostgreSQL s transformací
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("Data Migration dokončena")