Data Migration — lényege, módszerei és az adatátvitel folyamata

Mi az a Data Migration

Data Migration az adatok egyik forrásból a másikba történő átvitelének folyamata, biztosítva azok integritását, konzisztenciáját és elérhetőségét a befejezést követően. Az egyszerű másolástól eltérően a migráció magában foglalja a formátumok átalakítását, a duplikátumok tisztítását, a referenciális integritás ellenőrzését és az eredmény validálását.

A Data Migration szükségessége DBMS frissítésekor (pl. MySQL 5.7-ről MySQL 8.0-ra), felhőszolgáltató váltásakor, monolitról mikroszolgáltatásokra való migrációkor vagy sémáról NoSQL-re való áttéréskor merül fel. A Stripe (2024) szerint a vállalatok 89%-a találkozik adatmigrációval legalább kétévente, és 43% a technikai frissítés legnehezebb szakaszának tartja.

Az adatmigráció fő céljai

Az első cél — teljesítménynövelés egy modernebb tárolási megoldásra való áttéréssel. A második — működési költségek csökkentése az infrastruktúra-szolgáltató váltásával. A harmadik — a szabályozási követelményeknek való megfelelés biztosítása (GDPR, 152-FZ), amikor az adatokat meghatározott joghatóságban kell tárolni.

Miben különbözik a migráció az integrációtól

Integráció állandó szinkronizációt feltételez két működő rendszer között. Migráció — egyszeri átvitel a forrás későbbi kikapcsolásával. Az integráció nem törli az adatokat a forrásban, a migráció a fogadó rendszer primary státuszba kapcsolásával ér véget. Ez az alapvető különbség határozza meg az eszközök és validálási megközelítések kiválasztását.

Adatmigráció ETL-modellje

Minden Data Migration alaparchitektúrája az ETL (Extract, Transform, Load) modellen alapul. Extract — adatok kinyerése a forrásból. Transform — átalakítás a cél sémára. Load — betöltés a fogadóba. Minden fázisnak saját minőségellenőrzési módszerei vannak.

Extract: adatok kinyerése

A kinyerési szakaszban az adatokat a forrásadatbázisból, fájltárolóból vagy API-ból olvassák. A növekményes kiürítés (CDC — Change Data Capture) lehetővé teszi csak a módosított rekordok átvitelét, csökkentve a forgalom mennyiségét. A teljes dump kis mennyiségekhez alkalmas, de terabájtos adatbázisokhoz a streaming replikáció előnyösebb Debezium vagy Kafka Connect segítségével.

Transform: séma átalakítása

Az átalakítás magában foglalja az oszlopok átnevezését, adattípusok megváltoztatását, értékek normalizálását és aggregálását. Például MySQL-ről PostgreSQL-re migráláskor a DECIMAL numerikus típust NUMERIC-re, a dátumformátumot pedig ISO 8601-re kell alakítani. A Talend (2024) szerint a migrációs idő 70%-a az átalakításra megy el, nem az átvitelre.

Load: betöltés a fogadóba

A betöltés kötegenként (batch insert) vagy streamelve történik. A duplikátumok kiküszöbölésére idempotencia-kulcsot használnak. A betöltés után kötelező a validálás: rekordok számának összehasonlítása, ellenőrző összegek számítása és üzleti szabályok ellenőrzése. Validálás nélkül a Data Migration befejezetlennek tekintendő.

Adatmigrációs stratégiák

A Data Migration stratégia kiválasztása meghatározza a rendszer állásidejét, a visszaállítás bonyolultságát és az előkészítő munka mennyiségét. A fő stratégiák — Big Bang, Trickle és párhuzamos futtatás (Parallel Run). Mindegyik különböző forgatókönyvekben alkalmazható.

Big Bang migráció

Big Bang — a régi rendszer egyszeri kikapcsolása, adatátvitel és az új bekapcsolása. Kis mennyiségekhez és egyszerű sémákhoz alkalmas. Kockázat: hiba esetén a rendszer a biztonsági mentésből való teljes helyreállításig nem elérhető. 2024-ben a GitLab Big Bang-et használt 5 TB adat AWS RDS-ről GCP Cloud SQL-re történő migrálásához 14 órás állásidő-ablakkal.

Trickle migráció

Trickle — folyamatos szinkronizáció kis adagokban. A régi és új rendszer párhuzamosan működik, a változtatások valós időben replikálódnak. Az adatok stabilizálódása után a régi forrás kikapcsolásra kerül. Ez a megközelítés kétirányú szinkronizációt és konfliktuskezelést igényel. Continuous Delivery-ben használják adatbázisséma frissítésekor állásidő nélkül.

Parallel Run

Parallel Run — mindkét rendszer egyidejűleg működik, az alkalmazás mindkét forrásból ír és olvas. Az adatok fogadóban történő ellenőrzése után a régi forrás kikapcsolásra kerül. Ez a legbiztonságosabb stratégia, de egyben a legdrágább — két infrastruktúra fenntartását igényli. Kritikus pénzügyi rendszerek migrálásakor alkalmazzák.

Adatmigráció típusai

Az alkalmazásfejlesztésben a Data Migration több típusát különböztetjük meg az átvitel tárgya és kontextusa szerint. Minden típusnak saját módszertana és eszközei vannak. A típus megértése az első lépés a helyes stratégia kiválasztásához.

Adatbázis migráció (Database Migration)

Database Migration — átvitel különböző gyártók DBMS-ei között: Oracle-ről PostgreSQL-re, SQL Server-ről MySQL-re, MongoDB-ről DynamoDB-re. A nehézséget az adattípusok, SQL-dialektusok és indexelési mechanizmusok inkompatibilitása jelenti. Eszközök: AWS DMS, Debezium, Liquibase.

Alkalmazás adatmigráció (Application Data Migration)

Adatok átvitele ugyanazon alkalmazás különböző verziói között — például kód frissítésekor az entitásszerkezet megváltozásával. Gyakran migrációs szkriptek végrehajtásával jár az alkalmazás nyelvén: Active Record Migrations Ruby on Rails-ben, Flyway Java-hoz, Entity Framework Migrations .NET-ben. Ezek a szkriptek egymás után alakítják át a sémát és az adatokat.

Felhő migráció (Cloud Data Migration)

Cloud Data Migration — adatok átvitele on-premise infrastruktúráról felhőbe vagy felhők között. Az AWS Snowball, Azure Data Box és Google Transfer Appliance terabájtos mennyiségek fizikai szállítására szolgál. Online migrációhoz VPN-alagutakat és replikációt használnak. A Gartner szerint 2027-re a migrációk 70%-a hibrid felhőkörnyezetben történik majd.

Adatmigráció tervezése

Data Migration terv nélkül — garantált kudarc. A tervezés magában foglalja a jelenlegi séma auditját, adatprofilozást, stratégiaválasztást, környezet előkészítését, tesztelést és a visszaállítási terv jóváhagyását. A McKinsey (2024) kutatása szerint a sikertelen migrációk 54%-át a formális terv hiánya okozza.

Audit és profilozás

A migráció előtt el kell végezni a forrásrendszer auditját: meghatározni az adatmennyiséget, táblák számát, entitások közötti függőségeket, nullable mezők típusait és a duplikátumok jelenlétét. A profilozás feltárja az anomáliákat — NULL értékek a kulcsmezőkben, formátum-eltérések, hibás hivatkozások. Ezek az adatok képezik a teljes dump alapvonalát.

Tesztkörnyezet előkészítése

A teszt migrációt éles adatok másolatán végzik a fő futtatás előtt. Cél — az ETL csővezeték teljesítményének, az átalakítás helyességének és a betöltési sebességnek az ellenőrzése. Legalább három teljes ciklus tesztelés ajánlott a Big Bang előtt. Minden ciklus teljes átvitelt, validálást és visszaállítást foglal magában.

Visszaállítási terv (Rollback)

Visszaállítás — visszatérés az eredeti rendszerhez kritikus hibák észlelése esetén. A visszaállítási terv tartalmazza: a forrás teljes biztonsági mentését a kezdés előtt, séma helyreállítási szkripteket, lépésről lépésre utasítást a régi rendszer bekapcsolásához és kommunikációs tervet a felhasználók értesítésére. Jóváhagyott visszaállítási terv nélkül a Data Migration nem indítható éles környezetben.

Adatmigrációs kódpéldák

Nézzünk egy gyakorlati példát a Data Migration-re Kotlin-ban a Flyway-jel kombinálva. A V1 migrációs szkript létrehozza a users táblát és átviszi az adatokat a régi formátumból. A Flyway automatikusan nyomon követi az alkalmazott migrációkat és garantálja az idempotenciát.

// V1__Migrate_Users.kt — adatmigráció régi formátumból
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élda migrációra Python-ban SQLAlchemy segítségével CSV-ből PostgreSQL-be történő adatátvitelre. A szkript kinyeri az adatokat a fájlból, átalakítja a típusokat és betölti a cél táblákat.

# migrate_data.py — CSV betöltése PostgreSQL-be átalakítással
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 befejeződött")