📚 课程目录第2章 Snowflake架构回顾

2. Snowflake架构回顾

要理解Snowflake的灾备恢复能力，必须先回到它的基础架构。Snowflake并不是传统意义上“装在服务器上的数据库”，而是一个构建在公有云之上的多租户托管服务。它的核心设计可以概括为三层：云服务层（Cloud Services）、计算层（Compute / Virtual Warehouses）和存储层（Storage）。这三层彼此解耦，正是“存储与计算分离”和“多集群共享数据”得以成立的前提，也直接决定了故障发生时哪些部分会中断、哪些部分仍然可用、恢复时应该从哪里入手。

三层架构与存储计算分离

存储层是架构中最“稳”的部分。用户数据以Snowflake专有的微分区（Micro-Partition）列式格式存放在云对象存储中，例如AWS S3、Azure Blob Storage或Google Cloud Storage。微分区是自动切分、自动压缩、带元数据统计的不可变数据块，写入后不再原地修改，更新和删除通过新增分区与元数据标记实现。这种“不可变+元数据”的方式让存储层天然具备高持久性，云厂商对象存储通常提供跨可用区甚至跨区域的冗余，因此存储层很少成为灾备的瓶颈。

计算层由一组组虚拟仓库（Virtual Warehouse）构成。每个虚拟仓库是一批按需拉起、可独立伸缩的计算节点，负责执行SQL、加载数据、执行ETL。关键点在于：虚拟仓库不持有用户数据，它只缓存从存储层读取的分区，缓存丢失不会造成数据丢失，重新执行查询即可从存储层重建。因此计算层是“可丢弃、可重建”的。当某个虚拟仓库故障时，影响的是正在执行的查询，而不是数据本身。

云服务层是架构的“大脑”，负责身份认证、访问控制、元数据管理、查询解析与优化、事务管理、以及把计算层和存储层粘合起来。它本身也是多副本、跨可用区部署的高可用服务。理解这一点很重要：元数据（表结构、分区清单、事务日志、权限）是Snowflake的命脉，它由云服务层管理，而不是用户可见的普通文件。灾备方案中“能否快速恢复”往往取决于元数据与对象的可恢复性，而不仅是数据文件是否还在。

多集群共享数据：为什么它能支撑业务连续性

“多集群共享数据”指的是：多个虚拟仓库可以同时读取同一份存储层数据，彼此之间不需要复制数据、不需要数据分片、也不会互相阻塞。传统架构里，为了支撑更多并发用户，往往要复制多份数据或做读写分离，副本之间的一致性成为难题。Snowflake把数据统一放在存储层，计算层按需扩展，多个仓库共享同一份微分区，因此增加计算能力不会增加数据副本。

这对灾备的意义在于：当主区域的计算资源紧张或某个仓库故障时，可以快速在其他仓库或其他区域拉起新的计算集群，只要存储层和元数据可达，业务就能继续。反过来，如果存储层或元数据受损，再多计算集群也无济于事。因此灾备设计的重心应放在数据与元数据的跨区域复制，而不是计算节点的备份。

云区域与可用区部署

Snowflake部署在特定云区域（Region）中，例如 AWS us-east-1、Azure East US 2。每个区域内，云服务层和存储层由云厂商在多个可用区（AZ）之间做冗余，单个AZ故障通常不会导致服务中断。但区域级故障——例如整个us-east-1不可用——会影响该区域内所有Snowflake账户，这时就需要跨区域灾备。

跨区域灾备主要依赖数据库复制（Database Replication）和故障转移组（Failover Group）。复制把主区域账户中的数据库、共享、角色等对象异步复制到目标区域；故障转移组则把一组对象打包，支持一键切换。复制是异步的，因此存在复制延迟（Replication Lag），这决定了RPO。下面给出一个可参考的配置示例，用于建立主备区域之间的复制关系：

-- 在主区域账户中创建故障转移组
CREATE FAILOVER GROUP sales_fg
  OBJECT_TYPES = DATABASES, ROLES, USERS, WAREHOUSES
  ALLOWED_DATABASES = sales_db, sales_stage
  ALLOWED_ACCOUNTS = org1.account_b
  REPLICATION_SCHEDULE = '10 MINUTE';

-- 在目标区域账户中创建副本组
CREATE REPLICA GROUP sales_fg
  AS REPLICA OF org1.account_a.sales_fg;

-- 查看复制状态与延迟
SELECT * FROM TABLE(INFORMATION_SCHEMA.REPLICATION_GROUP_STATUS('sales_fg'));

示例中 REPLICATION_SCHEDULE = '10 MINUTE' 表示每10分钟尝试一次复制，实际RPO取决于数据变更量和网络状况，可能小于也可能大于10分钟。查询 REPLICATION_GROUP_STATUS 可以观察最近一次复制的完成时间与延迟，这是判断灾备是否“跟得上”的关键依据。若延迟持续增大，应检查主区域写入压力、网络带宽或复制对象数量。

从架构看灾备的三个判断点

第一，数据是否已复制到目标区域。存储层本身跨AZ冗余，但不跨区域，必须显式配置复制。第二，元数据与权限是否同步。只复制数据表而遗漏角色、共享、仓库定义，切换后用户可能无法访问。第三，计算资源是否可在目标区域快速就绪。目标区域的虚拟仓库可以预先创建或按需拉起，但需要确认配额与网络策略允许。

判断灾备是否可用，不要只看“复制任务是否成功”，还要看复制延迟、对象完整性以及目标区域能否实际执行一次查询。建议定期在目标区域做只读验证，确认数据可查、权限正确。

总结来说，Snowflake的三层解耦架构让计算层可以灵活重建，存储层提供高持久性，云服务层掌握元数据命脉。灾备的核心不是备份计算节点，而是保证存储数据与元数据能够跨区域复制并在需要时快速切换。理解区域与可用区的边界，才能正确设计RPO、RTO和故障转移策略。