1. 课程导入与场景锚定

在多数已经建成数据平台的企业里，数据并不是"没有"，而是"拿不到、不敢给、给不准、给不快"。业务团队想要一份用户行为明细，往往要经历"提需求—排期—导数—发文件—对口径"的漫长链路；数据团队则疲于应付重复取数，还要承担权限外溢与合规审计的压力。跨团队协作的瓶颈，通常不在计算能力，而在共享机制。

先看四个高频痛点。第一是数据孤岛：交易数据在订单库、行为数据在埋点仓、客户主数据在 CRM，各自被不同团队持有，物理隔离加上组织边界，导致"同一家公司、不同真相"。第二是权限混乱：权限往往授予在文件目录或工作区层级，一旦某人离职或转岗，散落在 Notebook、Dashboard、临时表上的授权难以回收，出现"看不见的越权"。第三是重复拷贝：为了共享，团队习惯把数据导出成 CSV 或 Parquet 再通过邮件、对象存储传递，一份数据被复制成 N 份副本，既浪费存储，也让血缘断裂、口径漂移。第四是协作低效：数据提供方与消费方之间缺少统一的契约，字段变更不通知、SLA 不明确，消费方上线后才发现上游已改列名。

这四类痛点并非孤立，它们彼此强化：孤岛催生拷贝，拷贝放大权限失控，权限失控又让团队更不敢开放数据，最终协作效率持续走低。要打破这个循环，需要一套"不搬数据也能共享、不靠人工也能管权限、不改代码也能跨源查询"的机制。这正是 Databricks 数据共享与协作能力地图要解决的问题。

上图给出了本课程的主线：痛点驱动能力，能力落到具体对象。左侧四类痛点并不是要逐个"消灭"，而是通过中间四项能力形成组合拳，最终由右侧四组对象承载。下面把这条主线拆开讲清楚。

Unity Catalog：把"权限混乱"变成可治理的命名空间

Unity Catalog 的核心价值是提供统一的三级命名空间：catalog.schema.table。例如 sales_prod.orders.fact_order 表示目录 sales_prod、模式 orders、表 fact_order。所有数据对象——表、视图、函数、模型、卷——都注册在这套命名空间下，权限也按此层级授予。常见做法是：在 catalog 层授予团队"可用"，在 schema 层授予"可读"，在表层做精细化控制。这样当成员转岗时，只需调整其所属组的成员关系，权限随组自动收敛，而不是逐张表回收。

需要强调的是，Unity Catalog 不只是"权限系统"，它同时承载血缘、审计与发现。当消费方在 Catalog Explorer 中检索到一张表时，可以同时看到它的上游来源、最近访问者与列级注释，这直接缓解了"口径不一"和"变更不通知"的问题。

Delta Sharing：把"重复拷贝"变成一次授权

Delta Sharing 是一种开放共享协议，它的关键特征是数据不移动。提供方在 Unity Catalog 中创建一个 Share，把若干表加入其中，再创建一个 Recipient（接收方）并生成凭证文件；接收方拿到凭证后，即可在自己的 Databricks 工作区或任意兼容客户端中读取这些表。整个过程没有导出 CSV、没有对象存储中转，数据始终留在提供方侧，接收方按需拉取。

这里有一个容易被忽略的细节：Share 中的表可以是动态视图，从而按接收方身份过滤行或列。例如提供方可以定义一个视图，只暴露 region = 'APAC' 的订单，接收方即使拿到凭证，也只能看到被授权的子集。这把"共享"和"最小权限"统一到了一起。

Lakehouse Federation：把"数据孤岛"变成可查询的外部源

现实中并非所有数据都能立刻迁入湖仓。业务系统仍跑在 PostgreSQL、MySQL、Snowflake 或 SQL Server 上。Lakehouse Federation 允许在 Unity Catalog 中创建外部连接（Connection），再基于连接创建外部目录（Foreign Catalog），把远端库的表映射为可查询对象。用户用统一的 SQL 就能跨源关联，例如把湖仓中的 fact_order 与 PostgreSQL 中的 dim_customer 做 join，而无需先把客户维表同步过来。

联邦查询适合"低频、探索性、维表类"的访问；对高频大表仍建议入湖。这个取舍判断，是后续章节会反复用到的工程直觉。

Databricks SQL 与 Workflows：把"协作低效"变成可交付的闭环

共享的终点是"被用起来"。Databricks SQL 提供 SQL 仓库与 Dashboard，让业务分析师无需写 Python 就能查询已授权的表；Workflows 则负责把"抽取—转换—校验—发布"编排成定时任务，并在失败时告警。两者结合，数据提供方可以对外承诺明确的刷新时间与数据质量门槛，消费方也能据此安排下游任务，协作从"口头约定"变成"可观测的契约"。

回到最初的四个痛点，可以看到它们对应的并不是四个独立工具，而是一条从治理到共享、从共享到查询、从查询到交付的链路。理解这条链路，比记住任何单个命令都重要。接下来的章节，我们就从 Unity Catalog 的命名空间与权限模型开始，把这条链路逐段落地。