2. Snowflake平台架构与验收对象

Snowflake 的验收之所以容易“看起来都通了、实际却交付不清”，根本原因在于它的架构不是一台服务器、一个数据库实例，而是一组跨云区域、跨账户、跨角色的逻辑对象与云资源的组合。要判断一个 Snowflake 平台是否达到交付标准，必须先明确：哪些对象属于平台方建设范围，哪些属于使用方自建范围；哪些是账户级配置，哪些是组织级治理；哪些是存储与计算分离后的独立验收点。本节围绕这些对象建立一张“验收对象地图”，后续章节的检查项、测试用例和交付物都挂在这张地图上。

一、从组织到账户：治理边界与资源边界

Snowflake 的最高层是 Organization（组织），它把多个 Account 关联在一起，用于跨账户的统一治理，例如组织级用户、组织级策略、跨账户复制与账户间数据共享。组织本身不承载业务数据，它承载的是“账户之间的关系”。因此验收组织层时，重点不是查表，而是查：组织下挂了哪些账户、账户属于哪个云区域、是否启用了组织级策略、跨账户复制是否按预期配置。

Account（账户）是真正承载资源、计费、安全和隔离的边界。一个账户内包含数据库、模式、虚拟仓库、用户、角色、网络策略、资源监视器等。验收账户层时，最典型的问题是：账户部署在哪个云与区域（例如 AWS ap-southeast-1 或 Azure East US 2）、账户标识符（Account Locator / Organization Name）是否登记正确、账户级参数（如时区、会话超时、语句超时）是否按交付基线设置。账户是“交付边界”的第一道分界线：账户之外的对象，通常不属于本账户的验收范围，除非通过共享或复制显式引入。

二、数据库与模式：数据对象的命名与归属

账户之下是 Database（数据库），数据库之下是 Schema（模式），模式之下才是表、视图、函数、存储过程、序列等对象。Snowflake 采用三层命名空间 DATABASE.SCHEMA.OBJECT，这一点在验收中非常关键：任何对象都必须能回答“它在哪个库、哪个模式、由谁创建、被谁引用”。

验收数据库与模式时，建议按“用途分层”检查，而不是按数量检查。常见分层包括：

• 原始层（RAW / LANDING）：存放从源系统接入的原始数据，通常保留最细粒度，允许重复与脏数据。
• 整合层（CURATED / INTEGRATION）：完成清洗、去重、标准化、维度建模。
• 应用层（MART / PRESENTATION）：面向报表、BI、数据产品，通常按主题域划分模式。
• 治理与运维层（GOVERNANCE / UTIL）：存放审计、监控、元数据、资源使用记录。

验收时要确认：每个模式是否有明确 Owner 角色、是否设置了默认的 Time Travel 保留期、是否启用了数据保留与克隆策略、是否对 PUBLIC 角色开放了不该开放的权限。数据库与模式是权限授予的主要落点，也是“交付边界”在数据侧的具体体现。

三、虚拟仓库与存储计算分离：验收的核心机制

Snowflake 最本质的架构特征是存储与计算分离。数据持久化在云对象存储（如 S3、Azure Blob、GCS）中，由 Snowflake 管理为微分区（Micro-partition）；计算由 Virtual Warehouse（虚拟仓库）提供，虚拟仓库是一组可弹性伸缩的计算节点，按秒计费，可独立于存储启停、扩缩。

这意味着验收必须把“存储”和“计算”分开看：

• 存储侧：数据是否已正确加载、微分区是否合理、表是否启用聚簇、Time Travel 与 Fail-safe 是否符合保留要求、存储用量是否可被监控。
• 计算侧：虚拟仓库的规模（T-shirt Size，如 XS、S、M、L）、自动挂起与自动恢复参数、多集群（Multi-cluster）配置、查询加速策略、资源监视器与预算告警是否生效。

虚拟仓库不是数据库，它不存数据，只提供计算。因此验收虚拟仓库时，不能只看“能不能跑 SQL”，而要看：仓库在空闲时是否按预期挂起、并发查询时是否按策略扩展、仓库与工作负载是否匹配（例如 ETL 用大仓库、BI 用小仓库）、是否设置了合理的 STATEMENT_TIMEOUT_IN_SECONDS 与 STATEMENT_QUEUED_TIMEOUT_IN_SECONDS。这些参数直接决定交付后的成本与稳定性。

四、云服务层：看不见但必须验收的一层

在存储与计算之外，Snowflake 还有一层云服务层（Cloud Services Layer），负责身份认证、访问控制、元数据管理、查询解析与优化、事务管理、安全策略执行等。云服务层不直接产生数据存储费用，但它是所有操作的控制平面。验收云服务层时，重点检查：

• 身份认证方式：是否启用 SSO / SAML / OAuth，是否强制 MFA。
• 访问控制：RBAC 角色层级是否清晰，是否存在越权路径。
• 网络与安全：网络策略、PrivateLink、IP 白名单是否按交付要求配置。
• 审计与监控：ACCOUNT_USAGE 与 INFORMATION_SCHEMA 是否可查，登录历史、查询历史是否保留。

云服务层是“交付边界”中最容易被忽略的一层，因为它没有实体资源，但一旦认证或权限配置错误，整个平台的可信度都会受影响。

五、交付边界：哪些属于平台交付，哪些属于使用方自建

把上述对象串起来，就形成了一条清晰的交付边界：组织与账户由平台方建设并登记；数据库、模式、虚拟仓库、角色、网络策略、资源监视器由平台方按基线创建；使用方在既定边界内创建自己的表、视图、任务与查询。验收时要能明确回答：账户是谁的、区域在哪里、哪些库和仓库已交付、哪些权限已授予、哪些监控已开启、哪些对象不在本次交付范围内。

六、验收对象清单与判断依据

把上述对象整理成可执行的验收清单，可以避免“凭感觉验收”。下表给出的是对象、检查点与判断依据的对应关系，实际交付时可按项目规模裁剪。

总结来看，Snowflake 的验收对象不是单一数据库，而是组织、账户、数据库、模式、虚拟仓库、存储、计算分离与云服务层共同构成的层次结构。只有把每一层的边界、归属和判断依据说清楚，后续的权限测试、性能测试、成本核对和安全审计才有稳定的落点。