Spark Catalog & AuthZ Foundation

Câu hỏi

Spark query đi qua catalog/analyzer như thế nào trước khi chạy?

Mental model

Một SQL/DataFrame query không nhảy thẳng xuống file. Nó đi qua plan path:

SQL/DataFrame API
  -> parse / build unresolved logical plan
  -> analyzer resolve table, column, function, catalog
  -> optimizer
  -> physical planning
  -> execution

Catalog nằm ở phase resolve:

table name
  -> catalog/session catalog/external catalog
  -> metadata/schema/location/provider

Nếu muốn enforce quyền ở mức table/column/row, analyzer/catalog path là điểm rất mạnh, vì mọi query hợp lệ đều phải resolve metadata trước.

AuthZ baseline

Open-source stack thường ghép:

Spark/Trino
  -> HMS/Iceberg catalog để lấy metadata
  -> Ranger/OPA/custom plugin để check policy
  -> object storage IAM để đọc file

Nhưng nếu storage credential quá rộng, hoặc user có đường đọc raw path, policy ở catalog/query layer có thể bị bypass.

Vì sao liên quan Databricks Runtime

Khi đọc Databricks UC/FGAC, mình cần hỏi:

• ManagedCatalogSessionCatalog thay/bọc catalog path nào?
• CheckPermissions là analyzer rule hay API check?
• Row filter/column mask được rewrite vào logical plan ở đâu?
• InlineUserInfoExpressions giúp policy phụ thuộc user ra sao?
• UC derive path credential từ quyền logical thế nào?

Đọc tiếp

• AuthZ & FGAC
• Credential & Storage Boundary