2. Azure数据共享基础架构
Azure数据共享（Azure Data Share）解决的是一个非常具体的协作问题：当数据的所有权、存储位置和治理责任分散在不同团队、不同订阅甚至不同租户时，如何让数据使用方获得数据，而不必把数据复制到对方控制的存储中，也不必交出底层存储账户的访问密钥。理解它的基础架构，关键在于分清四个概念：共享（Share）、提供方（Provider）、消费方（Consumer），以及数据到达消费方的两种机制——快照（Snapshot）与就地共享（In-place Sharing）。
共享、提供方与消费方：三个角色定位
一个共享是提供方创建的逻辑容器，它描述“我提供哪些数据集、以什么方式提供、消费方需要接受什么条款”。共享本身不移动数据，它是一份可被邀请、可被接受、可被撤销的协作契约。共享内部包含若干数据集（Dataset），每个数据集指向提供方存储中的一个具体对象，例如 Azure Data Lake Storage Gen2 中的某个文件夹、Blob 存储中的某个容器，或 Azure SQL 数据库中的某张表。
提供方是数据的拥有者，负责创建共享、添加数据集、指定共享模式（快照或就地）、发出邀请，并在共享存续期间管理访问。提供方始终保留对源存储的控制权，这是整个模型的核心安全前提。消费方是接受邀请的一方，它需要在自己的订阅中创建一个数据共享账户作为接收端，然后接受邀请、把共享中的数据集映射到自己的目标存储，并按提供方设定的模式获取数据。消费方拿到的是数据副本或受控的读取路径，而不是源存储的管理权限。
这里有一个容易被忽略的边界：提供方和消费方各自拥有独立的 Azure 数据共享资源，二者通过“邀请—接受”建立关联。邀请可以发给同一租户内的订阅，也可以发给外部租户的邮箱或对象 ID。跨租户共享时，双方不需要建立目录信任关系，认证由 Microsoft Entra ID 与共享邀请机制共同完成。
共享订阅：消费方侧的接收容器
消费方接受邀请后，会在自己的数据共享账户下生成一个共享订阅（Share Subscription）。共享订阅是消费方视角的“已接受共享”，它记录了来源共享、可用数据集、当前同步状态以及目标数据集映射。一个共享可以被多个消费方分别接受，每个消费方各自持有一个独立的共享订阅，互不影响；提供方撤销某个消费方的访问，也不会波及其他消费方。
共享订阅中最重要的配置是数据集映射：消费方为每个收到的数据集指定落地位置。例如提供方共享了一个 ADLS Gen2 文件夹，消费方可以把它映射到自己的存储账户下的某个容器路径。映射决定了数据最终写到哪里，也决定了消费方需要具备哪些写入权限。
快照机制：按需或按计划复制数据
快照是默认也是最通用的共享方式。它的工作逻辑是：消费方触发一次快照（手动触发，或由提供方配置的快照计划定时触发），Azure 数据共享读取提供方源存储中的当前数据，并将其复制到消费方映射的目标存储中。复制完成后，消费方在自己的存储中拥有一份完整的数据副本，可以自由读取、加工，不再依赖提供方的在线可用性。
快照有三种粒度，理解它们的差异对实际使用很重要：
- 完整快照：复制数据集中的全部数据。首次同步必须使用完整快照，因为它建立了消费方的基线副本。
- 增量快照：只复制自上次成功快照以来发生变化的数据。它依赖源端文件的时间戳或数据库的变更跟踪能力，因此要求源数据具备可识别的变更标记。增量快照能显著降低传输量和成本，适合周期性同步场景。
- 按需快照：由消费方在需要时手动触发，不依赖计划。适合数据更新节奏不固定、或消费方希望自主控制同步时机的场景。
快照的代价是数据被复制，因此会占用消费方存储空间，也会产生源端读取和跨区域传输费用。它的优势是消费方获得完全独立的数据副本，读取性能不受提供方影响，且提供方可以随时停止后续快照而不影响已复制的数据。
就地共享：不复制数据的受控读取
就地共享（In-place Sharing）是另一种机制，目前主要面向 Azure Data Explorer 和部分存储场景。它不复制数据，而是让消费方直接读取提供方存储中的数据。提供方在共享中授予消费方对特定数据集的读取权限，消费方通过自己的计算资源（例如自己的 Azure Data Explorer 集群或查询引擎）访问源数据。
就地共享的关键差异在于：数据始终留在提供方一侧，消费方看到的是实时或近实时的源数据，不存在副本滞后问题，也不产生复制存储成本。但消费方的读取会直接消耗提供方存储的吞吐和请求配额，因此提供方需要评估访问模式对源系统的影响。此外，就地共享要求消费方的计算环境能够访问提供方的存储端点，网络连通性和防火墙规则必须提前打通。
选择依据：如果消费方需要独立副本、离线分析或长期留存，选快照；如果消费方需要实时视图、数据量大到复制不经济，且双方网络可达，选就地共享。两者不是互斥的，同一个共享账户下可以针对不同数据集采用不同模式。
两种机制的数据流向对比
下面的图示把提供方、共享、消费方以及快照与就地共享两条路径放在同一张关系图中，帮助建立整体架构认知。
实际配置中的关键参数与判断
在真实部署中，有几个参数直接决定共享能否按预期工作。以快照共享为例，提供方在创建共享时需要指定快照计划，包括开始时间、重复间隔（例如每 24 小时）和快照类型（完整或增量）。如果选择增量快照，源数据集必须支持变更跟踪：ADLS Gen2 和 Blob 依赖文件时间戳，Azure SQL 依赖变更跟踪或时间戳列。若源数据不具备这些标记，增量快照会退化为完整快照或直接失败。
消费方侧需要关注目标存储的权限。消费方的数据共享账户需要被授予对目标存储的写入权限，通常通过托管标识（Managed Identity）实现。配置时，先为数据共享账户启用系统分配的托管标识，再把该标识添加到目标存储的“存储 Blob 数据贡献者”角色。如果这一步遗漏，快照触发后会报授权失败，数据不会落地。
对于就地共享，提供方需要确认消费方的网络路径。如果源存储启用了防火墙或专用终结点，消费方的计算资源必须能够通过允许的网络路径访问。此外，就地共享的权限授予是只读的，消费方无法通过该路径修改源数据，这一点在跨团队协作中尤其重要——它保证了数据所有权与使用权的分离。
排查思路：快照失败时，先看消费方目标存储的角色分配是否包含数据共享账户的托管标识；再看源数据集是否满足增量条件；最后检查提供方共享是否仍处于“已发送/已接受”的有效状态。就地共享读取失败时，优先检查网络连通性与源存储防火墙规则，而不是数据共享账户本身。
把以上内容串起来，Azure 数据共享的基础架构可以概括为：提供方用共享定义“给什么、怎么给”，消费方用共享订阅定义“收到哪里、怎么用”，快照负责把数据复制过去，就地共享负责把读取路径开放过去。理解这四者的分工，后续配置共享、设计同步策略和排查故障时就有了稳定的判断框架。