Data migration là gì?

Mục lục

1. Data migration là gì?
2. Data migration hoạt động thế nào?
3. Có những loại data migration nào?
4. Khi nào doanh nghiệp Việt Nam phải làm data migration?
5. Ánh xạ dữ liệu: bước khiến dự án thành hay bại
6. Chọn chiến lược nào: big bang, trickle hay sao chép liên tục?
7. Làm sao biết dữ liệu sau chuyển là đúng?
8. Rủi ro và lỗi thường gặp
9. Data migration khác gì với các khái niệm gần nhau?
10. Ưu điểm, hạn chế và khi nào nên làm
11. Công cụ thường dùng
12. Câu hỏi thường gặp

Data migration là gì?

Data migration là việc chuyển dữ liệu giữa các hệ thống lưu trữ, hệ thống máy tính hoặc định dạng dữ liệu, và vẫn giữ được tính toàn vẹn cùng độ chính xác. Định nghĩa này khớp với cách nhiều tài liệu tiếng Việt mô tả. Điểm cần nhớ là vế sau: dữ liệu phải còn đúng ở nơi mới, chứ không chỉ “đã sang bên kia”.

Ví dụ minh hoạ: một chuỗi cửa hàng thay phần mềm bán hàng cũ bằng hệ thống mới. Hệ thống cũ lưu mỗi khách hàng một dòng, số điện thoại viết nhiều kiểu. Hệ thống mới yêu cầu số điện thoại là trường duy nhất và có quy tắc kiểm tra. Nếu chỉ chép nguyên bảng, hàng nghìn dòng sẽ bị từ chối hoặc bị gộp sai. Phần việc xử lý chênh lệch đó mới là data migration.

Chuyển đổi dữ liệu hay di chuyển dữ liệu?

Tiếng Việt dùng lẫn lộn “chuyển đổi dữ liệu”, “di chuyển dữ liệu” và “chuyển dữ liệu”. Về kỹ thuật có hai khái niệm gần nhau. Migration nhấn vào việc chuyển từ nơi này sang nơi khác. Data conversion nhấn vào việc đổi định dạng, ví dụ từ tệp bảng tính sang cấu trúc bảng của cơ sở dữ liệu. Một số tài liệu tách riêng data conversion là việc thay đổi định dạng của dữ liệu. Trong thực tế, dự án migration nào cũng chứa một phần conversion.

Data migration hoạt động thế nào?

Về bản chất, mọi dự án đi qua ba pha: trích xuất dữ liệu từ nguồn, biến đổi cho khớp với mô hình dữ liệu đích, rồi nạp vào đích. Sau đó là kiểm tra và chuyển hệ thống sang dùng thật (cutover). Cơ chế này giống quy trình ETL, nhưng khác ở mục tiêu: ETL chạy lặp hằng ngày để phục vụ báo cáo, còn migration chạy có điểm kết thúc rồi hệ thống cũ được ngừng hoặc lưu trữ.

Có những loại data migration nào?

Cách phân loại phổ biến dựa trên thứ được chuyển. Mỗi loại kéo theo rủi ro khác nhau nên bạn cần xác định đúng loại trước khi lập kế hoạch.

• Storage migration: sau khi chuyển lưu trữ, cách truy cập dữ liệu thay đổi nhưng bản thân dữ liệu không đổi. Ví dụ: chuyển kho tệp từ máy chủ NAS cũ lên lưu trữ đám mây.
• Database migration: chuyển dữ liệu từ hệ quản trị cơ sở dữ liệu này sang hệ khác, chẳng hạn khi đổi nhà cung cấp hoặc lên cloud. Nếu hai hệ quản trị khác loại (ví dụ từ Oracle sang PostgreSQL), bạn còn phải chuyển đổi cả kiểu dữ liệu, thủ tục lưu sẵn và hàm. Xem thêm nền tảng ở bài cơ sở dữ liệu là gì.
• Application migration: chuyển một ứng dụng sang môi trường mới, kéo theo dữ liệu, cấu hình, phân quyền và các điểm tích hợp với ứng dụng khác.
• Cloud và data center migration: dời cả hạ tầng hoặc đưa dữ liệu từ on-premise lên cloud, hoặc giữa các nhà cung cấp cloud.

Khi nào doanh nghiệp Việt Nam phải làm data migration?

Thường là khi có một sự kiện buộc phải đổi hệ thống, chứ ít khi do dữ liệu tự yêu cầu. Các tình huống hay gặp:

• Thay phần mềm kế toán, ERP hoặc CRM. Dữ liệu công nợ, tồn kho, danh mục khách hàng cần sang hệ thống mới mà không đứt số dư đầu kỳ.
• Sáp nhập hoặc hợp nhất công ty. Gộp dữ liệu từ nhiều hệ thống về một nơi sau các thương vụ M&A là một lý do điển hình. Khi đó thường phải xử lý trùng lặp khách hàng, việc này liên quan đến quản lý dữ liệu chủ.
• Rời máy chủ đặt tại văn phòng hoặc hợp đồng thuê máy chủ sắp hết hạn để lên cloud.
• Dựng kho dữ liệu hoặc nền tảng phân tích mới và cần nạp lịch sử nhiều năm vào lần đầu.
• Số hoá hồ sơ giấy: dữ liệu từ biểu mẫu, bản quét đưa vào cơ sở dữ liệu có cấu trúc.

Ánh xạ dữ liệu: bước khiến dự án thành hay bại

Ánh xạ dữ liệu (data mapping) định nghĩa dữ liệu từ hệ thống nguồn tương ứng với trường nào ở hệ thống đích, và một tài liệu ánh xạ chi tiết sẽ dẫn dắt quá trình biến đổi. Với doanh nghiệp Việt Nam, những chỗ lệch thường gặp gồm:

• Bảng mã ký tự: hệ thống đời cũ có thể lưu tiếng Việt theo bảng mã không phải Unicode (như TCVN3 hoặc VNI). Nếu không đổi sang UTF-8 đúng cách, họ tên và địa chỉ hiện thành ký tự lỗi ở hệ thống mới.
• Định danh cá nhân: hồ sơ cũ có thể chứa số CMND 9 số và số CCCD 12 số trong cùng một cột. Cần quy tắc để biết dòng nào là loại nào, thay vì đoán theo độ dài.
• Định dạng ngày và số: ngày kiểu ngày/tháng/năm bị đọc thành tháng/ngày/năm sẽ sai âm thầm với các ngày từ 1 đến 12. Dấu phân cách thập phân và hàng nghìn cũng đảo nhau giữa các hệ thống.
• Mã danh mục: mã đơn vị hành chính, mã nhóm hàng, mã tài khoản kế toán mỗi hệ thống một kiểu. Cần bảng tra đổi mã được bên nghiệp vụ xác nhận.
• Ràng buộc mới: trường bắt buộc ở hệ thống đích nhưng bỏ trống ở nguồn. Phải quyết định điền giá trị mặc định hay loại dòng đó ra.

Phần làm sạch trước khi nạp (loại trùng, chuẩn hoá, xử lý giá trị thiếu) đã có hướng dẫn riêng ở bài làm sạch dữ liệu. Trong dự án migration, câu hỏi cần trả lời là dữ liệu nào làm sạch ở nguồn, dữ liệu nào làm trong lúc biến đổi, và dữ liệu nào bỏ lại không chuyển.

Chọn chiến lược nào: big bang, trickle hay sao chép liên tục?

Có ba chiến lược chính: big bang (chuyển một lần), trickle (chuyển theo từng giai đoạn tăng dần) và zero-downtime (sao chép liên tục bằng CDC). Chiến lược quyết định bạn có phải tạm dừng hệ thống hay không và khi sự cố xảy ra thì quay lui dễ hay khó.

Tiêu chí	Big bang	Trickle (theo đợt)	Sao chép liên tục (CDC)
Cách làm	Chuyển một lần trong khoảng thời gian ngừng hệ thống đã định	Chuyển từng phần nhỏ theo giai đoạn	Chép dữ liệu hiện có, rồi liên tục chép thay đổi mới
Thời gian ngừng	Có, kéo dài theo khối lượng	Thấp, hai hệ thống chạy song song	Rất ngắn, chỉ ở lúc chuyển hướng
Rủi ro	Có điểm hỏng duy nhất	Phát hiện lỗi sớm theo từng đợt	Cần theo dõi độ trễ và xung đột ghi
Độ phức tạp điều phối	Thấp hơn	Cần điều phối phức tạp và kéo dài hơn	Cần công cụ và kỹ năng riêng
Phù hợp	Khối lượng nhỏ hoặc chấp nhận được việc ngừng	Nhiều module, tách được theo đơn vị hoặc năm	Hệ thống giao dịch liên tục, cơ sở dữ liệu lớn

CDC hoạt động ra sao?

CDC (change data capture) đọc các thay đổi từ nhật ký giao dịch của cơ sở dữ liệu nguồn rồi áp sang đích. Ví dụ với dịch vụ AWS Database Migration Service, chế độ “full load + CDC” chép dữ liệu hiện có, đồng thời ghi lại thay đổi, rồi áp các thay đổi đó lên đích sau khi chép xong. Khi hai bên đã gần đồng bộ, bạn dừng ứng dụng, chờ nốt các thay đổi còn lại rồi khởi động lại ứng dụng trỏ vào đích. Nhờ vậy cửa sổ ngừng hệ thống chỉ còn vài phút thay vì vài giờ. Đổi lại, bạn cần đo độ trễ sao chép và xử lý những bảng không có khoá chính, vốn khó đồng bộ theo từng dòng.

Làm sao biết dữ liệu sau chuyển là đúng?

Đây là phần các bài giới thiệu thường nói rất ngắn. Đối soát (reconciliation) cần chạy ở nhiều lớp, từ thô đến sâu:

1. Đếm dòng theo bảng: số dòng nguồn so với số dòng đích, trừ số dòng bị loại có lý do ghi lại.
2. Tổng kiểm theo cột số: tổng tiền, tổng số lượng, số dư theo từng kỳ. Kế toán tự đối chiếu được với báo cáo cũ.
3. Kiểm tra toàn vẹn tham chiếu: mọi đơn hàng đều trỏ tới một khách hàng tồn tại, không có dòng mồ côi.
4. Đối chiếu mẫu nghiệp vụ: chọn một số hồ sơ có đủ kịch bản (trả hàng, hoàn tiền, khách đổi địa chỉ) và so từng trường bằng mắt với người dùng nghiệp vụ.
5. Kiểm thử chấp nhận của người dùng (UAT): người dùng thật chạy báo cáo, tra cứu, in chứng từ trên hệ thống mới.

Ba lớp đầu có thể tự động hoá bằng truy vấn so sánh, ví dụ viết bằng câu lệnh SQL chạy trên cả hai phía. Nếu doanh nghiệp đã có chuẩn về độ đầy đủ và độ nhất quán, hãy dùng luôn bộ tiêu chí ở bài chất lượng dữ liệu làm ngưỡng chấp nhận.

Chuẩn bị đường quay lui (rollback)

Trước ngày chuyển chính thức, cần quyết định trước điểm không thể quay lui, thường là lúc người dùng bắt đầu nhập giao dịch mới vào hệ thống đích. Trước điểm đó, hệ thống cũ vẫn là bản gốc, chỉ ở chế độ đóng băng ghi. Sau điểm đó, dữ liệu mới nằm ở đích, nên quay lui nghĩa là phải chép ngược. Hãy diễn tập cả hai kịch bản trong lần chạy thử, kèm đo thời gian thực tế.

Rủi ro và lỗi thường gặp

Lỗi	Dấu hiệu	Cách xử lý
Ánh xạ sai ngữ nghĩa	Nạp thành công nhưng báo cáo lệch số	Đối soát tổng theo cột số và có người nghiệp vụ ký duyệt mapping
Hỏng ký tự tiếng Việt	Họ tên hiện ký tự lạ, tìm kiếm không ra	Xác định bảng mã nguồn, thử trên mẫu có dấu đầy đủ, dùng UTF-8 ở đích
Bỏ sót dữ liệu “ẩn”	Tệp đính kèm, bảng tạm, báo cáo tự viết không sang	Kiểm kê toàn bộ đối tượng ở nguồn, không chỉ các bảng chính
Phụ thuộc không biết trước	Một hệ thống khác ngừng chạy vì đọc trực tiếp bảng cũ	Lập sơ đồ phụ thuộc; xem cách truy vết ở bài data lineage
Hết cửa sổ ngừng	Chạy thử mất nhiều giờ hơn dự tính	Đo thời gian trên bản sao có khối lượng thật; cân nhắc trickle hoặc CDC
Lộ dữ liệu khi chuyển	Tệp xuất ra ổ cá nhân, thư mục chia sẻ	Mã hoá đường truyền và nơi lưu tạm, giới hạn quyền, xoá bản trung gian sau khi xong

Nếu dữ liệu cần chuyển có chứa dữ liệu cá nhân và đích là máy chủ hoặc cloud đặt ở nước ngoài, cần rà soát quy định về chuyển dữ liệu cá nhân ra nước ngoài trước khi chọn vùng lưu trữ. Khung trách nhiệm và phân quyền dữ liệu nói chung nằm ở bài quản trị dữ liệu.

Data migration khác gì với các khái niệm gần nhau?

• So với ETL: ETL là quy trình lặp lại để đưa dữ liệu vào kho phân tích. Migration là dự án chuyển một lần có thời điểm bắt đầu và kết thúc, dù có thể dùng công cụ ETL bên trong.
• So với data integration: tích hợp dữ liệu giữ nhiều hệ thống cùng tồn tại và kết nối với nhau. Migration thường kết thúc bằng việc một hệ thống ngừng hoạt động.
• So với sao lưu (backup): sao lưu tạo bản dự phòng để khôi phục. Migration chuyển bản gốc sang nơi mới và biến đổi nếu cần.
• So với data pipeline: đường ống dữ liệu chạy thường xuyên, còn migration chỉ cần tạm thời, dù đôi khi dựng bằng cùng công cụ.

Ưu điểm, hạn chế và khi nào nên làm

Lợi ích: bỏ được hệ thống đã lỗi thời, gộp dữ liệu phân tán, giảm chi phí hạ tầng cũ và có cơ hội dọn dữ liệu rác. Hạn chế: tốn công đối soát, có thể phải ngừng hệ thống, và nếu chuyển cả dữ liệu sai thì hệ thống mới chỉ thừa hưởng lỗi cũ.

Nên làm khi hệ thống cũ không còn được nhà cung cấp hỗ trợ, không đáp ứng yêu cầu bảo mật, hoặc hợp đồng hạ tầng sắp kết thúc. Nên cân nhắc lại khi chưa chọn xong hệ thống đích, chưa ai xác nhận được ý nghĩa của các trường cũ, hoặc dữ liệu lịch sử quá lớn mà ít dùng. Trường hợp cuối có thể chỉ chuyển dữ liệu những năm gần đây, còn phần cũ lưu dạng chỉ đọc.

Công cụ thường dùng

Công cụ phụ thuộc loại migration. Với cơ sở dữ liệu, các dịch vụ như AWS Database Migration Service hỗ trợ full load và CDC; tài liệu mô tả dịch vụ này chạy lần nạp đầy đủ ban đầu, và phối hợp với AWS Schema Conversion Tool khi hai bên khác loại cơ sở dữ liệu. Với kho dữ liệu, nhiều nhóm dùng công cụ ETL hoặc ELT. Với tệp và lưu trữ, thường dùng công cụ đồng bộ tệp hoặc thiết bị vận chuyển vật lý khi mạng không đủ băng thông. Với dự án nhỏ, một script SQL cộng bảng tính đối soát đôi khi là đủ. Bạn nên chọn theo loại nguồn, loại đích, khối lượng và khả năng của đội vận hành, không theo danh sách xếp hạng.

Sau khi chuyển, cần cập nhật mô tả dữ liệu để người dùng tìm đúng nguồn mới, chẳng hạn bằng danh mục dữ liệu.

Câu hỏi thường gặp

Data migration là gì, nói ngắn gọn?

Là việc chuyển dữ liệu từ hệ thống, định dạng hoặc nơi lưu trữ này sang nơi khác, kèm ánh xạ và đối soát để dữ liệu ở nơi mới vẫn đúng và dùng được.

Data migration và chuyển đổi dữ liệu có phải một không?

Trong tiếng Việt, hai cách gọi thường được dùng thay nhau. Về kỹ thuật, chuyển đổi định dạng (data conversion) chỉ là một phần của migration, vì migration còn gồm vận chuyển, kiểm tra và chuyển hệ thống.

Data migration mất bao lâu?

Không có con số chung, vì phụ thuộc số hệ thống nguồn, chất lượng dữ liệu, số vòng chạy thử và cửa sổ ngừng cho phép. Thời gian chạy lệnh chép thường chỉ là phần nhỏ, phần lớn nằm ở ánh xạ và đối soát.

Big bang và trickle migration khác nhau thế nào?

Big bang chuyển toàn bộ trong một lần ngừng hệ thống. Trickle chuyển theo từng đợt nhỏ, hai hệ thống chạy song song nên giảm gián đoạn nhưng điều phối phức tạp và kéo dài hơn.

Có cần ngừng hệ thống khi chuyển dữ liệu không?

Với big bang thì có. Nếu dùng CDC, hệ thống nguồn vẫn chạy trong lúc chép, và bạn chỉ cần ngừng ngắn lúc chuyển ứng dụng sang trỏ vào hệ thống đích.

Làm sao tránh mất dữ liệu khi migration?

Giữ nguyên hệ thống cũ ở chế độ chỉ đọc đến khi đối soát xong, chạy thử trên bản sao, so số dòng và tổng tiền theo từng bảng, và diễn tập kịch bản quay lui trước ngày chuyển chính thức.