Unity Catalog 與系譜

Databricks Lakehouse 入門

Gang Wang

Senior Data Scientist

為何治理很重要

多個團隊共用上百張資料表
「行銷團隊能看到客戶財務資料嗎？」
「這份報表怪怪的——底層資料其實從哪裡來？」
Unity Catalog 統一集中解答

recraft: half: 交錯相連的資料管線與資料夾如同迷宮，頭頂漂浮問號，象徵缺乏治理的資料複雜度

Unity Catalog 的階層

Unity Catalog 階層樹狀檢視

Metastore——每個帳戶一個，最上層容器
Catalogs——如「production」或「development」
Schemas——分組相關物件（例如「sales」）
內含 tables、views 與 functions

存取控制

-- Grant read access to a schema
GRANT SELECT
ON SCHEMA production.sales
TO `analytics_team`;

-- Revoke table-level access
REVOKE SELECT
ON TABLE production.sales.customers
FROM `intern_group`;

權限可設在階層中的「每一層」
可在 catalog、schema、table 上授與 SELECT、MODIFY、CREATE
具繼承性——授與 catalog 會套用到其內所有 schemas

資料系譜（Lineage）

這筆資料從哪裡來？

flowchart: bronze_orders（來源）、silver_orders（清理後）、gold_daily_revenue（彙總）、Revenue Dashboard（使用者）

在查詢執行時，自動追蹤表與表的關聯
可追溯上游來源與下游使用者

系譜的實務應用

Upstream——追蹤資料的來源
Downstream——查看哪些相依於此資料表
影響分析——如果我更改此欄位，會壞掉什麼？
偵錯——報表數字不對時，回溯到來源

recraft: half: 偵探手持放大鏡檢視串連的文件與資料表線索，象徵資料系譜調查

重點整理

Unity Catalog——集中治理所有資料資產
階層——metastore → catalog → schema
存取控制——各層皆可用 SQL 授權，並自上而下繼承
系譜——自動追蹤資料流，涵蓋上游與下游

一起來練習吧！

Databricks Lakehouse 入門