Data Migration — esența, metodele și procesul de transfer al datelor

Ce este Data Migration

Data Migration este procesul de transfer al datelor dintr-o sursă în alta, asigurând integritatea, consistența și disponibilitatea acestora după finalizare. Spre deosebire de copierea simplă, migrarea include transformarea formatelor, curățarea duplicatelor, verificarea integrității referențiale și validarea rezultatului.

Nevoia de Data Migration apare la actualizarea SGBD (de exemplu, de la MySQL 5.7 la MySQL 8.0), schimbarea furnizorului de cloud, migrarea de la monolit la microservicii sau la trecerea de la schemă la NoSQL. Potrivit Stripe (2024), 89% dintre companii se confruntă cu migrarea datelor cel puțin o dată la doi ani, iar 43% o consideră cea mai dificilă etapă a actualizării tehnice.

Obiectivele principale ale migrării datelor

Primul obiectiv — creșterea performanței prin trecerea la o soluție de stocare mai modernă. Al doilea — reducerea costurilor operaționale prin schimbarea furnizorului de infrastructură. Al treilea — asigurarea conformității cu cerințele de reglementare (GDPR, 152-FZ), când datele trebuie stocate într-o anumită jurisdicție.

Ce deosebește migrarea de integrare

Integrarea presupune sincronizarea permanentă între două sisteme care funcționează. Migrarea — transfer unic cu dezactivarea ulterioară a sursei. Integrarea nu șterge datele din sursă, migrarea se finalizează prin trecerea sistemului destinatar în statutul primary. Această diferență fundamentală determină alegerea instrumentelor și abordărilor de validare.

Modelul ETL de migrare a datelor

Arhitectura de bază a oricărei Data Migration se bazează pe modelul ETL (Extract, Transform, Load). Extract — extragerea datelor din sursă. Transform — transformarea în schema țintă. Load — încărcarea în destinatar. Fiecare fază are propriile metode de control al calității.

Extract: extragerea datelor

În faza de extragere, datele sunt citite din baza de date sursă, stocarea de fișiere sau API. Descărcarea incrementală (CDC — Change Data Capture) permite transferul numai a înregistrărilor modificate, reducând volumul de trafic. Dump-ul complet este potrivit pentru volume mici, dar pentru baze de date de teraocteți se preferă replicarea în flux prin Debezium sau Kafka Connect.

Transform: transformarea schemei

Transformarea include redenumirea coloanelor, schimbarea tipurilor de date, normalizarea valorilor și agregarea. De exemplu, la migrarea de la MySQL la PostgreSQL, tipul numeric DECIMAL trebuie convertit în NUMERIC, iar formatul datelor — în ISO 8601. Potrivit Talend (2024), 70% din timpul migrării este alocat transformării, nu transferului.

Load: încărcarea în destinatar

Încărcarea se realizează în loturi (batch insert) sau în flux. Pentru eliminarea duplicatelor se utilizează cheia de idempotență. După încărcare este obligatoriu un pas de validare: compararea numărului de înregistrări, calcularea sumelor de control și verificarea regulilor de afaceri. Fără validare, Data Migration este considerată nefinalizată.

Strategii de migrare a datelor

Alegerea strategiei Data Migration determină timpul de nefuncționare a sistemului, complexitatea revenirii și volumul lucrărilor pregătitoare. Strategiile principale — Big Bang, Trickle și rularea paralelă (Parallel Run). Fiecare este aplicabilă în scenarii diferite.

Migrarea Big Bang

Big Bang — dezactivarea unică a sistemului vechi, transferul datelor și activarea celui nou. Potrivit pentru volume mici și scheme simple. Risc: în caz de avarie, sistemul este indisponibil până la restaurarea completă din backup. În 2024, GitLab a folosit Big Bang pentru migrarea a 5 TB de date de la AWS RDS la GCP Cloud SQL cu o fereastră de nefuncționare de 14 ore.

Migrarea Trickle

Trickle — sincronizare continuă în porțiuni mici. Sistemele vechi și noi funcționează în paralel, modificările sunt replicate în timp real. După stabilizarea datelor, sursa veche este dezactivată. Această abordare necesită sincronizare bidirecțională și rezolvare a conflictelor. Este utilizată în Continuous Delivery la actualizarea schemei bazei de date fără timp de nefuncționare.

Parallel Run

Parallel Run — ambele sisteme funcționează simultan, aplicația scrie și citește din ambele surse. După verificarea datelor în destinatar, sursa veche este dezactivată. Este cea mai sigură strategie, dar și cea mai costisitoare — necesită întreținerea a două infrastructuri. Se aplică la migrarea sistemelor financiare critice.

Tipuri de migrare a datelor

În dezvoltarea aplicațiilor se disting mai multe tipuri de Data Migration după obiectul transferului și context. Fiecare tip are propria metodologie și instrumente. Înțelegerea tipului este primul pas către alegerea strategiei corecte.

Migrarea bazei de date (Database Migration)

Database Migration — transferul între SGBD-uri ale diferiților furnizori: de la Oracle la PostgreSQL, de la SQL Server la MySQL, de la MongoDB la DynamoDB. Complexitatea constă în incompatibilitatea tipurilor de date, dialectelor SQL și mecanismelor de indexare. Instrumente: AWS DMS, Debezium, Liquibase.

Migrarea datelor aplicației (Application Data Migration)

Transferul datelor între diferite versiuni ale aceleiași aplicații — de exemplu, la actualizarea codului cu modificarea structurii entităților. Este adesea însoțită de executarea scripturilor de migrare în limbajul aplicației: Active Record Migrations în Ruby on Rails, Flyway pentru Java, Entity Framework Migrations în .NET. Aceste scripturi transformă succesiv schema și datele.

Migrarea în cloud (Cloud Data Migration)

Cloud Data Migration — transferul datelor din infrastructura on-premise în cloud sau între cloud-uri. AWS Snowball, Azure Data Box și Google Transfer Appliance sunt utilizate pentru transportul fizic al volumelor de teraocteți. Pentru migrarea online se folosesc tuneluri VPN și replicare. Potrivit Gartner, până în 2027, 70% dintre migrări vor fi efectuate în mediu cloud hibrid.

Planificarea migrării datelor

Data Migration fără plan — eșec garantat. Planificarea include auditul schemei curente, profilarea datelor, alegerea strategiei, pregătirea mediului, testarea și aprobarea planului de revenire. Potrivit cercetării McKinsey (2024), 54% dintre migrările eșuate sunt cauzate de lipsa unui plan formal.

Audit și profilare

Înainte de migrare, trebuie efectuat un audit al sistemului sursă: determinarea volumului de date, numărului de tabele, dependențelor între entități, tipurilor de câmpuri nullable și prezenței duplicatelor. Profilarea dezvăluie anomalii — valori NULL în câmpurile cheie, neconcordanțe de formate, referințe rupte. Aceste date formează baseline-ul dump-ului complet.

Pregătirea mediului de test

Migrarea de test se efectuează pe o copie a datelor de producție înainte de rularea principală. Scopul — verificarea performanței pipeline-ului ETL, corectitudinii transformării și vitezei de încărcare. Se recomandă minimum trei cicluri complete de testare înainte de Big Bang. Fiecare ciclu include transferul complet, validarea și revenirea.

Planul de revenire (Rollback)

Revenirea — întoarcerea la sistemul original la detectarea erorilor critice. Planul de revenire include: backup complet al sursei înainte de start, scripturi de restaurare a schemei, instrucțiuni pas cu pas pentru activarea sistemului vechi și un plan de comunicare cu utilizatorii. Fără un plan de revenire aprobat, Data Migration nu trebuie lansată în producție.

Exemple de cod pentru migrarea datelor

Să analizăm un exemplu practic de Data Migration în Kotlin împreună cu Flyway. Scriptul de migrare V1 creează tabela users și transferă datele din format moștenit. Flyway urmărește automat migrările aplicate și garantează idempotența.

// V1__Migrate_Users.kt — migrarea datelor din formatul moștenit
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()
        }
    }
}

Exemplu de migrare în Python folosind SQLAlchemy pentru transferul datelor din CSV în PostgreSQL. Scriptul efectuează extragerea din fișier, convertește tipurile și încarcă tabelele țintă.

# migrate_data.py — încărcarea CSV în PostgreSQL cu transformare
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 finalizată")