Di trú từ Hadoop lên Cloudera: lộ trình theo giai đoạn an toàn

Nhiều tổ chức tại Việt Nam đang vận hành cụm Hadoop hoặc nền tảng dữ liệu thế hệ trước: HDFS (Hadoop Distributed File System), bảng Hive, hàng trăm job ETL (Extract — Transform — Load) chạy theo lịch, và một danh sách báo cáo mà cả công ty phụ thuộc vào. Hệ thống ấy vẫn đang chạy, vẫn ra số mỗi sáng. Đó chính là lý do việc hiện đại hóa khó: không ai được phép làm nó dừng.

Tin tốt là Cloudera xuất thân từ chính hệ sinh thái Hadoop. Con đường đi lên Open Data Lakehouse trên bảng Apache Iceberg không phải là bỏ hết làm lại, mà là nâng cấp theo giai đoạn trên nền quen thuộc — giữ dữ liệu, giữ kỹ năng đội ngũ, đổi lớp bảng và lớp quản trị. Bài này mô tả lộ trình đó và cách giữ cho hệ thống hiện tại không gián đoạn.

flowchart TD
  H["Cụm hiện tại − vẫn phục vụ nghiệp vụ hằng ngày"]
  A["1 · Đánh giá hiện trạng"]
  B["2 · Chọn phần việc thí điểm"]
  C["3 · Chuyển dữ liệu sang bảng Iceberg"]
  D["4 · Chuyển luồng xử lý"]
  E["5 · Đối chiếu rồi cắt chuyển"]
  H --> A --> B --> C --> D --> E
  H -.->|Chạy song song tới khi đủ tin cậy| E
  E -.->|Nhân rộng cho lát cắt tiếp theo| B

Vì sao hiện đại hóa

Ba thứ đáng để đánh đổi công sức di trú:

• Bảng mở Apache Iceberg. Một bản dữ liệu, nhiều engine cùng đọc — Data Engineering trên Apache Spark, Data Warehouse cho báo cáo, và cả nền tảng ngoài truy cập trực tiếp không cần sao chép. Iceberg hỗ trợ giao dịch ACID (Atomicity — Consistency — Isolation — Durability), cập nhật ở mức bản ghi và tiến hóa cấu trúc bảng.
• Quản trị SDX (Shared Data Experience). Bảo mật, phân quyền và chính sách đặt một lần, áp cho mọi dịch vụ — thay vì cấp quyền rời rạc ở từng thành phần rồi không ai dựng lại được bức tranh tổng thể lúc thanh tra.
• Trí tuệ nhân tạo ngay trên dữ liệu. Khi dữ liệu đã nằm trong bảng có quản trị, Cloudera AI — lớp AI (Artificial Intelligence) của nền tảng — chạy tại chỗ trên chính dữ liệu đó, không phải trích ra ngoài.

Kèm theo là phần vận hành nhẹ đi: Cloudera Lakehouse Optimizer tự tối ưu bảng Iceberg (nén tệp nhỏ, dọn ảnh chụp cũ) — theo Cloudera công bố, giúp truy vấn nhanh hơn 38% và giảm 36% dung lượng lưu trữ. Cloudera Object Store trên nền Apache Ozone cung cấp lưu trữ đối tượng tương thích S3 ở quy mô hàng tỉ đối tượng.

Điều hay gặp trên nền dữ liệu thế hệ trước	Điều thay đổi trên Open Data Lakehouse
Mỗi engine giữ một bản sao dữ liệu riêng	Một bản bảng Iceberg, nhiều engine cùng đọc
Sửa hoặc xóa vài bản ghi phải ghi lại cả phân vùng	Giao dịch ACID, cập nhật ở mức bản ghi
Đổi cấu trúc bảng kéo theo viết lại dữ liệu	Iceberg cho phép tiến hóa cấu trúc và phân vùng
Quyền cấp rải rác ở từng thành phần	SDX đặt chính sách một lần cho mọi dịch vụ
Muốn dùng AI phải trích dữ liệu ra ngoài	AI chạy ngay cạnh dữ liệu, trong vành đai

Di trú theo giai đoạn

1. Đánh giá hiện trạng Kiểm kê bảng, dung lượng, job, lịch chạy, báo cáo và người dùng thật. Câu hỏi quan trọng nhất không phải “có bao nhiêu bảng” mà “cái gì còn được dùng” — trong mọi hệ chạy lâu năm luôn có một phần job tồn tại vì lịch sử. Kết quả cần có: bản đồ phụ thuộc, danh sách lát cắt theo miền nghiệp vụ, thiết kế mô hình dữ liệu đích và ước lượng công.

2. Chọn phần việc thí điểm Chọn một miền nghiệp vụ đủ nhỏ để xong trong vài tuần và đủ quan trọng để người ta quan tâm tới kết quả. Tiêu chí chọn: ít phụ thuộc chéo, có người dùng sẵn sàng ngồi đối chiếu số, có thước đo rõ ràng để tuyên bố thành công. Lát cắt đầu tiên vừa tạo giá trị vừa là bài học cho các lát sau.

3. Chuyển dữ liệu sang bảng Iceberg Với nhiều bảng, việc chuyển sang Iceberg là ghi lại lớp siêu dữ liệu trên chính các tệp đang có, không phải chép lại toàn bộ dữ liệu — nhanh và ít rủi ro hơn nhiều người hình dung (đường đi cụ thể tùy loại bảng và định dạng tệp). Chuyển xong thì đối chiếu ngay: số bản ghi, tổng kiểm các cột số, mẫu ngẫu nhiên.

4. Chuyển luồng xử lý Trỏ job Spark và pipeline sang bảng Iceberg, rồi chạy song song hai bên cùng một chu kỳ và so kết quả mỗi ngày. Đây cũng là lúc dọn: bỏ job đã chết, gộp job trùng. Nguyên tắc giữ tỉnh táo: mô hình dữ liệu đích đã chốt ở bước 1, còn trong lúc cắt một lát cụ thể thì giữ số liệu luôn đối chiếu được — đừng đổi nhiều biến số cùng lúc.

5. Đối chiếu rồi cắt chuyển Khi hai bên khớp số qua đủ nhiều chu kỳ (gồm cả kỳ đóng sổ), chuyển người dùng và báo cáo sang nền mới. Giữ hệ cũ ở chế độ chỉ đọc một thời gian rồi mới thu hồi tài nguyên. Ghi lại bài học và nhân rộng cho lát cắt tiếp theo.

Làm sao để hệ thống đang chạy không phải dừng

Toàn bộ lộ trình trên dựa vào một nguyên tắc: hai hệ cùng sống trong giai đoạn chuyển tiếp. Nền mới được dựng song song, dữ liệu chảy vào cả hai, và chỉ khi số liệu khớp thì người dùng mới chuyển sang.

• Cắt theo lát, không cắt theo cả hệ. Mỗi lần cắt chuyển chỉ động tới một miền nghiệp vụ — phạm vi ảnh hưởng nhỏ, xử lý sự cố nhanh.
• Luôn có đường lui. Hệ cũ giữ ở chế độ chỉ đọc, tiêu chí quay lại được xác định trước khi cắt chứ không bàn lúc đang sự cố.
• Đối chiếu tự động, không đối chiếu bằng mắt. Tổng kiểm số bản ghi và các cột số, so mẫu ngẫu nhiên, kiểm các mốc biên như cuối tháng và dữ liệu về trễ.
• Chọn cửa sổ theo lịch nghiệp vụ. Tránh kỳ đóng sổ, tránh mùa cao điểm — việc kỹ thuật nên nhường lịch kinh doanh.
• Giữ nguyên giao diện cho người dùng cuối. Nếu báo cáo vẫn ở chỗ cũ và ra đúng số, phần lớn người dùng không cần biết nền bên dưới vừa đổi.

💡 Bằng chứng thuyết phục nhất là một lát cắt chạy thật

Một miền nghiệp vụ chuyển trọn vẹn, ra đúng số, chạy ổn định vài tuần — đó là thứ mở được ngân sách cho phần còn lại, hiệu quả hơn bất kỳ bản thuyết trình nào. Cách làm này cũng cho đội ngũ học trên phạm vi nhỏ, nơi sai sót còn rẻ.

Hỗ trợ dài hạn tới 2032 và ý nghĩa khi ký hợp đồng nhiều năm

Cloudera công bố cam kết hỗ trợ dài hạn tới năm 2032, cập nhật đồng thời cho bản tại chỗ và bản đám mây, và lộ trình nâng cấp không buộc thay nền dựng lại (re-platform).

Nghe như chi tiết hợp đồng, nhưng với người ký một nền tảng dữ liệu dùng 5–7 năm, ba điều đó trả lời ba câu hỏi tiền bạc:

Câu hỏi lúc thẩm định	Điều Cloudera công bố	Ý nghĩa với chủ đầu tư
Vòng đời có đủ dài để khấu hao khoản đầu tư?	Hỗ trợ dài hạn tới 2032	Nền dữ liệu là hạ tầng, không phải ứng dụng — biết được chân trời hỗ trợ thì mới lập kế hoạch vốn nhiều năm
Chọn chạy tại chỗ có bị bỏ lại phía sau về tính năng?	Cập nhật đồng thời on-premises và đám mây	Chọn nơi đặt dữ liệu theo yêu cầu chủ quyền, không phải đánh đổi lấy tính năng
Nâng cấp sau này có thành một dự án di trú mới?	Nâng cấp không phải re-platform	Bản nâng cấp không biến thành lần “làm lại từ đầu” với chi phí và rủi ro của một dự án riêng

Nói cách khác: một lần di trú, không phải một chuỗi di trú. Đó là biến số quyết định tổng chi phí sở hữu (TCO — Total Cost of Ownership) của cả chu kỳ, chứ không phải giá trong năm đầu.

Các sai lầm dễ mắc phải

Những điểm dưới đây xuất hiện trong các dự án di trú nền dữ liệu ở khắp nơi, thường không phải vì thiếu năng lực mà vì áp lực tiến độ:

• Di trú theo kiểu “big bang”. Dồn mọi thứ vào một lần cắt cuối tuần nghe có vẻ tiết kiệm, nhưng nó gom toàn bộ rủi ro vào đúng thời điểm ít người trực nhất, và khi có sự cố thì không biết bắt đầu gỡ từ đâu. Cắt theo đợt tốn nhiều lần chuẩn bị hơn, đổi lại mỗi lần đều nhỏ và lùi được.
• Bê nguyên mô hình dữ liệu cũ sang nền mới. Nhiều bảng trong hệ cũ sinh ra để né giới hạn của công nghệ khi đó — bảng dựng sẵn để tránh phép nối chậm, phân vùng chia theo kích thước tệp, bản sao cho từng phòng ban. Chép nguyên trạng nghĩa là mang cả những ràng buộc ấy sang một nền vốn không còn ràng buộc đó, rồi trả chi phí lưu trữ và bảo trì cho chúng thêm nhiều năm.
• Để phần quản trị tới cuối mới làm. Mở quyền rộng cho nhanh trong lúc di trú rồi tính siết sau là một khoản nợ có lãi: khi hàng trăm người đã quen với quyền rộng, việc thu hẹp trở thành đàm phán chứ không còn là cấu hình.
• Chuyển hết mọi thứ, kể cả phần không ai còn dùng. Bước kiểm kê thường cho thấy một tỉ lệ đáng kể job và bảng chạy theo quán tính. Chuyển chúng sang nền mới là trả tiền để tiếp tục duy trì thứ không tạo giá trị.
• Đo tiến độ bằng số bảng đã chuyển. Con số đó dễ báo cáo nhưng không nói gì về giá trị. Thước đo gần thực tế hơn là: đã có bao nhiêu nghiệp vụ chạy trọn vẹn trên nền mới.
• Quên phần con người. Nền mới cần kỹ năng mới. Nếu đội nội bộ không được đào tạo song song, tổ chức đổi được công nghệ nhưng vẫn phụ thuộc bên ngoài để vận hành nó.

BSD Insight đồng hành

BSD Insight là đối tác Cloudera tại Việt Nam, làm cùng khách hàng trọn lộ trình:

• Tư vấn kiến trúc — đánh giá hiện trạng, thiết kế nền đích và mô hình dữ liệu, chọn phương án triển khai theo yêu cầu chủ quyền dữ liệu (tại chỗ, đám mây hoặc hybrid).
• Thực hiện di trú — chuyển bảng sang Iceberg, dựng lại luồng xử lý, đối chiếu số liệu và cắt chuyển theo từng đợt, giữ hệ thống hiện tại chạy suốt quá trình.
• Đào tạo và chuyển giao — để đội ngũ nội bộ tự vận hành và tự mở rộng sau khi dự án kết thúc.

Xem định vị và dịch vụ Cloudera của BSD tại bsdinsight.com/solutions/data-bi/cloudera.

Đọc tiếp

Open Data Lakehouse & Apache Iceberg Đích đến của cuộc di trú — bảng mở, giao dịch ACID, một bản dữ liệu nhiều engine.

SDX — lớp quản trị dùng chung Thiết kế phân quyền ngay từ đầu lộ trình, thay vì mở rộng rồi siết lại.

Ghi chú

Tổng hợp & diễn giải tiếng Việt theo tài liệu Cloudera và thực hành di trú. Số liệu về Lakehouse Optimizer cùng cam kết hỗ trợ tới 2032 là thông tin do Cloudera công bố — kiểm tra tài liệu chính thức khi đưa vào hồ sơ dự án. BSD Insight — đối tác Cloudera tại Việt Nam — liên hệ tư vấn.