Databricks: Giải pháp thống nhất quản trị dữ liệu trên kiến trúc Open Lakehouse

Trong các bài viết trước, chúng tôi đã chỉ ra cách các định dạng bảng mở (open table formats), API mở và quản trị thống nhất đang kết hợp với nhau để hoàn thiện tầm nhìn Open Lakehouse. Chúng tôi cũng đã giới thiệu tính năng kiểm soát truy cập dựa trên thuộc tính (ABAC) đa công cụ, cho phép các chính sách được xác định trong Unity Catalog được thực thi nhất quán khi các công cụ bên ngoài truy cập vào dữ liệu đã được quản trị.

Giờ đây, tầm nhìn đó đang bắt đầu hiện thực hóa một cách công khai. Cộng đồng Apache Iceberg™ gần đây đã thúc đẩy hai bổ sung quan trọng cho Iceberg REST Catalog: hạn chế đọc (read restrictions) và nhãn danh mục (catalog labels). Cùng với nhau, chúng giải quyết hai thách thức riêng biệt: ủy quyền thực thi cho một công cụ bên ngoài và làm cho ngữ cảnh quản trị có thể di chuyển giữa các danh mục.

Trong bài viết này, chúng ta sẽ xem xét kỹ hơn cả hai bổ sung mới cho đặc tả kỹ thuật: cách chúng hoạt động, những thách thức chính mà chúng giải quyết, các cơ hội đổi mới trong tương lai và khi nào nên sử dụng chúng.

Hạn chế đọc: tiêu chuẩn hóa việc thực thi được ủy quyền

Hạn chế đọc giải quyết một kịch bản phổ biến giữa công cụ và danh mục: một tổ chức quản trị dữ liệu trong một danh mục và muốn truy vấn dữ liệu đó từ nhiều công cụ hoặc nền tảng khác nhau.

Đối với bất kỳ truy vấn được quản trị nào, ba điều phải xảy ra:

Khi dữ liệu được truy cập từ một công cụ, các trách nhiệm này có thể được phân chia theo hai cách.

Với thực thi tập trung, cả ba bước đều nằm trong môi trường của danh mục. Ví dụ, Databricks triển khai kiểm soát truy cập chi tiết trên nền tảng tính toán chuyên dụng bằng cách định tuyến truy vấn một cách minh bạch thông qua một hệ thống lọc bảo mật. Và tính năng ABAC đa công cụ của Unity Catalog mở rộng khả năng quản trị này sang các công cụ khác bằng cách đặt hệ thống lọc phía sau các API quét/lập kế hoạch của Iceberg REST Catalog để làm sạch dữ liệu trước khi một công cụ bên ngoài như Spark hoặc DuckDB xử lý kết quả.

Với thực thi được ủy quyền, danh mục nhận danh tính yêu cầu và đánh giá chính sách, sau đó trả về các hạn chế về hàng và cột cho một công cụ mà nó tin tưởng để thực thi chúng. Ở đây, sự tin tưởng có nghĩa là danh mục có thể dựa vào công cụ để thực thi các hạn chế và ngăn người dùng vượt qua chúng. Các công cụ như Spark và DuckDB không được coi là đáng tin cậy khi người dùng kiểm soát thời gian chạy vì những người dùng đó có thể thực thi mã tùy ý hoặc truy cập trực tiếp vào dữ liệu cơ bản. Một triển khai Trino được cấu hình bảo mật là một ví dụ về công cụ đáng tin cậy vì nó cung cấp khả năng thực thi gốc cho các bộ lọc hàng và mặt nạ cột.

Thực thi được ủy quyền đòi hỏi một hợp đồng chung giữa danh mục và công cụ. Cộng đồng Iceberg đã áp dụng các hạn chế đọc để cung cấp hợp đồng đó.

Cách thức hoạt động của hạn chế đọc

Khi một trình đọc tải một bảng thông qua Iceberg REST Catalog, danh mục sẽ đánh giá các chính sách áp dụng cho chủ thể yêu cầu và ngữ cảnh yêu cầu. Nó có thể trả về các hành động chiếu cột bắt buộc và các biểu thức lọc hàng, và công cụ đáng tin cậy phải áp dụng các hạn chế đó khi nó đọc bảng.

Hai quyết định thiết kế rất quan trọng để hiểu phạm vi hiện tại của đề xuất này.

Thứ nhất, công cụ không nhận chính sách theo cách mà quản trị viên đã xác định. Thay vào đó, nó nhận kết quả cho một chủ thể cụ thể, được thể hiện dưới dạng các hướng dẫn lọc hoặc che giấu mà nó phải áp dụng. Điều này tạo ra một hợp đồng thực thi chung giữa công cụ và danh mục. Đặc tả ban đầu xác định một từ vựng giới hạn: chín hành động chiếu cột được xác định trước và các biểu thức lọc hàng tiêu chuẩn hóa như so sánh hoặc kiểm tra thành viên tập hợp. Nhiều chính sách doanh nghiệp thực tế phụ thuộc vào các truy vấn con, bảng tra cứu hoặc UDF tùy chỉnh, vốn không thể diễn đạt trong từ vựng của hạn chế đọc. Điều này có một hàm ý quan trọng: các chính sách chỉ có thể được biểu diễn khi danh mục có thể giảm kết quả của chúng xuống từ vựng được xác định bởi tiêu chuẩn, nếu không bạn sẽ mất ngữ nghĩa của chính sách.

Thứ hai, đặc tả kỹ thuật xác định những gì một công cụ đáng tin cậy phải thực thi, nhưng không xác định cách danh mục thiết lập sự tin tưởng đó. Một tuyên bố từ phía máy khách là không đủ, vì vậy các quản trị viên hệ thống và các bên triển khai phải sử dụng các cơ chế bảo mật phù hợp với môi trường của họ. Các cuộc thảo luận trong cộng đồng Iceberg đã xem xét các cơ chế như mTLS và OAuth, nhưng sự tin tưởng cuối cùng vẫn nằm ngoài giao thức (thảo luận cộng đồng Iceberg).

Hạn chế đọc phù hợp nhất cho các kịch bản truy cập trực tiếp từ công cụ đến danh mục, nơi các chính sách của danh mục nguồn đơn giản và một công cụ đáng tin cậy có thể thực thi quyết định thu được. Nhiều câu hỏi triển khai vẫn còn đó, chẳng hạn như làm thế nào một công cụ truyền tải danh tính và thuộc tính của người dùng cuối một cách an toàn, làm thế nào một danh mục phân biệt người dùng với công cụ thay mặt người dùng đó, và làm thế nào các thông tin xác thực được gắn với người nhận dự định. Khi các triển khai xuất hiện, chúng tôi rất hào hứng được hợp tác với cộng đồng Iceberg để giải quyết những thách thức này và phát triển tiêu chuẩn.

Nhãn danh mục: làm cho ngữ cảnh quản trị có thể di chuyển

Nhãn danh mục giải quyết một kịch bản khác: quản trị trên các danh mục liên kết (federated catalogs).

Nhiều doanh nghiệp hiện kết nối nhiều danh mục, chẳng hạn như Unity Catalog, Snowflake, AWS Lake Formation và Google Cloud Knowledge Catalog, thông qua liên kết và API mở. Điều này phức tạp hơn so với tích hợp công cụ-vào-danh mục vì mỗi danh mục phục vụ người dùng, ứng dụng và công cụ riêng của mình thông qua các mô hình danh tính, ngôn ngữ chính sách và ngữ nghĩa riêng biệt.

Bất kỳ giải pháp quản trị thống nhất nào hoạt động ở quy mô doanh nghiệp đều phải:

Nhãn danh mục, gần đây đã được cộng đồng Iceberg thông qua, là bước đầu tiên hướng tới tầm nhìn này. Các nhãn cho phép các danh mục trao đổi siêu dữ liệu khóa-giá trị nhẹ ở cấp bảng và cột thông qua API mở. Các nhãn có thể chỉ ra rằng một trường chứa PII, liên kết một tập dữ liệu với một miền kinh doanh hoặc cung cấp các gợi ý ngữ nghĩa cho các mô hình AI. Vì đề xuất này mang tính tổng quát, các nhãn có thể hỗ trợ nhiều trường hợp sử dụng ngoài kiểm soát truy cập, bao gồm khám phá, quyền sở hữu, phân bổ chi phí, ngữ cảnh AI và chất lượng dữ liệu.

Cách thức hoạt động của nhãn danh mục

Khi một danh mục tiêu thụ tải một bảng từ một danh mục sản xuất thông qua liên kết danh mục, danh mục sản xuất sẽ trả về các nhãn ở cấp bảng và cột.

Danh mục tiêu thụ sau đó ánh xạ các nhãn vào các phân loại, thuộc tính hoặc mô hình thẻ gốc của riêng nó. Sau đó, nó đánh giá quyền truy cập bằng cách sử dụng các danh tính và chính sách gốc của mình và thực thi các kiểm soát trong thời gian chạy của riêng nó. Ví dụ, nếu một danh mục sản xuất gắn nhãn một cột ssn là pii=ssn, danh mục tiêu thụ có thể áp dụng một chính sách dựa trên thẻ để che giấu các cột mang nhãn đó.

Vì việc thực thi chính sách vẫn ở mức cục bộ, danh mục tiêu thụ bảo toàn được khả năng biểu đạt của các chính sách gốc của nó và tránh việc phải gọi danh mục sản xuất cho mỗi quyết định truy cập. Mỗi danh mục cũng duy trì độc lập các bản ghi thực thi và dấu vết kiểm toán của mình.

Cần lưu ý rằng các nhãn là các cặp khóa-giá trị mờ. Tiêu chuẩn không xác định ngữ nghĩa chung hoặc định danh ổn định, và dòng dõi (lineage) cho các nhãn không mở rộng ra ngoài danh mục nguồn. Danh mục tiêu thụ chỉ nhận được khóa và giá trị đã giải quyết, chứ không biết liệu nhãn đó có dành cho mục đích khám phá, kiểm soát truy cập, phân bổ chi phí hay mục đích nào khác hay không. Do đó, các nhãn làm cho siêu dữ liệu có thể di chuyển được, nhưng không làm cho ý nghĩa của nó di chuyển theo; các doanh nghiệp vẫn cần các quy ước chung hoặc các ánh xạ rõ ràng để diễn giải các nhãn một cách nhất quán.

Nhãn danh mục phù hợp nhất cho các kịch bản danh mục-vào-danh mục với sự liên kết giữa các hệ thống không đồng nhất, nơi danh mục tiêu thụ có hệ thống quản trị riêng và cần ngữ cảnh có thể tái sử dụng thay vì một quyết định truy cập riêng biệt cho mỗi người dùng và yêu cầu.

Nhãn danh mục là một bước tiến tới tầm nhìn dài hạn về trao đổi chính sách mở. Trong thế giới này, các danh mục đáng tin cậy trao đổi ngữ cảnh quản trị và cuối cùng là các định nghĩa chính sách thông qua các API mở, trong khi mỗi nền tảng đánh giá và thực thi các kiểm soát bằng cách sử dụng mô hình danh tính và thời gian chạy gốc của nó. Ý tưởng cốt lõi là quản trị và ngữ cảnh kinh doanh, giống như siêu dữ liệu bảng, nên mở và có thể di chuyển thông qua các API của Iceberg REST Catalog.

Chọn mô hình phù hợp

Mô hình phù hợp phụ thuộc vào đích đến: thực thi tập trung cho một công cụ không đáng tin cậy, hạn chế đọc cho một công cụ đáng tin cậy và nhãn danh mục làm nền tảng cho trao đổi chính sách mở khi đích đến là một danh mục khác với hệ thống quản trị riêng của nó.

Thực thi tập trung thông qua lập kế hoạch quét

Hạn chế đọc

Nhãn danh mục

Cách thức hoạt động

Danh mục nguồn đánh giá và thực thi chính sách thông qua dịch vụ lọc bảo mật, chỉ trả về dữ liệu được ủy quyền

Tại thời điểm truy vấn, danh mục cho công cụ biết các hạn chế cần áp dụng cho người dùng và tài sản cụ thể này - ví dụ: “áp dụng mask_alphanum trên cột 12”

Các danh mục chia sẻ thông tin quản trị hoặc kinh doanh bổ sung về một bảng nhất định - ví dụ: “cột 12 có phân loại pii=ssn”