📚 课程目录第1章课程导入

1. 课程导入

在多数数据平台里，数据共享往往被当成一个“导出—传输—再导入”的搬运问题：团队 A 把结果表导出成文件，团队 B 下载后再加载进自己的库。这个模式在 Snowflake 里被彻底改写。Snowflake 的共享（Share）机制让数据提供方把数据库、模式、表、视图、安全视图甚至 UDF 的访问权授予另一个 Snowflake 账户，消费方在自己的账户里直接查询这些对象，数据本身不发生物理复制，也不需要对方提供计算资源。理解这一点，是理解整个跨团队协作体系的地基。

本课程的学习目标可以归纳为四条主线。第一，机制层：掌握 Share、Database Role、Secure View、Reader Account、Data Exchange、Listing 等对象的语义与边界，知道什么能被共享、什么不能。第二，实现层：能够用 SQL 完成从创建共享、授权对象、添加消费方账户到消费方创建数据库的完整链路，并能用 SHOW SHARES、SHOW GRANTS TO SHARE 等命令验证状态。第三，治理层：理解共享场景下的权限最小化、行级/列级过滤、数据脱敏、访问审计与成本归属。第四，协作层：把共享放进真实的跨团队流程中，包括需求确认、数据契约、版本演进、故障排查与退出机制。

核心价值一句话概括：共享的是访问权，不是数据副本。由此带来三个直接收益——消费方读取的是提供方存储上的“实时”数据，延迟取决于提供方表的更新节奏；提供方无需为消费方承担查询计算成本（消费方用自己的虚拟仓库付费）；权限回收即时生效，不需要追回已下发的文件。

为了把上述目标落到可执行的路径上，先建立整体知识框架。Snowflake 数据共享可以按“提供方—共享对象—消费方”三段来理解。提供方一侧的核心动作是：准备可共享对象（表、安全视图、安全 UDF）、创建共享、把对象授权给共享、把消费方账户加入共享。消费方一侧的核心动作是：接受共享、CREATE DATABASE ... FROM SHARE、把共享数据库的权限授予本账户角色、在自己的虚拟仓库上查询。中间层则是共享的两种形态：直接共享（Direct Share）面向已知的、同区域（或跨区域复制后）的 Snowflake 账户；Listing / Data Exchange 面向一对多、需要发现与订阅的场景。

下面这张图把“提供方—共享—消费方”的对象关系、权限流向与数据可见性放在同一张结构图里，便于在后续章节中反复对照。

有了这张结构图，实战路线图就可以按“先跑通、再治理、后规模化”三段推进。第一阶段跑通最小闭环：在提供方用 CREATE SHARE 建共享，用 GRANT USAGE ON DATABASE 与 GRANT SELECT ON TABLE 授权，用 ALTER SHARE ... ADD ACCOUNT 加入消费方；消费方执行 CREATE DATABASE 挂载共享，再用 GRANT IMPORTED PRIVILEGES 把访问权交给业务角色，最后用一条 SELECT 验证。第二阶段做治理：把直接共享表替换为安全视图，加入行级过滤与列脱敏，明确共享对象的命名与版本约定，并建立访问审计。第三阶段做规模化：当消费方从 1 个变成 10 个，评估是否改用 Listing 或 Data Exchange，评估跨区域复制带来的存储与传输成本，并设计共享的退出与回收流程。

为了让第一阶段可复现，下面给出一个最小可用的示例链路。假设提供方账户为 PROVIDER_ACCT，消费方账户为 CONSUMER_ACCT，共享一张订单表 SALES_DB.PUBLIC.ORDERS，只暴露 order_id、region、amount 三列，并只允许消费方看到 region = 'CN' 的行。示例中的账户名、表名与数据均为教学假设，不是实测结果。

-- 提供方：创建共享并授权
CREATE SHARE SH_ORDERS_CN;
GRANT USAGE ON DATABASE SALES_DB TO SHARE SH_ORDERS_CN;
GRANT USAGE ON SCHEMA SALES_DB.PUBLIC TO SHARE SH_ORDERS_CN;

-- 用安全视图做行过滤与列裁剪
CREATE OR REPLACE SECURE VIEW SALES_DB.PUBLIC.V_ORDERS_CN AS
SELECT order_id, region, amount
FROM SALES_DB.PUBLIC.ORDERS
WHERE region = 'CN';

GRANT SELECT ON VIEW SALES_DB.PUBLIC.V_ORDERS_CN TO SHARE SH_ORDERS_CN;
ALTER SHARE SH_ORDERS_CN ADD ACCOUNT = CONSUMER_ACCT;

-- 消费方：挂载共享并授权给业务角色
CREATE DATABASE SHARED_SALES FROM SHARE PROVIDER_ACCT.SH_ORDERS_CN;
GRANT IMPORTED PRIVILEGES ON DATABASE SHARED_SALES TO ROLE ANALYST_ROLE;

-- 验证：应只返回 region = 'CN' 的行
SELECT order_id, region, amount
FROM SHARED_SALES.PUBLIC.V_ORDERS_CN
ORDER BY order_id
LIMIT 10;

验证时有两个关键判断点。其一，消费方查询返回的列必须只有三列，若出现 customer_name 等未授权列，说明授权对象不是安全视图而是基表，需要检查 SHOW GRANTS TO SHARE SH_ORDERS_CN 的输出。其二，返回行必须全部满足 region = 'CN'，若出现其他区域，说明过滤条件没有生效，通常是视图定义被覆盖或授权指向了旧对象。这两个判断点会在后续“共享验证与排障”章节中展开。

学习本课程时建议始终带着三个问题阅读每一节：这个对象共享的是“数据”还是“访问权”？权限在提供方和消费方分别由谁授予？如果共享被撤销，消费方会立刻看到什么变化？把这三个问题答清楚，Snowflake 共享的绝大多数行为都能自行推导。

最后需要提前建立成本与治理意识。共享本身不产生存储费用，但消费方每次查询都会消耗自己的虚拟仓库；如果提供方对共享对象做了跨区域复制，则复制会带来额外的存储与数据传输成本。权限方面，共享一旦撤销，消费方对该数据库的访问立即失效，但消费方此前基于共享数据物化出来的本地表不会自动消失，这属于消费方自己的数据资产，需要在协作约定中明确。把这些边界想清楚，跨团队协作才不会在“谁付费、谁负责、谁能看”上反复扯皮。