5.1 Secure Data Sharing：零拷贝共享

5.1 Secure Data Sharing：零拷贝共享

本节摘要：两个 Snowflake 账户之间共享一张表，底层文件一个字节都不复制：提供方创建 SHARE 对象、授权表与视图，消费方从 SHARE 直接建库查询，读到的就是提供方存储层里同一批微分区。本节讲清零拷贝的机制、三方角色与计费责任、共享的边界（跨区跨云需要复制打底），以及从"共享几张表"到"数据市场"的延伸。

一行 SQL 跨过组织边界

体系定位先摆清楚：第4章的克隆解决了"同一账户内的状态复制"，本节解决"跨账户的数据供给"。传统做法是导出文件、上传、导入、对账——每一步都可能出错，且从此出现第二份需要维护一致性的副本。Secure Data Sharing 把这条链压缩成两个动作：提供方授权，消费方建库。

-- ===== 提供方账户 =====
-- 创建 SHARE 对象：它不是数据，是一份"授权清单"
CREATE SHARE sales_share;

-- 把表或安全视图加入 SHARE（安全视图用于只暴露部分行列）
GRANT SELECT ON TABLE orders TO SHARE sales_share;
GRANT SELECT ON VIEW orders_public TO SHARE sales_share;

-- 把 SHARE 授给对方账户
ALTER SHARE sales_share ADD ACCOUNTS = partner_acct_001;

-- ===== 消费方账户 =====
-- 从 SHARE 建库：秒级完成，底层零复制
CREATE DATABASE partner_data FROM SHARE provider_acct.sales_share;

-- 之后像查自己的表一样查询
SELECT COUNT(*) FROM partner_data.public.orders_public;
​

从消费方视角，SHARE 建出的库是只读的：能查、能 JOIN 自己的表、能建视图二次加工，但不能写。从提供方视角，撤销授权（REVOKE）即刻生效，数据从未离开自己的存储层。

图：零拷贝共享的三方角色与数据流

三方角色与一本算清楚的账

零拷贝共享的商务模式比技术机制更值得咀嚼，因为它把"数据供给"从项目行为变成了运营行为：

• 提供方：付存储费（数据只此一份），控制共享范围。数据更新后，消费方立即可见——同一批微分区，没有同步延迟。
• 消费方：付自己的查询计算费。想查多快开多大仓库，自己决定，与提供方无关。
• 读取账户（Reader Account）：给没有 Snowflake 账户的伙伴开的"托管账户"，查询产生的计算费记在提供方头上，可用配额（monetary quota）封顶，防止对方把你的账单刷爆。

对比传统数据供给的隐性成本：每接一个消费方就要维护一条导出管道、一套对账逻辑、一份存储副本、一个安全审批流程——边际成本几乎不降。共享模式的边际成本趋近于零：多授权一个账户，只是授权清单多一行。

共享与克隆：同一思想的两次登场

回看第4章的零拷贝克隆与本节的零拷贝共享，机制同源：都是对底层微分区文件的元数据引用，都靠写时分离（写入产生新文件）保证两边独立演化。 差别只在作用域——克隆在账户内，共享跨账户并叠加了授权检查。理解其中一个，另一个自动成立。

这个思想还有第三次登场：第7章的"安全视图"——同一张表，不同角色看到不同行列，靠的也是引用而非复制。整本教程到这里已经能串出一句话：Snowflake 反复在做的同一件事，是让"多一份使用"不再产生"多一份数据"。

从共享到市场

把 SHARE 模式产品化，就是数据交换与市场（Marketplace/Listings）：提供方上架数据产品，消费方浏览、试用、订阅，平台处理授权与计费分账。对企业内部，同一机制可以搭"内部数据市场"——各业务线把口径统一的数据集以 Listing 形式发布，全公司订阅同一份口径，从机制上消灭"各部门报表数字对不上"的顽疾。

⚠️ 常见坑：共享"裸表"。把生产表直接放进 SHARE，消费方的查询压力虽然不落到你的仓库，但你的任何表结构变更（删列、改名）都可能当场弄断对方的作业。生产实践是只共享安全视图，在视图层做版本兼容与列裁剪，把变更控制在自己手里。

本节要点回顾

• 机制：SHARE 是授权清单不是副本；消费方读的就是提供方的微分区，更新即时可见。
• 计费三方：提供方付存储，消费方付计算，读取账户的消费由提供方买单但可设配额。
• 边界：同区同云零拷贝；跨区跨云先复制后共享；安全视图是共享的最佳载体。
• 思想内核：克隆、共享、安全视图都是"元数据引用 + 写时分离"的三次应用。

对外的管道打通了，下一节回到账户内部：数据进来之后，怎么让它自己流转起来。

共享治理清单

共享的技术门槛低，治理门槛不低。对外开通一份共享前，过一遍这份清单：

• 共享对象用安全视图而不是裸表，把列裁剪与口径版本握在自己手里（5.1 的坑位提醒）；
• 明确计费责任：普通共享消费方自付计算费；读取账户要设配额上限，防止账单外溢；
• 变更协议：视图口径调整、列增删的提前通知机制写进合作协议，消费方的作业以你的变更为日程；
• 定期盘点：列出所有在途共享与消费方，回收无人使用的授权——共享清单和权限清单一样会腐化；
• 合规确认：涉敏数据先过 7.3 的掩码与行级策略，确认策略对消费方会话同样生效。

与传统导出方案的对照表

一个跨企业共享的完整走查

把机制放进真实节奏：某制造商向物流伙伴开放在途库存数据。第一步，提供方在安全视图里裁剪出对方需要的列，并经过 7.3 的掩码策略处理批次号等内部标识；第二步，创建 SHARE、授权视图、添加对方账户，全程是几条 DDL；第三步，对方在自己的账户里从 SHARE 建库，与自己的运单表 JOIN 分析，用对方的仓库与配额；第四步，制造商每天凌晨刷新底表，对方上午查询时拿到的已经是新数据——没有任何同步作业存在于两家公司之间；第五步，合作结束，REVOKE 授权，对方侧的"库"即刻变空，不存在任何需要销毁的数据副本。

整个流程里值得回味的是第四步与第五步：更新零同步、终止零残留。传统点对点交付要维护的"数据离职流程"——收回文件、确认删除、出具证明——在共享模型里收缩成一条授权语句的状态变化。这也是把共享称作"协议"而非"功能"的原因：它改变的不是某次交付的效率，而是组织间数据关系的默认形态。