1. 课程导入与全景认知

在开始动手写第一条管道之前，我们需要先建立一张"地图"。Snowflake 的数据工程能力并不是单一功能，而是由存储、计算、数据加载、流式捕获、任务调度、通知与外部集成等多个部件协同构成的体系。如果一开始就扎进某个具体语法，很容易出现"会写 SQL 但不知道放在哪一层、什么时候触发、失败后谁来兜底"的问题。本节的目标是让你先看清整体轮廓：哪些能力属于批处理、哪些属于流式、任务编排在中间扮演什么角色，以及一个典型场景从数据落地到结果可用会经过哪些环节。

一、学习目标与能力边界

完成本课程后，你应当能够独立完成以下四类工作：

• 批处理管道构建：使用 COPY INTO、外部表、Snowpipe 将对象存储或本地文件持续加载进 Snowflake 表，并处理去重、错误行与加载历史。
• 流式与增量捕获：使用 Stream（流）对象捕获表的 CDC（变更数据捕获）记录，配合 Task（任务）实现分钟级增量处理，而不是每次全量重算。
• 任务编排：用 Task DAG 组织有依赖关系的 SQL、存储过程与 Snowpark 逻辑，设置调度频率、前置条件（WHEN）、错误通知与重试策略。
• 可观测与运维：通过 INFORMATION_SCHEMA、ACCOUNT_USAGE 视图与通知集成，判断任务是否按预期运行、数据是否新鲜、失败如何定位。

需要明确的边界是：Snowflake 负责"数据到达之后的加工与调度"，它不负责源端业务系统的变更捕获机制本身（如 MySQL binlog 解析通常由 Kafka Connect、Debezium 等外部工具完成），也不替代通用工作流引擎（如 Airflow）做跨系统的复杂编排。理解这条边界，能避免把不该由 Snowflake 承担的责任硬塞进 Task 里。

二、核心概念：批、流、任务三者的关系

批处理与流处理在 Snowflake 中并不是两套割裂的系统，而是共享同一份存储与计算资源，区别主要在触发方式与数据粒度：

• 批（Batch）：按固定周期或手动触发，一次处理一批文件或一段区间的数据，典型工具是 COPY INTO 与 Snowpipe 的批量加载模式。
• 流（Stream）：不是数据副本，而是对表变更的"偏移量记录"。它记录 INSERT、UPDATE、DELETE 的元数据，消费后偏移量前移，因此天然支持增量。
• 任务（Task）：调度的执行单元，可以按 cron 表达式或 AFTER 依赖关系触发，内部执行 SQL、调用存储过程或运行 Snowpark Python。

三者组合出的典型模式是：外部数据先经 Snowpipe 或 COPY INTO 落入原始表（Raw），原始表上建立 Stream 捕获增量，Task 按分钟或小时消费 Stream 并写入清洗层（Silver），再由下游 Task 聚合到应用层（Gold）。这条链路就是本课程反复出现的"批流一体"骨架。

三、整体架构与数据流

下图给出一个典型场景的端到端结构：左侧是数据来源与加载通道，中间是 Snowflake 内部的存储分层与流/任务编排，右侧是消费与监控出口。请注意箭头方向表示数据流动方向，虚线表示控制或元数据关系。

四、典型应用场景

这套架构在以下几类场景中价值最明显：

• 近实时报表：业务库变更经 CDC 进入对象存储，Snowpipe 自动加载，Stream + Task 每分钟合并到 Silver，BI 查询延迟可控制在数分钟内。
• 日志与事件分析：应用日志按小时批量写入，Task 定时聚合出错误率、响应时间分位数等指标，供运维看板使用。
• 多源数据整合：不同来源的订单、库存、用户数据分别加载到 Raw，再由 Task DAG 按依赖顺序清洗、关联、生成统一宽表。
• 数据回填与重跑：历史数据一次性 COPY INTO，再通过带参数的 Task 或存储过程按日期分区重算，避免全量刷新。

五、一个可参考的起步参数示例

为了让后面的章节有具体对象可操作，这里给出一个示例配置（属于教学假设，非实测结果）：原始表 RAW_ORDERS 按天分区，Snowpipe 使用 AUTO_INGEST = TRUE；Stream 命名为 STRM_ORDERS；清洗 Task 调度频率设为 1 MINUTE，并设置 WHEN SYSTEM$STREAM_HAS_DATA('STRM_ORDERS') 作为前置条件，避免空跑消耗计算资源；错误通知通过 ERROR_INTEGRATION 发送到消息队列。这些参数在后续章节会逐一展开，此处只需记住它们各自属于哪一层。

接下来，我们将从最基础的加载通道开始，逐步把这张全景图上的每个方框变成可以运行的真实对象。