Data Migration — esensya, paraan at proseso ng paglilipat ng datos

Ano ang Data Migration

Data Migration ay ang proseso ng paglilipat ng datos mula sa isang source papunta sa isa pa na may integridad, consistency, at availability pagkatapos makumpleto. Hindi tulad ng simpleng pagkopya, ang migrasyon ay may kasamang pagbabago ng format, paglilinis ng mga duplicate, pagsuri ng referential integrity, at pag-validate ng resulta.

Ang pangangailangan para sa Data Migration ay lumilitaw kapag nag-a-update ng DBMS (hal. mula MySQL 5.7 hanggang MySQL 8.0), nagpapalit ng cloud provider, lumilipat mula sa monolit patungo sa microservices, o kapag lumilipat mula sa schema patungo sa NoSQL. Ayon sa Stripe (2024), 89% ng mga kumpanya ay nakakaranas ng migrasyon ng datos kahit isang beses sa loob ng dalawang taon, at 43% ang itinuturing itong pinakamahirap na yugto ng technical update.

Mga pangunahing layunin ng migrasyon ng datos

Ang unang layunin — pagpapabuti ng performance sa pamamagitan ng paglipat sa mas modernong solusyon sa imbakan. Pangalawa — pagbawas ng operational cost sa pagpapalit ng infrastructure provider. Pangatlo — pagtiyak ng pagsunod sa mga regulasyon (GDPR, 152-FZ) kapag ang datos ay dapat na nakaimbak sa isang partikular na hurisdiksyon.

Pagkakaiba ng migrasyon sa integrasyon

Integrasyon ay nagsasaad ng permanenteng pag-sync sa pagitan ng dalawang tumatakbong system. Ang migrasyon — isang beses na paglilipat na may kasunod na pag-deactivate ng source. Hindi tinatanggal ng integrasyon ang datos sa source, ang migrasyon ay nagtatapos sa paglipat ng receiving system sa status na primary. Ang pangunahing pagkakaibang ito ay tumutukoy sa pagpili ng mga tool at approach sa pag-validate.

Modelo ng ETL para sa migrasyon ng datos

Ang pangunahing arkitektura ng anumang Data Migration ay batay sa modelong ETL (Extract, Transform, Load). Extract — pagkuha ng datos mula sa source. Transform — pag-convert sa target na schema. Load — pagkarga sa receiver. Bawat yugto ay may sariling pamamaraan ng quality control.

Extract: pagkuha ng datos

Sa yugto ng pagkuha, ang datos ay binabasa mula sa source database, file storage, o API. Ang incremental na pagbaba (CDC — Change Data Capture) ay nagpapahintulot sa paglipat lamang ng mga binagong record, na nagbabawas ng dami ng trapiko. Ang kumpletong dump ay angkop para sa maliliit na volume, ngunit para sa terabyte na database, mas gusto ang streaming replication sa pamamagitan ng Debezium o Kafka Connect.

Transform: pag-convert ng schema

Ang pag-convert ay may kasamang pagpapalit ng pangalan ng column, pagbabago ng uri ng datos, pag-normalize ng mga value, at aggregation. Halimbawa, sa migrasyon mula MySQL patungo sa PostgreSQL, ang numeric type na DECIMAL ay dapat i-convert sa NUMERIC, at ang format ng petsa — sa ISO 8601. Ayon sa Talend (2024), 70% ng oras ng migrasyon ay ginugugol sa transformasyon, hindi sa paglilipat.

Load: pagkarga sa receiver

Ang pagkarga ay ginagawa nang batch (batch insert) o streaming. Para alisin ang mga duplicate, ginagamit ang idempotency key. Pagkatapos ng pagkarga, kinakailangan ang hakbang ng pag-validate: paghahambing ng bilang ng mga record, pagkalkula ng checksum, at pagsuri sa mga business rule. Kung walang validation, ang Data Migration ay itinuturing na hindi kumpleto.

Mga estratehiya sa migrasyon ng datos

Ang pagpili ng estratehiya ng Data Migration ay tumutukoy sa downtime ng system, pagiging kumplikado ng rollback, at dami ng paghahandang trabaho. Ang mga pangunahing estratehiya — Big Bang, Trickle, at parallel run (Parallel Run). Bawat isa ay naaangkop sa iba't ibang sitwasyon.

Migrasyong Big Bang

Big Bang — isang beses na pag-deactivate ng lumang system, paglilipat ng datos, at pag-activate ng bago. Angkop para sa maliliit na volume at simpleng schema. Peligro: kung magkaroon ng aberya, ang system ay hindi available hanggang sa kumpletong pagbawi mula sa backup. Noong 2024, ginamit ng GitLab ang Big Bang para sa paglipat ng 5 TB ng datos mula AWS RDS patungo sa GCP Cloud SQL na may 14 na oras na downtime window.

Migrasyong Trickle

Trickle — patuloy na pag-sync sa maliliit na bahagi. Ang luma at bagong system ay tumatakbo nang parallel, ang mga pagbabago ay nire-replicate sa real-time. Pagkatapos ng pag-stabilize ng datos, ang lumang source ay ide-deactivate. Ang approach na ito ay nangangailangan ng two-way sync at pagresolba ng conflict. Ginagamit sa Continuous Delivery kapag nag-a-update ng database schema nang walang downtime.

Parallel Run

Parallel Run — parehong system ay tumatakbo nang sabay, ang application ay sumusulat at bumabasa mula sa parehong source. Pagkatapos ng pag-verify ng datos sa receiver, ang lumang source ay ide-deactivate. Ito ang pinakaligtas na estratehiya, ngunit pinakamahal — nangangailangan ng pagpapanatili ng dalawang infrastructure. Ginagamit sa paglipat ng kritikal na financial system.

Mga uri ng migrasyon ng datos

Sa pag-develop ng aplikasyon, maraming uri ng Data Migration ang nakikilala ayon sa object ng paglilipat at konteksto. Bawat uri ay may sariling metodolohiya at mga tool. Ang pag-unawa sa uri ay unang hakbang sa pagpili ng tamang estratehiya.

Migrasyon ng database (Database Migration)

Database Migration — paglilipat sa pagitan ng DBMS ng iba't ibang vendor: mula Oracle patungo sa PostgreSQL, mula SQL Server patungo sa MySQL, mula MongoDB patungo sa DynamoDB. Ang komplikasyon ay nasa hindi pagkakatugma ng mga uri ng datos, dialect ng SQL, at mekanismo ng pag-index. Mga tool: AWS DMS, Debezium, Liquibase.

Migrasyon ng datos ng aplikasyon (Application Data Migration)

Paglilipat ng datos sa pagitan ng iba't ibang bersyon ng parehong application — halimbawa, kapag nag-a-update ng code na may pagbabago sa istruktura ng entity. Madalas na may kasamang pagpapatakbo ng migration script sa wika ng application: Active Record Migrations sa Ruby on Rails, Flyway para sa Java, Entity Framework Migrations sa .NET. Ang mga script na ito ay sunud-sunod na nagpapabago ng schema at datos.

Migrasyon ng cloud (Cloud Data Migration)

Cloud Data Migration — paglilipat ng datos mula sa on-premise infrastructure patungo sa cloud o sa pagitan ng clouds. Ang AWS Snowball, Azure Data Box, at Google Transfer Appliance ay ginagamit para sa pisikal na transportasyon ng terabyte volume. Para sa online migration, ginagamit ang mga VPN tunnel at replication. Ayon sa Gartner, pagsapit ng 2027 70% ng migrasyon ay isasagawa sa hybrid cloud environment.

Pagpaplano ng migrasyon ng datos

Data Migration nang walang plano — garantisadong pagkabigo. Kasama sa pagpaplano ang audit ng kasalukuyang schema, profiling ng datos, pagpili ng estratehiya, paghahanda ng environment, pag-test, at pag-apruba ng rollback plan. Ayon sa pananaliksik ng McKinsey (2024), 54% ng mga bigong migrasyon ay sanhi ng kawalan ng pormal na plano.

Audit at profiling

Bago ang migrasyon, kailangang magsagawa ng audit ng source system: tukuyin ang dami ng datos, bilang ng mga table, dependencies sa pagitan ng mga entity, uri ng nullable field, at pagkakaroon ng mga duplicate. Ang profiling ay nagpapakita ng mga anomalya — NULL values sa key field, hindi pagkakatugma ng format, sirang reference. Ang datos na ito ay bumubuo ng baseline ng kumpletong dump.

Paghahanda ng test environment

Ang test migration ay isinasagawa sa kopya ng production data bago ang pangunahing pagpapatakbo. Layunin — suriin ang performance ng ETL pipeline, correctness ng pag-convert, at bilis ng pagkarga. Hindi bababa sa tatlong kumpletong cycle ng pag-test ang inirerekomenda bago ang Big Bang. Bawat cycle ay may kasamang kumpletong paglipat, validation, at rollback.

Rollback plan

Rollback — pagbabalik sa orihinal na system kapag may nakitang kritikal na error. Kasama sa rollback plan: kumpletong backup ng source bago magsimula, script para sa pag-restore ng schema, step-by-step na tagubilin para sa pag-activate ng lumang system, at communication plan sa mga user. Kung walang aprubadong rollback plan, hindi dapat isagawa ang Data Migration sa produksyon.

Halimbawa ng code para sa migrasyon ng datos

Tingnan natin ang praktikal na halimbawa ng Data Migration sa Kotlin na may Flyway. Ang V1 migration script ay gumagawa ng users table at naglilipat ng datos mula sa legacy format. Flyway ay awtomatikong sumusubaybay sa mga inilapat na migrasyon at ginagarantiyahan ang idempotency.

// V1__Migrate_Users.kt — migrasyon ng datos mula sa legacy format
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()
        }
    }
}

Halimbawa ng migrasyon sa Python gamit ang SQLAlchemy para sa paglipat ng datos mula CSV patungo sa PostgreSQL. Ginagawa ng script ang pagkuha mula sa file, pag-convert ng types, at pagkarga sa target na mga table.

# migrate_data.py — pagkarga ng CSV sa PostgreSQL na may pag-convert
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 natapos")