📚 课程目录第2章 Snowflake环境架构与账户策略

2. Snowflake环境架构与账户策略

在 Snowflake 上做持续交付，第一件必须想清楚的事不是“怎么写流水线”，而是“代码最终落到哪个账户、哪个库、哪个模式、用哪个仓库跑”。Snowflake 的层级对象模型天然支持多环境隔离，但如果一开始把开发、测试、预发、生产全部塞进同一个账户，后续的权限、成本、发布回滚都会变成灾难。本节围绕 Organization、Account、Database、Schema、Warehouse 五层对象，讲清楚规划原则与隔离模式。

一、五层对象模型与职责边界

Snowflake 的对象层级从高到低是：Organization（组织）→ Account（账户）→ Database（数据库）→ Schema（模式）→ 表/视图等具体对象。Warehouse（虚拟仓库）是独立的计算资源，不隶属于数据库，而是被账户内的角色按需调用。理解这一点非常关键：数据隔离靠 Database/Schema，计算隔离靠 Warehouse，权限隔离靠 Role，而账户是计费、安全与网络策略的边界。

Organization 是 Snowflake 引入的顶层容器，用于跨账户统一管理、跨账户数据共享（Data Sharing / Listing）以及组织级策略。一个组织下可以挂多个账户，例如 ACME_PROD、ACME_UAT、ACME_DEV。账户之间默认完全隔离，数据不互通，除非显式配置共享或复制。

二、账户策略：单账户多环境 vs 多账户隔离

这是规划阶段最重要的决策。两种主流模式各有适用场景：

模式 A：单账户多环境。在一个账户内用 Database 前缀区分环境，例如 DEV_RAW、UAT_RAW、PROD_RAW，配合不同 Warehouse 和 Role。优点是管理简单、共享方便、成本低；缺点是权限边界弱，一个误操作可能影响生产，且无法利用账户级网络策略做硬隔离。适合小团队、早期项目。

模式 B：多账户隔离。DEV、UAT、PROD 各自独立账户，通过 Organization 统一管理。优点是安全边界清晰、计费独立、网络策略可分别配置、生产账户可开启更严格的 MFA 和 IP 白名单；缺点是跨账户发布需要额外的部署工具（如 Terraform、Schemachange、Snowflake CLI），数据共享需显式配置。适合中大型团队、有合规要求的场景。

实践中常见的折中方案是：DEV 与 UAT 合并为一个非生产账户，PROD 独立账户。这样既控制了账户数量，又保证了生产环境的硬隔离。

三、数据库与模式的命名与分层

无论选哪种账户模式，Database 和 Schema 的规划都应遵循“按数据加工层次分层”的原则。推荐三层：

RAW（或 LANDING）：贴源层，存放从业务系统抽取的原始数据，只做加载不做转换，保留全量历史。
STG（或 CURATED）：清洗层，做去重、类型转换、标准化，是数据质量校验的主要场所。
MART（或 ANALYTICS）：应用层，面向报表、BI、特征工程，按主题域组织。

命名建议带上环境标识，例如 DEV_RAW、PROD_MART，避免跨环境误引用。Schema 内部再按源系统或主题域细分，如 RAW.SALESFORCE、RAW.SAP。这样在 CI/CD 中可以用统一的模板变量替换环境前缀，实现“一套代码、多环境部署”。

四、Warehouse 规划：计算隔离与成本控制

Warehouse 是 Snowflake 计费的核心，规划时要考虑三点：尺寸、并发、自动挂起。开发环境用 X-Small 并设置 60 秒自动挂起即可；测试环境用 Small；生产环境根据负载选择 Medium 或 Large，并开启多集群（Multi-Cluster）应对并发高峰。

关键实践是按用途拆分 Warehouse：ETL 用 WH_ETL，BI 查询用 WH_BI，数据科学用 WH_DS。这样既能避免资源争抢，又能通过 Resource Monitor 分别设置配额。例如给 WH_ETL 设置每月 500 credits 上限，达到 80% 时告警，100% 时挂起，防止意外跑飞。

-- 示例：创建带资源监视器的生产 ETL 仓库
CREATE WAREHOUSE WH_PROD_ETL
  WAREHOUSE_SIZE = 'MEDIUM'
  AUTO_SUSPEND = 120
  AUTO_RESUME = TRUE
  MAX_CLUSTER_COUNT = 3
  MIN_CLUSTER_COUNT = 1
  SCALING_POLICY = 'STANDARD'
  INITIALLY_SUSPENDED = TRUE;

CREATE RESOURCE MONITOR RM_PROD_ETL
  WITH CREDIT_QUOTA = 500
  TRIGGERS ON 80 PERCENT DO NOTIFY
           ON 100 PERCENT DO SUSPEND;

五、权限模型与发布账户的最小权限

CI/CD 流水线使用的服务账户不应拥有 ACCOUNTADMIN。推荐做法是创建专用角色 ROLE_DEPLOY，只授予目标 Database 的 CREATE SCHEMA、CREATE TABLE、CREATE VIEW 等权限，以及目标 Warehouse 的 USAGE 权限。生产环境的发布角色还应限制只能操作 PROD_* 前缀的对象。

规划检查清单：① 环境是否按账户或数据库前缀隔离？② 每个环境是否有独立 Warehouse 和 Resource Monitor？③ 发布角色是否遵循最小权限？④ 命名是否统一带环境标识？⑤ 生产账户是否开启 MFA 与网络策略？这五点确认后，再开始搭建 CI/CD 流水线。

总结来说，Snowflake 的环境架构规划本质上是把“隔离”这件事分配到正确的层级：账户管安全与计费，数据库和模式管数据分层，仓库管计算与成本，角色管权限。规划阶段多花一天，后续发布和排障就能少花一周。