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 TB података са AWS RDS на GCP Cloud SQL са прозором застоја од 14 сати.

Trickle миграција

Trickle — проточна синхронизација у малим порцијама. Стари и нови систем раде паралелно, промјене се реплицирају у реалном времену. Након стабилизације података, стари извор се искључује. Овај приступ захтијева двострану синхронизацију и рјешавање конфликата. Користи се у Continuous Delivery при ажурирању шеме базе података без застоја.

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% неуспјешних миграција је узроковано недостатком формалног плана.

Ревизија и профилисање

Прије миграције потребно је извршити ревизију изворног система: одредити обим података, број табела, зависности између ентитета, типове nullable поља и присуство дупликата. Профилисање открива аномалије — NULL вриједности у кључним пољима, неусклађеност формата, покварене референце. Ови подаци формирају baseline потпуног дампа.

Припрема тестног окружења

Тестна миграција се изводи на копији продукцијских података прије главног покретања. Циљ — провјера перформанси ETL цијевовода, исправности трансформације и брзине учитавања. Препоручује се најмање три потпуна циклуса тестирања прије Big Bang-а. Сваки циклус укључује потпун пренос, валидацију и повратак.

План повратка (Rollback)

Повратак — враћање на оригинални систем при откривању критичних грешака. План повратка укључује: потпуну резервну копију извора прије почетка, скрипте за обнављање шеме, упутство корак по корак за укључивање старог система и план комуникације са корисницима. Без одобреног плана повратка, 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("Data Migration завршена")