1. 课程导入与场景锚定

在多数已经上云的企业里，数据并不是"没有"，而是"拿不到"。销售团队需要客户行为数据做分层运营，风控团队需要交易流水做实时拦截，算法团队需要特征宽表做模型训练，而数据往往分散在不同订阅、不同租户、不同部门甚至不同合作公司手中。传统做法是导出 CSV、开 SFTP、建临时库、发邮件，结果是数据副本满天飞、权限收不回来、口径对不上、审计说不清。Azure 数据共享（Azure Data Share）要解决的正是这一类"跨边界的数据交付"问题：让数据提供方在不复制、不迁移、不交出存储账户密钥的前提下，把数据集以只读方式共享给消费方，并保留可撤销、可审计的控制权。

核心价值：从"搬数据"到"给访问"

理解 Azure 数据共享，关键是理解它把"数据交付"从文件搬运变成了访问授权。提供方在自己的存储账户（如 ADLS Gen2、Blob Storage）或数据仓库（如 Azure Synapse Analytics、Azure SQL Database）中定义共享内容，消费方在自己的订阅里"映射"到一份只读快照或就地访问入口。数据物理上仍在提供方一侧，消费方拿到的是受控的读取路径。这一模型带来三个直接收益：其一，减少副本，降低存储与合规成本；其二，权限集中，提供方随时可撤销共享；其三，口径统一，消费方读取的是同一份源数据而非各自导出的版本。

需要区分两种共享模式。基于快照的共享（Snapshot）会在消费方侧生成一份只读副本，适合批量分析、离线训练等对时效要求不高的场景；就地共享（In-place）则让消费方直接读取提供方存储中的最新数据，适合需要近实时视图的场景。选择哪种模式，取决于数据时效要求、消费方是否允许持有副本、以及双方的合规约束。

典型业务场景

第一个场景是集团与子公司之间的数据分发。集团在中心订阅维护客户主数据与交易汇总，各子公司需要按区域读取。若用导出方式，每个子公司一份副本，口径漂移几乎不可避免；用数据共享，集团定义一次共享，各子公司映射到自己的分析环境，源数据更新后按快照计划同步，口径始终一致。

第二个场景是跨部门协作。数据平台团队作为提供方，把清洗后的宽表共享给营销、风控、财务三个消费方。营销只读用户行为字段，风控只读交易与设备字段，财务只读结算字段。通过为不同团队建立不同共享，实现字段级的最小权限交付，而不是把整张宽表发给所有人。

第三个场景是与外部合作伙伴的数据交换。例如保险公司与再保公司、零售企业与供应链服务商之间，需要定期交换脱敏后的业务数据。数据共享让提供方保留数据主权，合作结束后撤销共享即可，不必追着对方删除副本。

第四个场景是数据科学与模型训练。算法团队需要历史特征做训练，但生产库不允许直连。提供方按快照方式共享一份只读训练集，训练完成后消费方侧副本可自行清理，生产库不受影响。

学习路径与实战项目说明

本课程围绕"能建、能接、能管、能排障"四条主线展开。前段建立概念与权限模型，中段进入提供方与消费方的实际操作，后段覆盖监控、成本、安全与故障排查。学习过程中会反复使用一个贯穿式实战项目：某零售企业"星云零售"的数据平台团队，需要把订单、客户、商品三类数据共享给营销分析、风控、外部物流合作方三个消费方，并满足不同的时效与合规要求。

实战项目的关键参数设定如下（均为教学示例，非实测结果）：源存储为 ADLS Gen2 账户 stnebulaadls，容器 curated；订单数据每日增量约 200 万行，客户主数据约 80 万行，商品维表约 3 万行；营销分析要求每日 06:00 前可见前一日数据，风控要求近实时，外部物流合作方仅需每周一次脱敏汇总。基于这些要求，营销走每日快照计划，风控走就地共享，外部合作方走每周快照并附加脱敏视图。

本课程要建立的能力

完成本课程后，你应当能够独立完成一次端到端的数据共享交付：在提供方创建共享、添加数据集、设置快照计划、发出邀请；在消费方接受邀请、映射目标、验证数据可读；在运行期通过监控查看快照状态与失败原因；在合规要求变化时撤销共享或调整数据集范围。同时，你应当能判断什么场景不该用数据共享——例如需要消费方写入回传、需要双向同步、或数据量极小且一次性交付时，直接导出或其它集成方式可能更合适。

下一阶段的学习会从权限模型与共享对象结构开始，逐步进入具体操作。请先记住本课程的核心判断：数据共享交付的是"受控的读取关系"，而不是"一份数据文件"。所有后续的模式选择、权限设计和排障思路，都建立在这一判断之上。