4. 微分区与聚簇深度解析

Snowflake 的查询性能在很大程度上取决于“扫描了多少数据”。微分区（Micro-partition）是 Snowflake 表存储的物理单元，聚簇（Clustering）则是控制数据如何落入这些物理单元的手段。理解微分区结构、聚簇键选择原则、自动聚簇与手动聚簇的适用场景，以及如何用聚簇信息函数评估效果，是数据建模与性能优化的核心能力。

一、微分区结构：不可见的物理切分

当数据写入 Snowflake 表时，系统会按照写入顺序自动将其切分为连续的微分区。每个微分区是 50MB～500MB 未压缩数据的不可变存储单元，采用列式存储，并带有元数据：每列的最小值、最大值、不同值数量、NULL 数量等。这些元数据构成了“分区裁剪（Partition Pruning）”的基础——优化器据此判断哪些微分区不可能包含目标数据，从而跳过扫描。

关键点在于：微分区边界由写入顺序决定，而不是由业务主键决定。如果数据按时间顺序持续追加，那么时间列天然具有良好的聚簇性；但如果数据来自多个源、乱序写入，同一业务键的值就会散布在大量微分区中，导致查询时必须扫描大量分区。此外，微分区一旦写入便不可修改，DML 操作会生成新的微分区，旧分区进入 Time Travel 保留期后失效。

二、聚簇键选择原则

聚簇键不是索引，它不指向单行，而是通过重排数据物理顺序，让相同或相近的键值聚集到相邻微分区中。选择聚簇键时，应遵循以下原则：

• 高基数优先：基数越高，每个微分区覆盖的键值范围越窄，裁剪越精确。日期、时间戳、订单号通常优于性别、状态等低基数列。
• 过滤频率高：选择 WHERE 子句中最常出现、且过滤效果显著的列。如果某列很少用于过滤，聚簇它几乎没有收益。
• 列数不宜多：多列聚簇键会形成组合排序，但每增加一列，聚簇收益会被摊薄，维护成本上升。通常 1～3 列足够。
• 表达式聚簇：可以使用确定性表达式，如 TO_DATE(created_at) 或 SUBSTR(order_id,1,4)。但查询谓词必须与表达式写法一致，否则无法命中裁剪。

三、自动聚簇与手动聚簇的适用场景

Snowflake 提供两种聚簇方式：

自动聚簇（Automatic Clustering）：在表上定义 CLUSTER BY 后，Snowflake 后台服务会持续监控微分区重叠情况，并自动执行重组。适合数据量大、持续写入、查询模式稳定的表，如事实表、事件日志表。自动聚簇按实际计算资源计费，需评估成本收益。

手动聚簇（Manual Clustering）：通过定期执行 ALTER TABLE ... RECLUSTER 或重建表来实现。适合写入频率低、批量加载后查询密集的场景，如每日批量导入后供分析使用。手动方式可控性强，但需要自行调度和维护。

-- 自动聚簇示例
ALTER TABLE sales_fact CLUSTER BY (TO_DATE(sale_time), region_id);

-- 查看聚簇信息
SELECT SYSTEM$CLUSTERING_INFORMATION('sales_fact', '(TO_DATE(sale_time), region_id)');

-- 手动触发重聚簇（需有权限）
ALTER TABLE sales_fact RECLUSTER;

四、聚簇信息函数与效果评估

Snowflake 提供多个函数用于评估聚簇效果：

评估时重点关注 average_depth：它表示每个微分区中，有多少个其他微分区与它在聚簇键上存在重叠。理想情况下，聚簇良好的表 average_depth 接近 1；如果远大于 1，说明数据散布严重，裁剪效率低。同时观察 partition_depth_histogram，若大量分区集中在高深度区间，说明需要重聚簇。

实际优化中，可以先用 EXPLAIN 查看查询计划中的分区扫描数量，再对比聚簇前后的变化。如果聚簇后扫描分区数显著下降、查询延迟降低，说明聚簇键选择有效；反之则需要重新审视聚簇键是否与查询谓词匹配。聚簇是手段，减少扫描量才是目的。