Data Migration — istota, metody i proces przenoszenia danych

Czym jest Data Migration

Data Migration to proces przenoszenia danych z jednego źródła do drugiego z zapewnieniem ich integralności, spójności i dostępności po zakończeniu. W przeciwieństwie do prostego kopiowania, migracja obejmuje transformację formatów, czyszczenie duplikatów, sprawdzanie integralności referencyjnej i walidację wyniku.

Potrzeba Data Migration pojawia się przy aktualizacji SZBD (np. z MySQL 5.7 na MySQL 8.0), zmianie dostawcy chmury, migracji z monolitu na mikrousługi lub przy przejściu ze schematu na NoSQL. Według Stripe (2024), 89% firm spotyka się z migracją danych przynajmniej raz na dwa lata, a 43% uznaje ją za najtrudniejszy etap aktualizacji technicznej.

Główne cele migracji danych

Pierwszym celem jest zwiększenie wydajności dzięki przejściu na nowocześniejsze rozwiązanie przechowywania. Drugim — obniżenie kosztów operacyjnych przy zmianie dostawcy infrastruktury. Trzecim — zapewnienie zgodności z wymogami regulacyjnymi (RODO, 152-FZ), gdy dane muszą być przechowywane w określonej jurysdykcji.

Czym migracja różni się od integracji

Integracja zakłada stałą synchronizację między dwoma działającymi systemami. Migracja to jednorazowe przeniesienie z późniejszym wyłączeniem źródła. Integracja nie usuwa danych w źródle, migracja kończy się przełączeniem systemu docelowego do statusu primary. To zasadnicza różnica określa wybór narzędzi i podejść do walidacji.

Model ETL migracji danych

Podstawowa architektura każdej Data Migration opiera się na modelu ETL (Extract, Transform, Load). Extract — wydobycie danych ze źródła. Transform — przekształcenie do docelowego schematu. Load — załadowanie do systemu docelowego. Każda faza ma własne metody kontroli jakości.

Extract: wydobycie danych

Na etapie wydobycia dane są odczytywane z bazowej bazy danych, magazynu plików lub API. Przyrostowy eksport (CDC — Change Data Capture) pozwala przenosić tylko zmienione rekordy, zmniejszając ilość ruchu. Pełny zrzut nadaje się dla małych woluminów, ale dla baz terabajtowych preferowana jest bieżąca replikacja przez Debezium lub Kafka Connect.

Transform: przekształcenie schematu

Przekształcenie obejmuje zmianę nazw kolumn, zmianę typów danych, normalizację wartości i agregację. Na przykład przy migracji z MySQL na PostgreSQL typ liczbowy DECIMAL należy przekształcić na NUMERIC, a format dat — na ISO 8601. Według Talend (2024), 70% czasu migracji przypada właśnie na transformację, a nie na przenoszenie.

Load: załadowanie do systemu docelowego

Załadowanie odbywa się partiami (batch insert) lub strumieniowo. Aby wyeliminować duplikaty, stosuje się klucz idempotentności. Po załadowaniu wymagany jest krok walidacji: porównanie liczby rekordów, obliczenie sum kontrolnych i sprawdzenie reguł biznesowych. Bez walidacji Data Migration jest uznawana za nieukończoną.

Strategie migracji danych

Wybór strategii Data Migration określa czas przestoju systemu, złożoność wycofania i zakres prac przygotowawczych. Główne strategie to Big Bang, Trickle i równoległe uruchomienie (Parallel Run). Każda jest stosowana w różnych scenariuszach.

Migracja Big Bang

Big Bang — jednorazowe wyłączenie starego systemu, przeniesienie danych i włączenie nowego. Nadaje się do małych woluminów i prostych schematów. Ryzyko: w razie awarii system jest niedostępny do czasu pełnego przywrócenia z kopii zapasowej. W 2024 roku GitLab zastosowała Big Bang do migracji 5 TB danych z AWS RDS na GCP Cloud SQL z oknem przestoju 14 godzin.

Migracja Trickle

Trickle — bieżąca synchronizacja małymi porcjami. Stary i nowy system działają równolegle, zmiany są replikowane w czasie rzeczywistym. Po stabilizacji danych stare źródło jest wyłączane. To podejście wymaga dwukierunkowej synchronizacji i rozwiązywania konfliktów. Stosowane w Continuous Delivery przy aktualizacji schematu bazy danych bez przestojów.

Parallel Run

Parallel Run — oba systemy działają jednocześnie, aplikacja zapisuje i odczytuje z obu źródeł. Po weryfikacji danych w systemie docelowym stare źródło jest wyłączane. To najbezpieczniejsza strategia, ale też najdroższa — wymaga utrzymania dwóch infrastruktur. Stosowana przy migracji krytycznych systemów finansowych.

Rodzaje migracji danych

W tworzeniu aplikacji rozróżnia się kilka rodzajów Data Migration według obiektu przenoszenia i kontekstu. Każdy rodzaj ma własną metodologię i narzędzia. Zrozumienie rodzaju to pierwszy krok do wyboru prawidłowej strategii.

Migracja bazy danych (Database Migration)

Database Migration — przenoszenie między SZBD różnych dostawców: z Oracle na PostgreSQL, z SQL Server na MySQL, z MongoDB na DynamoDB. Złożoność polega na niekompatybilności typów danych, dialektów SQL i mechanizmów indeksowania. Narzędzia: AWS DMS, Debezium, Liquibase.

Migracja danych aplikacji (Application Data Migration)

Przenoszenie danych między różnymi wersjami tej samej aplikacji — na przykład przy aktualizacji kodu ze zmianą struktury encji. Często towarzyszy temu wykonywanie skryptów migracyjnych w języku aplikacji: Active Record Migrations w Ruby on Rails, Flyway dla Java, Entity Framework Migrations w .NET. Skrypty te sekwencyjnie przekształcają schemat i dane.

Migracja chmurowa (Cloud Data Migration)

Cloud Data Migration — przenoszenie danych z infrastruktury on-premise do chmury lub między chmurami. AWS Snowball, Azure Data Box i Google Transfer Appliance są używane do fizycznego transportu terabajtowych woluminów. Do migracji online stosuje się tunele VPN i replikację. Według Gartner, do 2027 roku 70% migracji będzie wykonywanych w hybrydowym środowisku chmurowym.

Planowanie migracji danych

Data Migration bez planu to gwarantowana awaria. Planowanie obejmuje audyt bieżącego schematu, profilowanie danych, wybór strategii, przygotowanie środowiska, testowanie i zatwierdzenie planu wycofania. Według badania McKinsey (2024), 54% nieudanych migracji jest spowodowanych brakiem formalnego planu.

Audyt i profilowanie

Przed migracją należy przeprowadzić audyt systemu źródłowego: określić ilość danych, liczbę tabel, zależności między encjami, typy pól nullable i obecność duplikatów. Profilowanie ujawnia anomalie — wartości NULL w kluczowych polach, niezgodność formatów, uszkodzone referencje. Te dane tworzą baseline pełnego zrzutu.

Przygotowanie środowiska testowego

Testowa migracja jest wykonywana na kopii danych produkcyjnych przed uruchomieniem głównej. Celem jest sprawdzenie wydajności potoku ETL, poprawności transformacji i szybkości ładowania. Zaleca się co najmniej trzy pełne cykle testowania przed Big Bang. Każdy cykl obejmuje pełne przeniesienie, walidację i wycofanie.

Plan wycofania (Rollback)

Wycofanie to powrót do oryginalnego systemu w przypadku wykrycia krytycznych błędów. Plan wycofania obejmuje: pełną kopię zapasową źródła przed startem, skrypty przywracania schematu, instrukcję krok po kroku włączania starego systemu i plan komunikacji z użytkownikami. Bez zatwierdzonego planu wycofania Data Migration nie powinna być uruchamiana na produkcji.

Przykłady kodu migracji danych

Rozważmy praktyczny przykład Data Migration w Kotlin w połączeniu z Flyway. Skrypt migracji V1 tworzy tabelę users i przenosi dane z legacy-format. Flyway automatycznie śledzi zastosowane migracje i gwarantuje idempotentność.

// V1__Migrate_Users.kt — migracja danych z legacy formatu
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()
        }
    }
}

Przykład migracji w Python z użyciem SQLAlchemy do przenoszenia danych z CSV do PostgreSQL. Skrypt wykonuje wydobycie z pliku, przekształca typy i ładuje docelowe tabele.

# migrate_data.py — ładowanie CSV do PostgreSQL z transformacją
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 zakończona")