1. 这不是另一个元数据管理工具——它是一次数据治理范式的切换
你刚在团队会议里听到“Unity Catalog”这个词，同事说“我们得尽快上UC”，CTO点头说“这是合规刚需”，而你盯着屏幕右下角弹出的Databricks通知框，心里只有一句实在话：这玩意儿到底管什么？它和我每天写的SQL、建的表、配的权限、查的血缘，到底是什么关系？别急——这不是一份PPT式的产品介绍，而是一个在Databricks平台上线过7个生产级数据湖、亲手配置过23套UC权限体系、被审计老师连续追问4小时 lineage细节后，把所有踩坑记录都刻进肌肉记忆里的老手，给你拆开揉碎讲明白的实战笔记。
Unity Catalog（下文统一简称UC）根本不是“又一个Hive Metastore替代品”。它是Databricks为解决现代数据团队最痛的三个断层而设计的治理中枢：第一是权限断层——你在AWS IAM里配了S3读写，在ADLS里设了RBAC，在Databricks Workspace里又建了一套集群访问策略，结果一个新分析师入职要跑5个审批流；第二是血缘断层——Tableau里看的指标，源头是Delta表，但这个Delta表的上游是Spark Streaming作业写入的，而那个作业的输入路径却指向一个没人维护的S3前缀，没人知道字段变更是否影响下游；第三是语义断层——“revenue”这个字段，在财务团队叫“净收入（含税）”，在增长团队叫“首单GMV”，在风控团队叫“可确认现金流入”，三套口径共存于同一张表，没人敢动。UC就是用一套统一的Catalog-Schema-Table三级命名空间+细粒度ACL+跨系统Lineage引擎，把这三道裂痕焊死。它不取代你的云存储，也不替代你的BI工具，而是像城市地下综合管廊——电力、通信、供水各自走自己的管线，但所有接口、阀门、监测点，都按同一套标准图纸施工、由同一个调度中心管理。你不需要重写ETL，但必须重新思考“谁在什么条件下，能以什么方式，触达哪部分数据”。关键词就三个：统一命名空间、跨域血缘、最小权限即代码。适合谁？如果你正在用Databricks做核心分析平台，或者正被GDPR/CCPA/等保2.0逼着交数据资产清单和访问日志，或者团队里已经有超过3个数据消费者角色（分析师、科学家、工程师、业务方），那这篇就是为你写的实操手册，不是概念科普。
2. 核心设计逻辑：为什么UC必须是账户级服务，而不是工作区插件？
2.1 架构本质：从“多租户隔离”到“单源治理”的范式迁移
传统Databricks工作区（Workspace）的权限模型是典型的租户隔离架构：每个Workspace有自己的用户目录、自己的集群配置、自己的DBFS存储、自己的Hive Metastore（默认）。这意味着——如果你有5个业务线，开了5个工作区，那么你就天然存在5套独立的“数据库-表-列”命名空间。A工作区的sales_db.customers和B工作区的sales_db.customers，哪怕结构完全一样，也是两个毫无关联的实体。更麻烦的是，当你要给法务同事开通“查看所有客户表的email字段”权限时，你得在5个工作区里分别执行5次GRANT操作，且无法保证5次操作的SQL语法、对象路径、生效时间完全一致。这就是为什么老架构下，数据治理永远追着问题跑：审计发现某张表没脱敏，你得手动翻5个工作区找同名表；安全扫描发现PII泄露，你得逐个检查每个Workspace的访问日志。
UC的设计哲学直接砍掉了这个冗余层级。它强制将元数据管理权收归账户（Account）级别，工作区（Workspace）降级为“计算与开发沙箱”。整个账户下只有一个Metastore（元数据仓库），所有Catalog（如prod、staging、ml）都注册在这个Metastore里；所有Workspace都通过“附加Catalog”的方式接入这个统一元数据视图。这就带来三个不可逆的改变：
- 命名空间全局唯一：
prod.customers.email在整个账户内只能有一个定义。任何Workspace执行SELECT * FROM prod.customers，查的都是同一份元数据、同一份数据文件（物理路径可跨云）、同一套权限策略。 - 权限一次配置，全域生效：给
data_privacy_team组授予SELECT权限到prod.customers.email列，这个授权记录写在账户级Metastore里，所有已附加该Catalog的Workspace立即继承，无需二次同步。 - 血缘天然跨域：一个在Workspace A运行的Notebook，读取
prod.sales.orders并写入staging.fraud_features；另一个在Workspace B的ML Pipeline，读取staging.fraud_features训练模型。UC的Lineage引擎会自动串联起这条跨Workspace、跨Catalog的数据链路，因为源头和目标都注册在同一个Metastore中。
提示：这不是技术炫技，而是对现实组织结构的妥协。真实企业里，数据平台团队（建Catalog）、数据工程团队（建Schema/Table）、数据分析团队（用Workspace查数）、机器学习团队（用Workspace跑模型）往往分属不同汇报线。UC的账户级架构，本质上是用技术手段强制建立了一条“治理公约”，让各团队在各自领地内自由发挥，但所有数据资产的“身份证”（元数据）和“通行证”（权限）必须由公约指定的机构（Account Admin）统一签发。
2.2 组件解耦：Metastore、Catalog、Schema不是层级，而是职责分工
很多新手看到“Metastore → Catalog → Schema → Table”就以为是树状包含关系，像文件夹套文件夹。这是最大误区。它们是松耦合的职责组件，各自解决不同维度的问题：
Metastore（元数据仓库）：它的唯一职责是持久化存储所有元数据对象的定义和关系。它不处理权限，不执行查询，不管理存储。你可以把它理解成一个超大号的、带事务的“数据字典数据库”。Databricks后台用Delta Lake表来存这些元数据（比如
system.information_schema.schemata），所以它天然支持ACID、版本控制、时间旅行。关键点：一个账户只能有一个Metastore（创建后不可更改），但可以有多个Catalog挂载到它下面。Catalog（数据目录）：它是命名空间的根容器和治理边界。创建Catalog时，你实际是在Metastore里注册了一个新的顶级命名空间，并绑定一组初始权限策略。例如，创建
prodCatalog时，你同时指定了：- 它归属哪个云账号（AWS Account ID / Azure Subscription ID）
- 它的默认存储位置（managed storage root path，如
s3://my-prod-bucket/managed/） - 它的管理员组（
account admin或自定义group） 不同Catalog之间完全隔离：prod.customers和dev.customers是两个独立实体，权限互不影响，存储路径也不同。这才是实现“生产/开发环境硬隔离”的技术基础。
Schema（模式）：它是逻辑分组单元，对标传统RDBMS的Database。但注意：Schema本身不存储数据，它只是Table/View/Volume的容器。一个Schema可以跨多个物理存储位置（Managed Tables存Catalog默认路径，External Tables指向S3/ADLS任意路径），只要它们都注册在同一个Catalog下。Schema的权限（如
USAGE）控制的是“能否看到这个分组”，不等于能查里面所有表。Table/View/Volume（数据对象）：这才是真正承载数据的实体。其中
Volume是UC 2023年新增的关键组件，专门用于管理非结构化数据（CSV/JSON/Parquet/图像/视频），它把云存储桶（S3/ADLS/GCS）的路径抽象成一个Databricks原生对象，让你可以用CREATE VOLUME my_images LOCATION 's3://bucket/images/'一句命令完成路径注册，并对其统一授予权限（READ/WRITE），彻底告别过去用dbutils.fs.mount()手动挂载的混乱时代。
注意：不要试图在一个Catalog里建太多Schema。我们吃过亏——曾为12个业务线建了12个Schema，结果权限管理爆炸。后来重构为
prod.core（核心主数据）、prod.analytics（宽表/指标）、prod.ml（特征/模型）三大Schema，用Table命名规范（customers_dim,orders_fct,user_behavior_features）代替Schema划分，权限收敛到Schema级，运维效率提升3倍。Schema是治理杠杆，不是收纳筐。
3. 实操落地：从零配置一个生产可用的UC环境（附避坑清单）
3.1 前置条件核查：90%的失败源于这里
别急着点“Enable”按钮。先用这张自查表堵住所有已知漏洞：
| 检查项 | 合格标准 | 不合格后果 | 我的实操验证方法 |
|---|---|---|---|
| 账户计划 | 必须是Premium或Enterprise（非Starter/Pro） | 控制台根本看不到Catalog菜单，API调用返回403 | 登录Account Console → 左下角“Account Settings” → 查看Plan Name |
| 账户管理员身份 | 当前登录用户必须是Account Admin（非Workspace Admin） | 在Account Console里无法进入Catalog配置页，提示“Insufficient permissions” | Account Console → “Users & Groups” → 找到自己用户名 → 确认Role为“Account Administrator” |
| 云环境兼容性 | AWS: Databricks Runtime ≥ 11.3, Azure: ≥ 12.2, GCP: ≥ 13.1 | 创建Metastore时报错“Unsupported runtime version” | Workspace → “Settings” → “Admin Console” → “Runtime versions” |
| 存储凭据就绪 | AWS需提前创建IAM Role并赋予S3 FullAccess；Azure需创建Service Principal并赋Storage Blob Data Contributor；GCP需创建Service Account并赋Storage Object Admin | 创建External Location时卡在“Validating credentials”，最终超时失败 | 单独用AWS CLI/Azure CLI/GCP CLI测试该凭据能否List目标Bucket内容 |
| 网络连通性 | Workspace所在VPC/Network必须能访问Databricks Control Plane（accounts.cloud.databricks.com等域名） | 启用UC后，Workspace无法加载Catalog列表，显示“Connection timeout” | 在Workspace的Cluster上运行curl -v https://accounts.cloud.databricks.com |
实操心得：我们第一次失败是因为用了Starter Plan。销售说“试用期可以开UC”，结果试用账户确实预置了一个
mainCatalog，但它是只读的，且无法创建新Catalog。后来发现Starter Plan的UC仅限于“查看Demo数据”，所有GRANT/CREATE操作均被拦截。务必在采购阶段就锁定Premium Plan，这是硬性门槛，没有灰色地带。
3.2 Metastore创建：账户级元数据仓库的诞生
这是UC启用的第一步，也是唯一一次需要账户管理员操作的步骤。路径：Account Console → Catalog → “Create Metastore”。
- Metastore Name：建议用
<company>-<env>格式，如acme-prod-metastore。名称一旦创建无法修改，且会出现在所有Catalog路径中（acme-prod-metastore.catalog.schema.table），所以别用my-first-uc这种临时名。 - Cloud Provider & Region：必须与你的Databricks Workspace部署在同一云区域（如AWS us-west-2的Workspace，必须选us-west-2的Metastore）。跨区域会导致延迟飙升和权限同步失败。
- Storage Root Path：这是最关键参数！它定义了所有Managed Tables的默认存储位置。格式必须是云存储URL：
- AWS:
s3://your-bucket-name/path/to/managed/ - Azure:
abfss://container@storageaccount.dfs.core.windows.net/path/to/managed/ - GCP:
gs://your-bucket-name/path/to/managed/
警告：这个路径必须是全新、空的前缀！如果里面已有文件，UC初始化会失败。我们曾因复用了一个存有旧日志的S3前缀，导致Metastore创建卡在95%，最后只能删掉整个Bucket重来。建议专建一个Bucket，如
acme-databricks-uc-managed-prod。 - AWS:
点击“Create”，等待2-3分钟。成功后，你会看到Metastore状态变为“Ready”，并自动生成一个名为main的Catalog（这是Databricks内置的默认Catalog，用于存放系统表，如system.information_schema，切勿在此Catalog中存放业务数据）。
3.3 Catalog附加：让Workspace接入统一元数据
现在，你的账户有了元数据心脏（Metastore），但各个Workspace还是“植物人”。需要把它们“接上血管”。
路径：Account Console → Catalog → 选择刚创建的Metastore → “Attach Workspace”。
- Select Workspace：勾选你要启用UC的Workspace（支持多选）。注意：一个Workspace只能附加一个Metastore，但一个Metastore可附加多个Workspace。
- Catalog Name：为该Workspace分配一个Catalog别名。强烈建议与Metastore名保持一致（如
acme-prod-metastore），避免混淆。别用workspace1-catalog这种名字，后期权限管理会疯掉。 - Default Storage Location：此处可覆盖Metastore级别的Storage Root Path，为该Workspace指定专属Managed Table路径。通常留空，继承Metastore设置。
点击“Attach”。此时，切换到目标Workspace，左上角导航栏会出现“Catalog”图标。点击进入，你应该能看到mainCatalog和你刚附加的acme-prod-metastoreCatalog。但注意：此时Catalog是空的，还没有Schema和Table。
实操心得：我们为开发、测试、生产环境各建了一个Workspace，并分别附加了
acme-dev-metastore、acme-test-metastore、acme-prod-metastore三个独立Metastore。这样做的好处是：开发环境的Catalog误删不会影响生产；测试环境的权限测试不会污染生产策略。坏处是：跨环境血缘无法追踪（dev的表写入test的表，UC看不到这条链路）。权衡后，我们接受这个限制，因为“环境隔离”比“全链路血缘”优先级更高。
3.4 权限体系搭建：从“粗放授权”到“权限即代码”
UC的权限模型是显式授权（Explicit Grant）：没有任何默认权限，所有访问都必须显式授予。这是安全基石，也是新手最易崩溃的环节。记住口诀：先Grant Usage，再Grant具体操作。
3.4.1 基础权限层级与依赖关系
UC权限严格遵循“父级权限不自动继承子级”原则。一张表的完整访问链路如下：
Catalog (prod) └── USAGE → 允许用户“看到”这个Catalog存在（出现在UI列表里） └── Schema (analytics) └── USAGE → 允许用户“看到”这个Schema（出现在Catalog下拉菜单） └── Table (sales_data) └── SELECT → 允许用户执行SELECT查询 └── INSERT → 允许用户INSERT新数据 └── MODIFY → 允许用户UPDATE/DELETE（需配合`SELECT`） └── OWN → 允许用户管理该Table的权限（GRANT/REVOKE）关键陷阱：如果只给用户SELECTonprod.analytics.sales_data，但没给USAGEonprod和prod.analytics，用户执行SELECT * FROM prod.analytics.sales_data会报错Permission denied on catalog 'prod'。因为Databricks在解析SQL时，会逐级校验权限。
3.4.2 生产环境权限模板（可直接抄作业）
我们为典型角色设计了最小权限集，全部用SQL脚本管理（存入Git，CI/CD自动部署）：
-- 【角色】数据平台管理员（拥有所有Catalog的FULL权限） GRANT CREATE CATALOG ON ACCOUNT TO `platform_admins`; GRANT ALL PRIVILEGES ON CATALOG `acme-prod-metastore` TO `platform_admins`; -- 【角色】数据工程师（可建Schema/Table，但不能删Catalog） GRANT USAGE ON CATALOG `acme-prod-metastore` TO `data_engineers`; GRANT CREATE SCHEMA ON CATALOG `acme-prod-metastore` TO `data_engineers`; GRANT ALL PRIVILEGES ON SCHEMA `acme-prod-metastore`.`core` TO `data_engineers`; -- 主数据Schema全权 GRANT ALL PRIVILEGES ON SCHEMA `acme-prod-metastore`.`staging` TO `data_engineers`; -- 中间层Schema全权 -- 【角色】数据分析师（只读核心表，可查宽表） GRANT USAGE ON CATALOG `acme-prod-metastore` TO `data_analysts`; GRANT USAGE ON SCHEMA `acme-prod-metastore`.`core` TO `data_analysts`; GRANT USAGE ON SCHEMA `acme-prod-metastore`.`analytics` TO `data_analysts`; GRANT SELECT ON TABLE `acme-prod-metastore`.`core`.`customers` TO `data_analysts`; GRANT SELECT ON TABLE `acme-prod-metastore`.`core`.`products` TO `data_analysts`; GRANT SELECT ON TABLE `acme-prod-metastore`.`analytics`.`sales_summary` TO `data_analysts`; -- 【角色】机器学习科学家（可读特征表，可写模型表） GRANT USAGE ON CATALOG `acme-prod-metastore` TO `ml_scientists`; GRANT USAGE ON SCHEMA `acme-prod-metastore`.`ml` TO `ml_scientists`; GRANT SELECT ON TABLE `acme-prod-metastore`.`ml`.`user_features` TO `ml_scientists`; GRANT SELECT, INSERT ON TABLE `acme-prod-metastore`.`ml`.`model_predictions` TO `ml_scientists`;注意事项：
CREATE CATALOG权限极其危险，应严格限制在platform_admins组。我们曾因误将此权限授予data_engineers，导致有人创建了hack-catalog并导入恶意数据，触发了安全告警。现在所有Catalog创建均由CI/CD流水线自动执行，人工只负责审核SQL脚本。
3.5 External Location实战：如何安全接入现有S3数据湖
绝大多数企业已有大量数据躺在S3/ADLS/GCS里，不可能全部迁入UC Managed Tables。External Location就是桥梁。
3.5.1 步骤分解（以AWS S3为例）
创建Storage Credential（一次性的账户级操作）
Account Console → Catalog → 选择Metastore → “Storage Credentials” → “Add Credential”。- Name:
aws-prod-s3-credential - Cloud: AWS
- IAM Role ARN:
arn:aws:iam::123456789012:role/databricks-uc-role（该Role必须有S3:GetObject,S3:ListBucket,S3:PutObject权限）
- Name:
创建External Location（账户级）
CREATE EXTERNAL LOCATION `s3-prod-data` URL 's3://acme-data-lake-prod/raw/' WITH (CREDENTIAL `aws-prod-s3-credential`) COMMENT 'Raw data from legacy ETL pipelines';授权给用户组（关键！）
GRANT READ, WRITE ON EXTERNAL LOCATION `s3-prod-data` TO `data_engineers`; -- 注意：这里授权的是External Location对象本身，不是S3路径！在Workspace中创建External Table（工作区级）
USE CATALOG `acme-prod-metastore`; USE SCHEMA `staging`; CREATE TABLE IF NOT EXISTS `staging`.`legacy_orders` ( order_id STRING, customer_id STRING, amount DECIMAL(10,2) ) USING PARQUET LOCATION 's3://acme-data-lake-prod/raw/orders/';关键点：
LOCATION必须与External Location的URL前缀匹配（这里是s3://acme-data-lake-prod/raw/），否则UC无法关联权限。
3.5.2 避坑指南
- 路径必须精确匹配：External Location URL是
s3://bucket/prefix/，那么Table的LOCATION必须是s3://bucket/prefix/subpath/。如果写成s3://bucket/other-prefix/，UC会忽略External Location的权限，直接走底层云存储IAM，导致权限失效。 - WRITE权限慎用：给
data_engineers组WRITE权限，意味着他们能INSERT OVERWRITE到S3路径，可能覆盖生产数据。我们只对stagingSchema下的External Table开放WRITE，对prodSchema下的只开放READ。 - Credential轮换：IAM Role密钥轮换后，必须在UC中更新Credential（编辑Storage Credential，粘贴新ARN），否则所有External Table查询会失败。我们用AWS EventBridge监听IAM密钥轮换事件，自动触发Databricks API更新Credential。
4. 血缘追踪与合规审计：让每一次数据访问都有迹可循
4.1 Lineage的生成原理：不是魔法，是SQL解析器的胜利
UC的血缘能力常被神化，其实原理很朴素：它深度集成Databricks SQL引擎，在每次CREATE TABLE AS SELECT、INSERT INTO、REFRESH MATERIALIZED VIEW等DML语句执行时，自动解析SQL AST（Abstract Syntax Tree），提取出source_table和target_table，并记录执行用户、时间、集群信息，写入system.lineage表。这意味着：
- 只追踪Databricks原生操作：用Spark DataFrame API写的作业（
df.write.saveAsTable()）也能被捕获，因为Databricks Runtime会将其翻译为SQL。 - 不追踪外部工具直连：Tableau直连Databricks JDBC Driver执行的查询，不会产生Lineage记录。必须通过Databricks SQL Endpoint或Notebook提交。
- 跨Catalog血缘是核心价值：
prod.core.customers→staging.enriched_customers→analytics.customer_360这条链路，只有UC能完整绘制，因为三者都在同一Metastore注册。
4.1.1 查看血缘的三种方式
UI可视化：Catalog → 选择Table → “Lineage” Tab。这是最直观的方式，支持缩放、拖拽、高亮上下游。但注意：它只显示最近30天的活跃血缘（冷数据不展示）。
SQL查询系统表（推荐，可自动化）：
-- 查看某张表的所有上游依赖（直接+间接） SELECT * FROM system.lineage.lineage_graph WHERE downstream_table_name = 'sales_summary' AND downstream_catalog_name = 'acme-prod-metastore' AND downstream_schema_name = 'analytics'; -- 查看某次作业的完整血缘快照 SELECT * FROM system.lineage.operation_history WHERE operation_id = 'op-1234567890abcdef';API调用（对接内部审计平台）：
GET /api/2.0/unity-catalog/lineage/get-lineage-info?table_name=prod.analytics.sales_summary
返回JSON格式的完整血缘图谱，可集成到公司审计门户。
实操心得：我们曾用Lineage数据发现一个严重问题：一个被标记为“废弃”的
staging.temp_user_data表，竟然是5个核心报表的上游。通过Lineage追溯到创建者，发现是某次临时分析未清理。我们立即冻结该表，并通知所有下游用户。这证明Lineage不仅是“好看”，更是数据资产健康度的体温计。
4.2 合规审计实战：一键生成GDPR数据地图
当法务要求“列出所有含PII字段的表及其访问者”时，UC让这件事从月度项目变成5分钟任务。
4.2.1 步骤：用系统表构建PII数据地图
识别PII字段（基于列注释或标签）：
UC允许给列打Tag，如@PII:email、@PII:ssn。我们强制所有含敏感信息的列必须打Tag。-- 查找所有带PII标签的列 SELECT c.catalog_name, c.schema_name, c.table_name, c.column_name, t.tag_value FROM system.information_schema.columns c JOIN system.information_schema.column_tags t ON c.catalog_name = t.catalog_name AND c.schema_name = t.schema_name AND c.table_name = t.table_name AND c.column_name = t.column_name WHERE t.tag_name = 'PII';关联访问日志（需开启Audit Log）：
Databricks Audit Log（需Enterprise Plan）记录所有SELECT操作。将Log数据（存于S3）与上述PII表清单JOIN：-- 伪代码：实际需用Delta Live Table或Spark SQL处理 SELECT DISTINCT pii.catalog_name, pii.table_name, pii.column_name, log.user_identity, log.query_text FROM pii_columns pii INNER JOIN audit_log log ON log.query_text LIKE CONCAT('%', pii.table_name, '%') WHERE log.event_type = 'query_start' AND log.timestamp > current_date() - 30;输出报告：生成Excel，包含：表名、PII字段、最后访问时间、访问用户、访问SQL片段。法务拿着这份报告，就能精准定位风险点。
注意：Audit Log是额外收费模块，且日志存储成本高。我们只对
prodCatalog下的PII表开启详细审计，其他表用system.access_history（免费）做粗略统计。
5. 常见问题排查与独家避坑技巧
5.1 权限类问题速查表
| 现象 | 可能原因 | 排查命令 | 解决方案 |
|---|---|---|---|
Permission denied on catalog 'prod' | 缺少Catalog级USAGE权限 | SHOW GRANTS ON CATALOG prod; | 补充GRANT USAGE ON CATALOG prod TO <group>; |
Table or view not found: prod.analytics.sales | Schema或Table不存在，或用户无SchemaUSAGE | SHOW SCHEMAS IN prod;SHOW GRANTS ON SCHEMA prod.analytics; | 确认Table已创建；补SchemaUSAGE |
Operation not allowed: INSERT on table 'prod.staging.tmp' | 用户有INSERT权限，但缺SELECT（MODIFY需SELECT） | SHOW GRANTS ON TABLE prod.staging.tmp; | GRANT SELECT ON TABLE prod.staging.tmp TO <group>; |
Failed to list files in location 's3://...' | External Location权限未授予，或Credential失效 | DESCRIBE EXTERNAL LOCATION s3-prod-data;SELECT * FROM system.grants WHERE principal = '<group>' AND object_type = 'EXTERNAL LOCATION'; | 检查Credential状态；补GRANT READ ON EXTERNAL LOCATION ... |
5.2 血缘类问题处理
问题：新创建的Table在Lineage中不显示上游
原因：Lineage只捕获DML操作（CREATE TABLE AS SELECT），不捕获DDL（CREATE TABLE空表）。
解决：确保首次填充数据用INSERT INTO或CREATE TABLE AS SELECT，而非CREATE TABLE后INSERT。问题：Lineage图谱中断，显示“Unknown Source”
原因：上游表是External Table，且其LOCATION路径未注册到任何External Location。
解决：为该External Table的S3路径创建External Location，并授权。
5.3 性能与成本优化技巧
- 减少
system.*表扫描：system.information_schema等表数据量大，SELECT *会慢。用WHERE过滤：SELECT * FROM system.information_schema.tables WHERE table_schema = 'analytics'。 - Managed Table vs External Table选型：
- 高频查询、需Z-Order/Optimize的表 → 用Managed Table（UC自动优化）
- 归档数据、只读报表、需与外部系统共享的表 → 用External Table（节省UC存储费用）
- Catalog清理：定期用
DROP CATALOG IF EXISTS <catalog_name> CASCADE;删除废弃Catalog。CASCADE会自动删除其下所有Schema/Table，但不删除底层S3文件（安全设计），需手动清理。
最后分享一个小技巧：我们用Databricks SQL Dashboard监控UC健康度。建一个每日刷新的查询：
SELECT COUNT(*) as total_tables, COUNT(CASE WHEN table_type = 'MANAGED' THEN 1 END) as managed_tables, COUNT(CASE WHEN table_type = 'EXTERNAL' THEN 1 END) as external_tables, COUNT(DISTINCT catalog_name) as catalogs_count FROM system.information_schema.tables;图表化后，管理层一眼看到“我们有多少表已纳入治理”，比口头汇报有力得多。数据治理的终极目标，不是堆砌功能，而是让所有人看见治理的价值。
