Databricks 5 — Unity Catalog (Governance)

Unity Catalog là gì

Unity Catalog (UC) là lớp quản trị (governance) dữ liệu và AI thống nhất của Databricks: một nơi duy nhất để quản lý quyền truy cập, metadata, lineage, audit cho mọi workspace trong tổ chức. Trước UC, mỗi workspace có một Hive metastore riêng, quyền được cấp rời rạc theo cluster/table ACL, không có lineage tự động, không có audit thống nhất — thảm hoạ với một ngân hàng có hàng chục team và yêu cầu tuân thủ khắt khe.

Ý tưởng cốt lõi: tách quản trị ra khỏi tính toán. Cluster/warehouse là nơi chạy query; UC là nơi quyết định ai được thấy gì. Bạn cấp quyền một lần trên đối tượng dữ liệu, và quyền đó áp dụng đồng nhất dù người dùng truy cập từ notebook, SQL warehouse (Databricks 6 — SQL & BI), job hay công cụ BI bên ngoài.

Nếu bạn đã đọc Governance 2 — Catalog & Lineage và Governance 6 — Access Control, UC chính là hiện thân cụ thể của những nguyên tắc đó trên nền Databricks: catalog, lineage, RBAC, masking — tất cả gói trong một sản phẩm.

Không gian tên 3 cấp

Điểm khác biệt kiến trúc rõ nhất so với Hive metastore: UC dùng không gian tên (namespace) 3 cấp thay vì 2 cấp.

• Hive metastore (cũ): schema.table — chỉ 2 cấp, một metastore cho một workspace.
• Unity Catalog: catalog.schema.object — 3 cấp, một metastore dùng chung nhiều workspace.

metastore (cấp vùng — 1 per region)
└── catalog                     (vd: prod, dev, banking_core)
    └── schema (database)        (vd: retail, risk, loan)
        ├── table / view         (bảng, view)
        ├── volume               (file phi bảng: pdf, image, csv thô)
        ├── model                (ML model registry)
        ├── function             (UDF, hàm mask/filter)
        └── materialized view    (kết quả tính sẵn)

Cách gọi đầy đủ: banking_core.risk.loan_application. Trong query bạn có thể USE CATALOG banking_core; USE SCHEMA risk; rồi gọi ngắn loan_application.

Ba cấp cho ta một trục phân tách tự nhiên rất hợp ngân hàng: catalog tách theo môi trường (prod/dev/uat) hoặc theo miền nghiệp vụ/pháp nhân; schema tách theo domain (retail, corporate, risk, finance); object là bảng/view/volume cụ thể. Ranh giới catalog cũng là ranh giới isolation mạnh — thường mỗi catalog gắn với một vị trí lưu trữ (storage location) riêng.

Metastore và gán vào workspace

Metastore là container cấp cao nhất, tạo một metastore cho mỗi region cloud. Metastore chứa toàn bộ catalog và metadata. Admin gán (assign) metastore vào từng workspace: nhiều workspace cùng chia sẻ một metastore ⇒ chia sẻ chung định nghĩa quyền, cùng nhìn thấy cùng dữ liệu (tuỳ quyền). Đây là nền tảng của "một nơi quản quyền cho mọi workspace".

Các đối tượng UC quản lý

Điểm quan trọng: Volume đưa file phi cấu trúc vào cùng một khung quyền như bảng — hợp đồng tín dụng PDF, ảnh CMND eKYC nay được cấp quyền và audit y hệt bảng SQL.

Phân quyền: mô hình GRANT/REVOKE

UC dùng mô hình RBAC kiểu SQL chuẩn: cấp privilege trên đối tượng cho principal (user, service principal, hoặc group).

-- Ví dụ minh hoạ (Databricks SQL — KHÔNG chạy trong sandbox)
GRANT USE CATALOG ON CATALOG banking_core TO `analysts`;
GRANT USE SCHEMA  ON SCHEMA  banking_core.retail TO `analysts`;
GRANT SELECT      ON TABLE   banking_core.retail.customer TO `analysts`;

GRANT MODIFY ON SCHEMA banking_core.risk TO `risk_engineers`;
REVOKE SELECT ON TABLE banking_core.retail.customer FROM `interns`;

Principal đồng bộ từ IdP qua SCIM: user và group không tạo thủ công trong Databricks mà đồng bộ tự động từ Identity Provider (Azure AD/Entra, Okta...) qua chuẩn SCIM. Nhân viên nghỉ việc bị vô hiệu ở IdP ⇒ mất truy cập Databricks ngay. Quyền nên cấp cho group (vd loan_officers), không cấp cho từng user — dễ quản, dễ audit.

Privilege và kế thừa theo cấp

Các privilege chính:

• USE CATALOG / USE SCHEMA — quyền "đi vào" (traverse) một cấp namespace; cần có mới tới được object bên trong.
• SELECT — đọc bảng/view.
• MODIFY — INSERT/UPDATE/DELETE/MERGE dữ liệu.
• CREATE TABLE / CREATE SCHEMA — tạo đối tượng con.
• EXECUTE — chạy function.
• READ VOLUME / WRITE VOLUME — đọc/ghi file trong volume.
• ALL PRIVILEGES — gộp tất cả.

Kế thừa (inheritance): quyền cấp ở cấp cha tự động áp cho toàn bộ con. GRANT SELECT ON SCHEMA banking_core.retail TO analysts ⇒ analysts SELECT được mọi bảng hiện có và sẽ tạo trong schema retail. Đây là con dao hai lưỡi: tiện nhưng dễ cấp thừa. Nguyên tắc ngân hàng: cấp ở cấp thấp nhất đủ dùng, ưu tiên least-privilege.

Ownership: mỗi đối tượng có một owner (thường là group). Owner có toàn quyền và có thể grant tiếp. Đặt owner là group vận hành, không phải cá nhân — tránh "mồ côi" quyền khi người đó nghỉ. Owner cũng là người có thể DROP/ALTER, nên đây là kiểm soát quan trọng.

An ninh nâng cao: row filter, column mask, dynamic view

Cấp quyền toàn bảng chưa đủ với dữ liệu ngân hàng. UC cung cấp kiểm soát mức hàng và mức cột ngay trong catalog (chi tiết nguyên lý ở Governance 6 — Access Control và Governance 7 — Privacy & Compliance).

Row filter (RLS — row-level security): gắn một function vào bảng; function trả về TRUE/FALSE quyết định mỗi hàng có hiện với người đang query hay không.

-- Ví dụ minh hoạ (Databricks SQL — KHÔNG chạy trong sandbox)
-- Function lọc: chỉ thấy hàng thuộc chi nhánh của mình
CREATE FUNCTION banking_core.risk.branch_filter(branch STRING)
RETURN is_account_group_member('all_branches')
    OR branch = current_user_branch();

-- Gắn row filter vào bảng
ALTER TABLE banking_core.retail.loan
  SET ROW FILTER banking_core.risk.branch_filter ON (branch_code);

Column mask (che cột nhạy cảm): gắn function vào một cột; function biến đổi giá trị (che, hash) tuỳ người xem.

-- Ví dụ minh hoạ (Databricks SQL — KHÔNG chạy trong sandbox)
CREATE FUNCTION banking_core.retail.mask_id(id STRING)
RETURN CASE
  WHEN is_account_group_member('pii_readers') THEN id
  ELSE CONCAT('******', RIGHT(id, 3))          -- che số CCCD
END;

ALTER TABLE banking_core.retail.customer
  ALTER COLUMN national_id SET MASK banking_core.retail.mask_id;

Ưu điểm: định nghĩa một lần, áp cho mọi truy cập bảng đó — không phải viết lại logic che ở từng query hay từng dashboard. Nhân viên bình thường thấy ******123, thanh tra AML thuộc group pii_readers thấy số đầy đủ.

Dynamic view: cách cũ hơn nhưng vẫn hữu dụng — tạo view có logic điều kiện dựa trên current_user() / is_account_group_member(), rồi chỉ cấp SELECT trên view chứ không trên bảng gốc. Linh hoạt cho logic phức tạp, nhưng row filter/column mask sạch hơn vì áp thẳng lên bảng.

Lineage tự động

UC tự động ghi lại lineage (dòng chảy dữ liệu) ở mức bảng và cột, end-to-end, cho mọi query chạy trên nền Databricks — không cần cấu hình. Chạy một CREATE TABLE ... AS SELECT hay một notebook, UC ghi nhận bảng/cột nào là nguồn, bảng/cột nào là đích.

Giá trị thực chiến:

• Impact analysis: trước khi đổi schema cột national_id, tra lineage xem những đâu dùng nó — bao nhiêu bảng downstream, dashboard nào, model nào. Tránh vỡ pipeline sản xuất.
• Audit & tuân thủ: chứng minh dữ liệu trong báo cáo NHNN đến từ nguồn nào, đã qua biến đổi gì — bằng chứng cho thanh tra.
• Truy vết sự cố dữ liệu: một con số sai ở dashboard, lần ngược lineage tới bảng nguồn.

Lineage cột (column-level) đặc biệt mạnh: biết chính xác cột pd_score ở bảng risk bắt nguồn từ những cột nào ở bảng giao dịch. So sánh sâu hơn ở Governance 2 — Catalog & Lineage.

Data discovery và audit

Data discovery: UC có giao diện Catalog Explorer để duyệt, search (tìm bảng/cột theo tên), gắn tag (vd pii, confidential, pci), thêm comment/mô tả (kể cả sinh tự động bằng AI). Nhân viên mới tìm "bảng nào chứa dữ liệu khoản vay" thay vì hỏi khắp nơi. Tag còn dùng để tự động áp policy — vd tag pii gắn liền masking.

Audit log: UC ghi ai truy cập gì, khi nào, từ đâu — mọi GRANT, mọi SELECT trên bảng nhạy cảm, mọi lần đọc volume. Log này (giao qua system tables / cloud audit) là bằng chứng bắt buộc cho tuân thủ. Kết hợp với Observability 1 — Overview để giám sát chủ động.

Delta Sharing

Delta Sharing là giao thức mở để chia sẻ dữ liệu an toàn ra ngoài mà KHÔNG copy: bên nhận đọc trực tiếp dữ liệu live từ object storage của bạn qua token, không cần cùng nền tảng Databricks, không cần cùng cloud. Bạn chia sẻ một share (tập bảng/volume), thu hồi bất cứ lúc nào, và mọi truy cập đều được audit.

Với ngân hàng: chia sẻ dữ liệu cho công ty kiểm toán, đối tác bảo hiểm, hoặc chi nhánh nước ngoài — không phải bê file CSV qua email (rủi ro rò rỉ, mất kiểm soát). Dữ liệu không rời khỏi vòng kiểm soát; thu hồi token là cắt truy cập tức thì.

Quản trị AI trong UC

UC không chỉ quản dữ liệu mà cả AI asset: model (versioned trong registry) và feature (feature table/function) được đặt trong cùng namespace 3 cấp, cùng mô hình GRANT, cùng lineage. Nghĩa là bạn kiểm soát ai được deploy model chấm điểm tín dụng, model đó huấn luyện từ bảng nào (lineage), và ai được đọc feature nhạy cảm — tất cả trong một khung governance. Chi tiết ở Databricks 7 — ML & MLflow và MLOps 3 — Feature Store.

Vì sao UC quan trọng với ngân hàng

Ngân hàng chịu Nghị định 13/2023/NĐ-CP về bảo vệ dữ liệu cá nhân và các quy định của NHNN về an toàn hệ thống thông tin. Yêu cầu cốt lõi: kiểm soát truy cập chặt, ghi vết đầy đủ, che dữ liệu nhạy cảm, truy được nguồn gốc dữ liệu. UC gói tất cả vào một điểm kiểm soát duy nhất:

• Quyền: một mô hình GRANT thống nhất, đồng bộ từ IdP, kế thừa rõ ràng — không còn quyền rời rạc khó audit.
• Che dữ liệu: row filter + column mask định nghĩa một lần, áp mọi nơi — CCCD, số tài khoản, thu nhập được che đúng theo vai trò.
• Audit: ai đọc dữ liệu khách hàng nào, lúc nào — sẵn sàng cho thanh tra.
• Lineage: chứng minh nguồn gốc số liệu báo cáo, phục vụ impact analysis khi đổi hệ thống.

Thay vì chứng minh tuân thủ trên hàng chục workspace rời rạc, đội compliance chỉ cần một nơi.

Use case thực tế

Bối cảnh: NCB triển khai UC cho catalog banking_core phục vụ đội Risk và Retail Analytics. Bảng retail.customer (2,4 triệu khách) chứa national_id, phone, income; bảng risk.loan_application chứa hồ sơ vay theo chi nhánh.

Yêu cầu tuân thủ NĐ13: analyst thường KHÔNG được thấy CCCD đầy đủ; cán bộ chi nhánh CHỈ thấy hồ sơ vay của chi nhánh mình; đội AML (group pii_readers) thấy đầy đủ để điều tra.

Các bước triển khai:

1. Đồng bộ group từ Entra qua SCIM: retail_analysts, branch_officers, pii_readers, risk_engineers.
2. GRANT USE CATALOG ON banking_core + GRANT SELECT ON SCHEMA retail cho retail_analysts (kế thừa xuống mọi bảng retail).
3. Column mask mask_id trên customer.national_id: group pii_readers thấy đầy đủ, còn lại thấy ****** + 3 số cuối.
4. Row filter branch_filter trên loan_application: branch_officers chỉ thấy hàng khớp chi nhánh của mình; risk_engineers (thuộc all_branches) thấy toàn bộ.
5. Gắn tag pii cho national_id, phone; bật audit log qua system tables.

Kết quả sau 1 quý: trước UC, đội compliance mất ~3 ngày mỗi kỳ để tổng hợp "ai truy cập dữ liệu PII" từ log rời rạc của 6 workspace. Sau UC, truy vấn một system table ra ngay báo cáo audit. Khi thay đổi schema national_id cho dự án eKYC mới, lineage cột chỉ ra 11 bảng downstream + 4 dashboard phụ thuộc — tránh được sự cố vỡ báo cáo cuối tháng. Delta Sharing thay việc gửi file cho công ty kiểm toán độc lập: share thu hồi được, mọi truy cập có vết.

Ghi nhớ

• UC là lớp quản trị dữ liệu & AI thống nhất của Databricks: một nơi quản quyền/metadata/lineage/audit cho mọi workspace.
• Namespace 3 cấp catalog.schema.object (khác Hive 2 cấp); một metastore per region gán vào nhiều workspace.
• Đối tượng UC quản: managed/external table, view, volume (file phi bảng), model, function, materialized view.
• Phân quyền GRANT/REVOKE cho principal (ưu tiên group đồng bộ IdP qua SCIM); privilege gồm USE/SELECT/MODIFY/EXECUTE...; kế thừa theo cấp; mỗi đối tượng có owner (nên là group).
• An ninh nâng cao: row filter (RLS) và column mask gắn qua function — định nghĩa một lần, áp mọi truy cập; dynamic view cho logic phức tạp.
• Lineage tự động mức bảng/cột end-to-end — phục vụ impact analysis, audit, truy vết sự cố.
• Data discovery (search/tag/comment), audit log (ai truy cập gì), Delta Sharing (chia sẻ ra ngoài an toàn, không copy).
• Với ngân hàng: một điểm kiểm soát cho quyền + che dữ liệu + audit + lineage ⇒ tuân thủ NĐ13/NHNN gọn hơn nhiều workspace rời rạc.