Snowflake SnowPro Advanced: Data Engineer Certification

**Streams 的变更追踪机制理解错** — Stream 不是"表的副本"也不是"队列"，它是一个**基于 offset 的元数据指针**，指向底层 Time Travel 里的一个时间点。当你 SELECT Stream 时看到的是"自上次消费后"的所有变更。**只有在一个 DML 事务中消费 Stream，offset 才会推进**（比如 INSERT INTO target SELECT * FROM stream 这种语句）。光 SELECT 查看不会推进 offset。另一个致命坑：Stream 的 offset 受 **STALE_AFTER** 保护，默认等于 DATA_RETENTION_TIME_IN_DAYS，**Stream 过期后无法恢复**，需要重建 — 考题常问"Stream 连续 15 天未消费 + 源表 retention 14 天会发生什么"，答案是 Stream 变 STALE，后续读取报错。

**Task DAG 的依赖和调度理解不到位** — Task Tree 里**只有根 Task 能设置 schedule**（CRON 或 interval），子 Task 通过 AFTER 子句链到父 Task 上，不能自己调度。Task 默认是**串行执行**（父跑完才跑子），想并行需要显式建多个 Task 分支。常见错误：以为在子 Task 上设 schedule 会生效（不会，会报错）。另一个高频错题：**SYSTEM$STREAM_HAS_DATA()** 必须放在 Task 的 **WHEN** 子句里用，不是在 Task body 里 IF，否则空跑也会消耗 credit。Serverless Task 和 User-managed Task（需要指定 warehouse）的计费模型也经常考。

**Snowpipe 和 Snowpipe Streaming 混为一谈** — 这是两个完全不同的产品。**Snowpipe**（批式）：基于文件，你上传文件到 stage → 事件触发 → Snowpipe 执行 COPY INTO，延迟约 1 分钟，按加载的文件数付费，使用 Snowflake 管理的 serverless 资源。**Snowpipe Streaming**：基于行，通过 Java SDK 或 Kafka Connector 直接写入表，不经过 stage 文件，延迟 **秒级**，按写入行数 + 计算时间付费，使用 client 端资源 + Snowflake 服务端 row buffering。考题会给场景让你选：有"上传 CSV 文件"关键词选批式 Snowpipe，有"Kafka / 实时事件流 / 亚秒级延迟"选 Snowpipe Streaming。它们也可以混用（lambda 架构），但计费和监控接口完全不同。

**物化视图 vs Dynamic Tables vs Result Cache 选型不清** — **Result Cache**：Cloud Services 层免费的查询结果缓存，24 小时有效，源数据未变时命中，**零成本**但不可控。**物化视图（Materialized View）**：Enterprise Edition 起支持，自动后台刷新，**限制很严**（单表、不支持 joins、不支持 window functions、不支持 UDF），适合对单大表做聚合。**Dynamic Tables**：2023 年 GA 的新特性，**声明式增量计算**，支持 joins 和复杂 SQL，用 TARGET_LAG 控制新鲜度，是 Streams+Tasks 的简化替代。考题最爱出"一个需要 join 两张表 + 5 分钟新鲜度"的场景 — 物化视图做不了（不支持 join），Streams+Tasks 能做但代码复杂，Dynamic Tables 才是最优解。

**Query Profile 误读导致优化方向错** — Profile 里最容易看错的几个信号：(1) **Local Disk Spilling** 不等于灾难，小量 spilling 正常；但 **Remote Disk Spilling** 几乎肯定是性能杀手，必须立刻升 warehouse 或重写查询。(2) **Partitions Scanned / Partitions Total** 比例接近 100% 不代表一定是坏事（小表本来就全扫），关键看绝对数字 + 扫描字节数。(3) **Exploding Join**（输出行数 >> 输入行数之和）通常是 join key cardinality 没算清楚或有笛卡尔积，不是 warehouse 问题，升 size 没用必须改 SQL。(4) **Bytes sent over the network** 高 → 可能有跨 region 数据传输或 Result Cache miss。考题会给 profile 截图让你二选一"该升 warehouse 还是该改 SQL"，答错直接送分。

**Clustering Key 的选择误区** — 不是所有表都该加 Clustering Key。选型原则：(1) 表足够大（> 1TB 才值得）；(2) 查询常用这一列做过滤或 join；(3) 列的基数适中（太低如 gender 无效，太高如 uuid 维护成本爆炸）；(4) 数据不是自然按这一列加载的。**AUTOMATIC_CLUSTERING** 开了之后 Snowflake 会后台持续重聚类，消耗 credit — 对写入频繁的表成本可能高于收益。考题爱出"这张表该加 Clustering 吗"的场景，答案经常是 "不加 / 先看 SYSTEM$CLUSTERING_INFORMATION 的 depth"。另一个坑：加 Clustering Key **不会立刻重组历史数据**，需要 ALTER TABLE ... RECLUSTER 或等自动聚类慢慢做。

**UDF / UDTF / Stored Procedure 的边界混淆** — UDF（标量函数，一行输入一行输出）、UDTF（表函数，一行输入多行输出）、Stored Procedure（过程，可以执行 DML 和事务）三者能做什么不能做什么考试经常细抠。**UDF 不能有副作用**（不能 INSERT / UPDATE），**Stored Procedure 才能**。**EXECUTE AS CALLER vs EXECUTE AS OWNER** 决定了权限检查逻辑 — OWNER 模式下 proc 以创建者权限跑（常用于数据脱敏场景），CALLER 模式下以调用者权限跑。Python Snowpark 的 UDF 装饰器 @udf 和存储过程装饰器 @sproc 别搞混。

**Time Travel 和 Fail-safe 的对象级配置** — 账户级 DATA_RETENTION_TIME_IN_DAYS 是默认值，**可以在 database / schema / table 级别覆盖**。**MIN_DATA_RETENTION_TIME_IN_DAYS**（账户级）可以强制下限防止用户把表的 retention 改到 0。临时表（TEMPORARY）和 transient 表**没有 Fail-safe**，transient 表 retention 最多 1 天 — 考题会问"创建 transient table 意味着省多少钱"，答案是没有 Fail-safe 的 7 天存储成本。