Những lỗi thường gặp khi chuyển sang Unity Catalog và cách phòng tránh
Sáu lỗi thường gặp khi chuyển sang Unity Catalog, xảy ra trong và sau lúc chuyển: nguyên nhân từng lỗi, cách phòng tránh và danh sách kiểm tra.
Trong một dự án chuyển sang Unity Catalog, các lỗi tốn nhiều thời gian nhất hiếm khi nằm ở việc sao chép bảng. Chúng nằm ở lịch sử bảng, các view, loại compute không chạy được mã nguồn cũ, công cụ chưa rõ chế độ hỗ trợ, và thời điểm tắt metastore cũ. Bài viết này trình bày sáu lỗi như vậy. Mỗi lỗi đều gắn với một trang tài liệu chính thức của Databricks để doanh nghiệp đối chiếu với phiên bản đang dùng.
Phần chuẩn bị, gồm kiểm kê, danh tính, lưu trữ và rà soát mã nguồn, đã được trình bày trong bài chuẩn bị chuyển từ Hive metastore lên Unity Catalog. Bài này bắt đầu từ chỗ bài kia dừng lại: quá trình chuyển và những việc diễn ra sau đó.
Hive metastore và Unity Catalog khác nhau ở điểm nào
Databricks mô tả Hive metastore gắn với từng workspace là tính năng cũ (legacy), và các bảng trong đó không hưởng đầy đủ các tính năng bảo mật, quản trị của Unity Catalog. Trong không gian tên ba cấp, Hive metastore xuất hiện dưới dạng một catalog tên hive_metastore. Quyền trong catalog này tham chiếu đến người dùng và nhóm cục bộ của một workspace, trong khi Unity Catalog là đối tượng cấp tài khoản, quyền áp dụng xuyên suốt các workspace, còn lineage và nhật ký kiểm toán xây trên cùng mô hình đó. Databricks khuyến nghị chuyển các bảng cùng những workload tham chiếu đến chúng. Chi tiết hai mô hình nằm ở bài chuẩn bị nêu trên; phần còn lại của bài này nói về những chỗ dễ sai.
Lỗi 1: coi SYNC, CLONE và CTAS có thể thay thế cho nhau
Biểu hiện. Cả một schema được nâng cấp bằng cùng một phương pháp. Một số bảng không nâng cấp được, hoặc sang bên mới mà mất lịch sử.
Nguyên nhân. Mỗi phương pháp áp dụng cho một nhóm bảng khác nhau. SYNC nâng cấp bảng external, và bảng managed khi bảng nằm ngoài vùng lưu trữ của workspace; SYNC không nâng cấp được bảng managed của Hive nằm trong vùng lưu trữ của workspace. Nhóm bảng này cần CREATE TABLE CLONE, áp dụng cho bảng managed định dạng Delta và phải là deep clone khi nguồn là Hive metastore. Bảng sau khi clone là một bảng mới: lịch sử bảng không được chuyển theo, nên không truy vấn ngược về thời điểm trước khi chuyển (time travel) được trên bảng mới. Bảng không đáp ứng điều kiện của CLONE thì dùng CREATE TABLE AS SELECT.
Cách phòng tránh. Chọn phương pháp theo loại bảng, không theo schema. Lập danh sách các báo cáo, đối soát hoặc kiểm toán đang dựa vào time travel, rồi giữ lại bảng cũ hoặc một kho lưu lịch sử riêng cho các trường hợp đó. Với tổ chức đối soát số liệu theo các phiên bản bảng trước đây, đây là vấn đề nghiệp vụ cần thống nhất trước khi chuyển, không phải chi tiết kỹ thuật để phát hiện về sau.
Lỗi 2: bỏ sót view và lệnh thao tác partition
Biểu hiện. Báo cáo hỏng sau khi các bảng đã chuyển, hoặc một script bảo trì từng chạy tốt trên bảng Hive thì báo lỗi trên bảng mới.
Nguyên nhân. View không được chuyển trực tiếp. Phải tạo lại view sau khi các bảng mà view tham chiếu đã nằm trong cùng một metastore Unity Catalog. Ngoài ra, Unity Catalog quản lý partition khác với Hive, và các lệnh Hive thao tác trực tiếp lên partition không được hỗ trợ trên bảng managed của Unity Catalog.
Cách phòng tránh. Sắp xếp công việc theo thứ tự phụ thuộc: bảng trước, rồi đến view đọc các bảng đó, sau cùng là báo cáo đọc từ view. Trước khi chuyển, tìm trong mã nguồn các lệnh thao tác ở cấp partition và lập sẵn phương án thay thế.
Lỗi 3: chạy workload trên compute standard mà chưa kiểm tra mã nguồn
Biểu hiện. Một job chạy bình thường trước khi chuyển lại báo lỗi sau khi chuyển, dù mã nguồn không thay đổi.
Nguyên nhân. Chế độ truy cập standard có các giới hạn đã được công bố. RDD API không được hỗ trợ. Với Scala, sc, spark.sparkContext và sqlContext không được hỗ trợ, Databricks khuyến nghị dùng biến phiên spark. Ngôn ngữ R và Databricks Runtime for ML cũng không được hỗ trợ. DBFS root và các điểm mount không hỗ trợ FUSE. Với workload cần những tính năng này, tài liệu hướng dẫn dùng compute dedicated.
Cách phòng tránh. Tìm các mẫu mã nguồn nêu trên trước khi chọn loại compute cho từng job, và chủ động xếp các job cần chúng vào compute dedicated, không chờ đến khi job lỗi. Bước rà soát mã nguồn mô tả trong bài chuẩn bị là thời điểm phù hợp để phát hiện các trường hợp này.
Lỗi 4: dựa vào công cụ mà chưa biết chế độ hỗ trợ của nó
Biểu hiện. Quá trình nâng cấp tự động dừng giữa chừng, và trong dự án không ai đủ hiểu công cụ để tiếp tục bằng tay.
Nguyên nhân. UCX là dự án của Databricks Labs, và Databricks khuyến nghị dùng cho phần lớn tình huống nâng cấp workspace. Cũng chính tài liệu đó nêu rằng UCX được cung cấp để tham khảo, không được Databricks hỗ trợ chính thức và không có cam kết mức dịch vụ (SLA) về hỗ trợ; sự cố được báo trên GitHub, không qua phiếu hỗ trợ. Tài liệu cũng cho biết luồng chuyển mã nguồn trong sơ đồ của UCX vẫn đang phát triển và chưa sử dụng được. Tài liệu khuyến nghị chạy bước đánh giá nhiều lần để phát hiện đủ các thành phần không tương thích.
Cách phòng tránh. Dùng UCX cho những việc công cụ làm tốt, là đánh giá cùng các luồng chuyển nhóm và chuyển bảng có thể lặp lại, đồng thời bố trí một người đọc được kết quả của công cụ và hoàn tất bằng tay phần công cụ không làm được. Đây cũng là câu trả lời thực tế cho câu hỏi về công cụ tăng tốc (accelerator) khi chuyển sang Unity Catalog: công cụ rút ngắn việc tìm và chuyển đối tượng, còn các quyết định về phạm vi, thứ tự và tiêu chí nghiệm thu vẫn thuộc về con người. Toàn bộ các công cụ chuyển đổi miễn phí, theo từng giai đoạn, được trình bày trong bài bộ công cụ tăng tốc chuyển đổi lên Databricks.
Lỗi 5: coi Hive metastore federation là điểm kết thúc
Biểu hiện. Dự án được báo cáo là hoàn tất vì các bảng đều hiển thị trong Unity Catalog, nhưng một năm sau metastore cũ vẫn nằm trên đường truy vấn.
Nguyên nhân. Federation cho phép Unity Catalog quản trị các bảng vẫn nằm trong Hive metastore, và Databricks giới thiệu đây là cách chuyển dần mà không phải sửa mã nguồn. Giải pháp này có giới hạn. Việc ghi qua foreign catalog được hỗ trợ với Hive metastore nội bộ của workspace, không được hỗ trợ với Hive metastore bên ngoài hoặc AWS Glue. Các tính năng thuộc về bảng managed của Unity Catalog, như predictive optimization, không áp dụng cho bảng foreign. Databricks cũng lưu ý hiệu năng có thể kém hơn đôi chút do cả hai hệ thống cùng nằm trên đường truy vấn.
Cách phòng tránh. Dùng federation như một cầu nối có ngày kết thúc, và ghi trong kế hoạch những bảng nào còn ở dạng foreign cùng bước sẽ chuyển chúng.
Lỗi 6: xoá bảng cũ quá sớm, hoặc tắt truy cập cũ quá muộn
Biểu hiện. Hoặc một bảng vẫn có hệ thống đọc bị xoá, hoặc metastore cũ vẫn truy cập được rất lâu sau khi chuyển và đội ngũ phải vận hành song song hai hệ thống phân quyền.
Nguyên nhân. Ở trường hợp thứ nhất, chưa ai kiểm tra phụ thuộc. Tài liệu gợi ý thu hồi quyền truy cập trên bảng cũ rồi chạy lại các truy vấn và workload liên quan, và khuyên giữ bảng cũ khi còn dùng chú thích ngừng sử dụng (deprecation comment) để tìm mã nguồn tham chiếu, khi bảng nguồn thay đổi sau lần đồng bộ, hoặc khi đã dùng shallow clone vì shallow clone tham chiếu đến dữ liệu của bảng nguồn. Ở trường hợp thứ hai, truy cập cũ mặc định vẫn bật cho đến khi quản trị viên tắt. Việc tắt kéo theo các hệ quả mà tài liệu liệt kê: job truy vấn bảng đăng ký trong Hive bị lỗi, job chạy trên Databricks Runtime thấp hơn 13.3 LTS bị lỗi, job đang chạy vẫn tiếp tục nhưng không khởi động lại được trên các cluster đó, và sau 30 ngày workspace chuyển vĩnh viễn sang vận hành trên Unity Catalog mà không còn metastore cũ, không bật lại được truy cập trực tiếp. Trang tài liệu cũng nêu Databricks đang dần tắt truy cập trực tiếp với các workspace không còn hoạt động trên Hive metastore, và truy cập cũ có thể được tắt tự động từ tháng 7/2026.
Cách phòng tránh. Kiểm tra phụ thuộc bằng cách thu hồi quyền, không bằng cách đọc mã nguồn. Nâng cấp các job lên Runtime 13.3 LTS trở lên trước khi tắt, và ghi ngày tắt vào kế hoạch để khoảng 30 ngày ấy là một quyết định chủ động, không phải điều bất ngờ.
Danh sách kiểm tra cho tổ chức thuộc ngành có quản lý
- Phương pháp được chọn theo loại bảng, có ghi lý do; nhu cầu về lịch sử bảng được xác định trước khi clone.
- View, báo cáo và lệnh thao tác partition được sắp sau các bảng mà chúng phụ thuộc.
- Mã nguồn đã được tìm các mẫu RDD,
sc,sqlContext, R, runtime ML và truy cập DBFS root hoặc mount; compute dedicated được gán đúng chỗ cần. - Có một người cụ thể chạy và đọc được kết quả của công cụ đánh giá, đồng thời hoàn tất bằng tay phần công cụ không xử lý.
- Danh sách bảng foreign đã lập, mỗi bảng đi kèm bước sẽ chuyển nó.
- Bảng cũ được xoá sau khi đã thu hồi quyền và chạy lại workload; các job đã ở Runtime 13.3 LTS trở lên trước khi tắt truy cập cũ.
- Vùng đặt metastore đã được quyết định: metastore Unity Catalog gắn với một vùng. Trang các vùng được hỗ trợ của Databricks không liệt kê vùng nào tại Việt Nam, nên doanh nghiệp tại Việt Nam thường cân nhắc Singapore, và lựa chọn này ảnh hưởng đến chi phí (xem giá Databricks tại Singapore so với US East).
- Lineage và nhật ký kiểm toán được bật ngay từ đợt chuyển khởi đầu của dự án, vì đây là bằng chứng mà cơ quan quản lý hoặc kiểm toán có thể yêu cầu. Mô hình phân quyền sau khi chuyển được trình bày trong bài Genie cho người dùng nghiệp vụ.
- Dữ liệu nào được đặt trên nền tảng đặt tại khu vực là câu hỏi pháp lý, thuộc về bộ phận tuân thủ và luật sư của chính tổ chức. Cần thống nhất trước khi chọn bảng nào được chuyển; xem bài luật bảo vệ dữ liệu cá nhân của Việt Nam và kiến trúc cho ngân hàng.
Sancire hỗ trợ ở khâu nào
Buổi khảo sát miễn phí 90 phút là cách để đối chiếu kế hoạch chuyển đổi với danh sách trên. Gói Quét hiện trạng chuyển đổi kéo dài một tuần, cho ra bản kiểm kê, kế hoạch chia đợt, rủi ro và báo giá cố định cho từng đợt. Việc nâng cấp, cùng mô hình phân quyền, lineage và phạm vi nhật ký kiểm toán, thuộc gói Quản trị Unity Catalog, từ 35.000 USD. Với ngân hàng và doanh nghiệp bảo hiểm, bước mở đầu là gói Đánh giá phân vùng dữ liệu và lộ trình tuân thủ, từ 10.000 USD, vì quyết định dữ liệu nào lên nền tảng đặt tại khu vực đi trước quyết định bảng nào được chuyển.
Nguồn, đều là các trang công khai của Databricks, tra cứu ngày 17/10/2026: Upgrade Hive tables and views to Unity Catalog (cập nhật 06/10/2026); Use the UCX utilities to upgrade your workspace to Unity Catalog (06/10/2026); Disable access to the Hive metastore used by your Databricks workspace (06/10/2026); Work with the legacy Hive metastore alongside Unity Catalog (11/09/2026); Hive metastore federation (11/09/2026); Standard compute requirements and limitations (11/09/2026); Supported regions (11/09/2026); UCX trên Databricks Labs (trang không ghi ngày). Tính năng và giới hạn thay đổi theo từng phiên bản runtime; cần đối chiếu tài liệu hiện hành trước khi lập kế hoạch.