📚 课程目录第2章 Snowflake架构与数据管道基础

2. Snowflake架构与数据管道基础

Snowflake 之所以能同时支撑“高并发查询”和“弹性数据加载”，关键在于它把传统数据仓库拆成了三层：存储层、计算层（虚拟仓库）、云服务层。这三层各自独立伸缩，又通过元数据和事务协调紧密配合。理解这三层如何协作，以及数据库、模式、表、阶段、文件格式这些对象在管道中的位置，是后续自动化加载设计的基础。

三层架构：各司其职又彼此解耦

存储层负责持久化数据。当数据写入表时，Snowflake 并不会直接修改原始文件，而是把数据组织成微分区（micro-partition）——一种列式、压缩、带元数据（如每列的最小值/最大值、NULL 数量）的不可变存储单元。微分区一旦写入就不再修改，更新和删除通过新增分区加元数据标记实现。这种设计让存储层天然适合批量加载，也让后续的裁剪（pruning）成为可能。

计算层由虚拟仓库构成。虚拟仓库不是一台固定服务器，而是一组可动态启停的计算资源。每个仓库独立于其他仓库运行，因此加载任务、报表查询、ETL 转换可以各用各的仓库，互不争抢。仓库有 T-shirt 尺寸（X-Small 到 6X-Large），尺寸决定单集群内的计算节点数量；多集群仓库则通过增加集群数应对并发。仓库的自动挂起（AUTO_SUSPEND）和自动恢复（AUTO_RESUME）是成本控制的核心：空闲即停，有查询即起。

云服务层是“大脑”。它管理元数据、优化器、事务、访问控制、安全认证，并协调存储与计算之间的交互。当你执行一条 COPY 命令时，云服务层解析语句、检查权限、生成执行计划，再调度虚拟仓库去读取阶段中的文件、写入微分区。云服务层本身不存储用户数据，也不参与实际计算，但它决定了“谁能做什么、怎么做”。

数据管道中的关键对象

Snowflake 的数据管道不是靠“一个工具”完成的，而是由一组对象串联起来。理解每个对象的职责，才能设计出可维护的加载链路。

数据库（Database）是最高层容器，通常按数据生命周期划分。例如 RAW_DB 存放原始加载数据，CURATED_DB 存放清洗后的数据，ANALYTICS_DB 存放面向报表的汇总表。这种分层让权限、保留策略和成本归属更清晰。

模式（Schema）是数据库内的逻辑分组。常见做法是按来源或主题划分，如 RAW_DB.SALES、RAW_DB.INVENTORY。模式也是权限授予的基本单位，可以给不同团队授予不同模式的读写权限。

表（Table）是数据的最终落点。Snowflake 支持标准表、临时表、瞬态表、外部表等。管道中最常用的是标准表，配合 COPY INTO 批量写入。表还可以定义聚簇键（cluster key），让微分区按指定列排序，提升大表查询的裁剪效率。

阶段（Stage）是文件的中转站。内部阶段（Internal Stage）由 Snowflake 管理存储，外部阶段（External Stage）指向 S3、Azure Blob 或 GCS 等对象存储。阶段对象保存了路径、存储集成、文件格式等配置，让 COPY INTO 命令可以简洁地引用。例如：

CREATE OR REPLACE STAGE RAW_DB.SALES.S3_STAGE
  URL = 's3://my-bucket/sales/'
  STORAGE_INTEGRATION = my_s3_int
  FILE_FORMAT = (TYPE = 'CSV' FIELD_OPTIONALLY_ENCLOSED_BY = '"' SKIP_HEADER = 1);

文件格式（File Format）定义如何解析文件。CSV、JSON、Parquet、Avro 等各有参数。例如 CSV 需要指定分隔符、引号规则、是否跳过表头；JSON 需要指定 STRIP_OUTER_ARRAY 等。文件格式可以独立创建并复用，也可以内联在 COPY 命令中。

一次典型加载的完整链路

假设销售数据每天以 CSV 文件落到 S3 的 s3://my-bucket/sales/2025-01-15/ 下。管道执行过程如下：

云服务层解析 COPY INTO 语句，检查 LOAD_WH 仓库权限和阶段访问权限。
LOAD_WH 虚拟仓库被自动唤醒，从 S3 阶段读取文件列表。
按文件格式定义解析 CSV，将数据写入 RAW_DB.SALES.ORDERS 表，生成新的微分区。
云服务层更新元数据，记录新分区和文件加载状态（避免重复加载）。
转换任务使用 TRANSFORM_WH 读取 RAW 表，清洗后写入 CURATED_DB.SALES.ORDERS_CLEAN。
BI 查询使用 BI_WH 读取 CURATED 或 ANALYTICS 表，返回结果。

整个过程中，三个仓库互不干扰：加载时 BI 查询不受影响，转换时加载可以继续。这正是计算层独立伸缩的价值。

参数与成本的关键控制点

虚拟仓库的 AUTO_SUSPEND 建议设为 60 秒（默认 600 秒），避免空闲浪费；AUTO_RESUME 必须为 TRUE，否则每次都要手动启动。STATEMENT_TIMEOUT_IN_SECONDS 可以防止异常查询长时间占用资源。对于加载任务，X-Small 通常足够；转换任务根据数据量选择 Medium 或 Large；BI 查询仓库则根据并发用户数考虑多集群。

阶段对象中的 FILE_FORMAT 可以省略，改为在 COPY INTO 中指定，但独立创建文件格式更利于复用和统一管理。加载后可用 SELECT * FROM TABLE(VALIDATE(RAW_DB.SALES.ORDERS, JOB_ID => '_last')) 检查本次加载的错误行。

理解这三层架构和对象关系后，后续的自动化加载设计就有了清晰的落点：阶段负责“从哪读”，文件格式负责“怎么解析”，表负责“写到哪”，虚拟仓库负责“用多少算力”，云服务层负责“协调与安全”。每一层都可以独立调整，而不影响其他层。