Chuyển từ Hive metastore lên Unity Catalog: cần chuẩn bị gì trước
Dự án chuyển đổi lên Unity Catalog được quyết định trước khi bảng đầu tiên được chuyển. Những gì cần chuẩn bị, và phương pháp phù hợp cho từng loại bảng.
Chuyển một nền tảng Databricks từ Hive metastore sang Unity Catalog thoạt nhìn giống một việc xử lý metadata: đăng ký các bảng vào catalog mới rồi trỏ các job sang đó. Trên thực tế, phần bảng dữ liệu lại là phần đơn giản nhất. Điều quyết định dự án hoàn tất trong vài tuần hay kéo dài nhiều tháng là những gì đã được thống nhất trước khi bảng đầu tiên được chuyển: người dùng là ai, dữ liệu nằm ở đâu, cluster nào đang chạy khối lượng công việc nào, và bao nhiêu mã nguồn còn phụ thuộc vào cách làm cũ.
Bài viết này tập trung vào phần chuẩn bị đó.
Những lỗi xảy ra trong và sau khi chuyển được trình bày ở bài những lỗi thường gặp khi chuyển sang Unity Catalog.
Những thay đổi chính
Bốn thay đổi tạo ra phần lớn khối lượng công việc.
Không gian tên ba cấp. Hive metastore định danh bảng theo dạng schema.table. Unity Catalog bổ sung catalog ở phía trước: catalog.schema.table. Mọi truy vấn, job và báo cáo đang dùng tên hai cấp đều phải được trỏ về đúng catalog.
Một metastore cho mỗi vùng, quản trị ở cấp tài khoản. Một metastore Unity Catalog phục vụ các workspace trong cùng vùng, và quyền truy cập được cấp cho các danh tính định nghĩa ở cấp tài khoản Databricks thay vì trong từng workspace. Nhóm người dùng tạo riêng trong một workspace không thể được cấp quyền truy cập dữ liệu trong Unity Catalog.
Không dùng DBFS cho bảng managed, không dùng mount point. Unity Catalog không lưu bảng managed trong DBFS, nên các bảng managed trong Hive metastore phải được sao chép sang, không thể chỉ đăng ký lại. Mount point không được hỗ trợ và được thay thế bằng external location và volume; cluster cũng không còn cần instance profile để truy cập kho lưu trữ.
Chế độ truy cập của cluster. Unity Catalog hoạt động trên cluster ở chế độ dedicated (trước đây gọi là single user) hoặc shared. Cluster ở chế độ “no isolation shared” và cluster bật credential passthrough không sử dụng được Unity Catalog.
Trong giai đoạn chuyển tiếp, Hive metastore vẫn hoạt động song song với Unity Catalog, nhờ đó doanh nghiệp có thể chuyển đổi theo từng đợt. Tuy vậy, chính Databricks khuyến nghị không duy trì song song quá lâu, vì hai hệ thống phân quyền phải liên tục được đồng bộ với nhau.
Năm việc cần thống nhất trước khi chuyển đổi
1. Bản kiểm kê đáng tin cậy
Trước khi chuyển bất kỳ thứ gì, doanh nghiệp cần một danh sách đầy đủ hiện trạng: cơ sở dữ liệu và bảng, bảng nào là managed hay external và dữ liệu nằm ở đâu, phân quyền, job, cluster, mount point và các service principal đang truy cập kho lưu trữ. Databricks Labs cung cấp công cụ UCX cho việc này, và chúng tôi coi bước đánh giá của UCX là bước bắt buộc đầu tiên. Vị trí của UCX bên cạnh các công cụ chuyển đổi miễn phí khác được trình bày trong bài bộ công cụ tăng tốc chuyển đổi lên Databricks.
Bản kiểm kê cũng trả lời các câu hỏi quyết định quy mô dự án: có bao nhiêu bảng managed, bao nhiêu dữ liệu nằm trong DBFS, bao nhiêu job dùng đường dẫn cố định trong mã nguồn, và khối lượng công việc nào không còn ai sử dụng để có thể loại bỏ luôn.
2. Danh tính ở cấp tài khoản
Người dùng và service principal tạo trong workspace được tự động đồng bộ lên tài khoản, nhưng nhóm người dùng thì không. Mỗi nhóm cục bộ đang được dùng để cấp quyền hiện nay cần có một nhóm tương ứng ở cấp tài khoản trước khi phân quyền trong Unity Catalog. Cấu hình được khuyến nghị là đồng bộ người dùng và nhóm từ hệ thống quản lý danh tính vào tài khoản Databricks qua SCIM, đồng thời ngừng đồng bộ vào từng workspace riêng lẻ.
Bước này cũng cần xác định rõ người phụ trách: quản trị viên tài khoản Databricks, quản trị viên cloud và IAM, quản trị viên hệ thống danh tính, quản trị viên workspace và người sẽ quản trị metastore. Dự án chuyển đổi bị chậm vì chờ một trong những người này thường xuyên hơn là vì vướng mắc kỹ thuật.
3. Thiết kế lưu trữ
Unity Catalog truy cập kho lưu trữ cloud thông qua storage credential và external location. Riêng storage credential cho phép truy cập toàn bộ một container; external location giới hạn quyền đó trong một đường dẫn cụ thể. Một cách tổ chức thực tế là mỗi container hoặc storage account một external location, với credential phân tách theo mảng nghiệp vụ và môi trường, ví dụ một credential riêng cho dữ liệu kinh doanh trên môi trường vận hành chính thức.
Có hai quy tắc cần biết sớm. Unity Catalog không cho phép hai bảng dùng chung một vị trí lưu trữ, điều thường gặp ở các nền tảng từng đăng ký nhiều bảng trên cùng một đường dẫn. Và không nên dùng lại bucket gốc của DBFS làm kho lưu trữ cho bảng managed.
4. Cluster và phiên bản runtime
Cluster chạy phiên bản Databricks Runtime cũ phải được dựng lại, không thể chỉ đổi cấu hình. Phiên bản runtime tối thiểu cho Unity Catalog được ghi khác nhau trong các tài liệu của Databricks qua từng năm, vì vậy doanh nghiệp nên đối chiếu tài liệu hiện hành cho đúng tính năng cần dùng, thay vì dựa vào con số trên một bản trình bày cũ. Cluster policy là cách thực tế để bảo đảm cluster mới luôn được tạo ở chế độ truy cập tương thích với Unity Catalog.
Cluster chế độ shared có một số giới hạn mà cluster dedicated không có, chẳng hạn với ngôn ngữ R và một số loại hàm do người dùng định nghĩa. Nếu đội ngũ nào phụ thuộc vào các tính năng này, cần lên phương án cluster riêng cho họ.
5. Mã nguồn
Khi rà soát mã nguồn cho đợt nâng cấp, cần kiểm tra: tên bảng hai cấp, tham chiếu tới mount point, việc dùng trực tiếp dbutils.fs và đường dẫn tệp, sqlContext và sparkContext, hàm do người dùng định nghĩa bằng Scala, Python và Java, init script, thư viện JAR trên cluster shared, checkpoint của luồng dữ liệu lưu trong DBFS, và các pipeline. Khối lượng công việc phụ thuộc lớn vào việc schema được tham số hoá hay ghi cố định trong mã nguồn, và đội ngũ đã có quy trình CI/CD hay chưa; dự án chưa có CI/CD nên được ước lượng riêng.
Job nên chạy bằng service principal thay vì tài khoản cá nhân. Trước khi xoá một bảng cũ, cách kiểm tra phụ thuộc rất đơn giản: thu hồi quyền truy cập bảng đó rồi chạy lại các truy vấn có thể vẫn đang dùng tới.
Phương pháp phù hợp cho từng loại bảng
Tài liệu của Databricks xác định phương pháp theo từng loại bảng:
| Bảng trong Hive metastore | Nơi lưu trữ | Đích chuyển đổi | Phương pháp |
|---|---|---|---|
| Mọi loại | Thư mục gốc DBFS | Managed hoặc external | Sao chép bằng CTAS hoặc DEEP CLONE |
| Mọi loại | Kho lưu trữ mount hoặc cloud | External | SYNC, đăng ký bảng tại chỗ |
| Mọi loại | Kho lưu trữ mount hoặc cloud | Managed | Sao chép bằng CTAS hoặc DEEP CLONE |
| Định dạng Hive SerDe | Mọi nơi | Mọi loại | Sao chép bằng CTAS hoặc DEEP CLONE |
SYNC nâng cấp bảng external định dạng Delta và Parquet mà không di chuyển dữ liệu, áp dụng cho cả schema hoặc từng bảng, và có thể chạy lặp lại trong thời gian hai metastore cùng hoạt động. Phương pháp sao chép chỉ áp dụng cho dữ liệu định dạng Delta. View phải được tạo lại sau khi các bảng mà view tham chiếu đã chuyển xong.
Chúng tôi xác định phạm vi nâng cấp theo ba cấp độ. Cấp đơn giản nhất chuyển các bảng external cùng hạ tầng tính toán chỉ đọc dữ liệu, và có thể hoàn nguyên dễ dàng. Cấp thứ hai bổ sung bảng managed và các job ghi vào đó. Cấp thứ ba bao trùm toàn bộ job, pipeline và công cụ điều phối bên ngoài. Bắt đầu từ cấp thứ nhất và ưu tiên các khối lượng công việc giá trị cao, rủi ro thấp cũng chính là khuyến nghị của Databricks khi giải đáp các băn khoăn thường gặp: không ai muốn phát hiện một giới hạn khi dự án đã đi được nửa chặng đường.
Với nền tảng có hàng chục hoặc hàng trăm workspace, mô hình chuyển đổi theo giai đoạn duy trì song song một vùng dùng Unity Catalog và một vùng cũ trong khi khối lượng công việc được chuyển dần. Databricks cũng đã phát hành chính thức tính năng liên kết Hive metastore (Hive metastore federation), cho phép Unity Catalog quản trị các bảng vẫn nằm trong metastore hiện có; tính năng này có phù hợp với từng nền tảng hay không là câu hỏi cần trả lời trong bước đánh giá.
Thời gian thực hiện
Thời gian thực hiện do các yếu tố đã nêu quyết định: số lượng bảng managed phải sao chép, khối lượng mã nguồn dùng mount point và tên hai cấp, và tốc độ những người phụ trách đưa ra quyết định về danh tính và lưu trữ.
Sancire bắt đầu từ đâu
Gói Quét hiện trạng chuyển đổi của chúng tôi chạy bước đánh giá trên các workspace của doanh nghiệp và chuyển bản kiểm kê thành kế hoạch: bảng nào chuyển bằng phương pháp nào, quyết định nào về danh tính và lưu trữ cần ai phê duyệt, và ước lượng khối lượng chỉnh sửa mã nguồn. Phần chuyển đổi nằm trong giai đoạn Hiện đại hoá, còn mô hình phân quyền mà Unity Catalog mang lại nằm trong giai đoạn Quản trị.
Nguồn: tài liệu Databricks về nâng cấp lên Unity Catalog và công cụ UCX của Databricks Labs, tra cứu ngày 16/10/2026. 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.