1. 课程导入与全景认知

在传统机器学习工程中，数据往往散落在对象存储、关系型数据库、特征库和本地文件系统之间，团队需要反复编写抽取脚本、搬运数据、维护离线与在线特征一致性。Snowflake 机器学习数据平台集成，指的是把 Snowflake 作为统一的数据与计算底座，让数据准备、特征工程、模型训练、模型注册、批量推理和在线推理尽量在同一个受治理的平台内完成，并通过 Snowpark、Snowflake Notebooks、Feature Store、Model Registry、Model Serving 等能力与外部机器学习框架衔接。它的核心不是"把模型搬进数据库"，而是让数据与模型共享同一套权限、血缘、版本和计算资源。

理解这一集成体系，需要先建立一张全景地图。下图给出 Snowflake 机器学习平台集成的整体结构：底层是存储与计算，中间是数据工程与特征层，上层是训练、注册与推理，右侧贯穿治理与运维。

从这张图可以看到，Snowflake 集成并不是单一工具，而是一条从数据到模型再到服务的链路。底层提供存储与弹性计算，中间层负责把原始数据加工成可复用、可追溯的特征，上层完成训练、注册和推理，治理能力则贯穿所有环节。理解这条链路，是后续学习每一项具体能力的前提。

核心价值：为什么要把机器学习放进 Snowflake

第一，消除数据搬运。传统方案中，数据科学家需要把 Snowflake 中的表导出为 Parquet 或 CSV，再上传到训练环境。数据量达到 TB 级时，导出和传输本身就是瓶颈，而且导出后的副本脱离了权限和血缘管理。使用 Snowpark 后，Python、Java、Scala 代码可以直接在 Snowflake 虚拟仓库中执行，DataFrame 操作会被下推为 SQL，数据不需要离开平台。

第二，保证训练与推理的一致性。离线训练用的特征和线上推理用的特征如果由两套代码生成，很容易出现偏差。Feature Store 通过特征视图和实体定义，让同一份特征定义同时服务于训练数据集生成和在线特征读取，减少"训练时表现好、上线后效果差"的问题。

第三，治理与安全天然继承。Snowflake 的 RBAC、行级访问策略、动态数据脱敏、对象标签等能力，对特征表、训练数据集、模型工件同样生效。模型训练读取了哪些表、产出了哪个版本、被谁调用，都可以通过血缘和访问历史追踪。

第四，弹性计算按需使用。训练任务可以使用独立的、规格更高的虚拟仓库，推理任务可以使用常驻的小仓库，两者互不干扰。任务结束后仓库可以自动挂起，避免长期占用资源。

典型应用场景

场景一：客户流失预测。数据团队在 Snowflake 中维护客户行为宽表，用 Snowpark 做特征聚合，生成过去 30 天、90 天的登录频次、消费金额、工单数量等特征，训练梯度提升模型，注册后每天批量对全量客户打分，输出流失概率表供运营使用。

场景二：实时推荐与风控。在线特征表存放用户最近行为向量，模型通过 Model Serving 暴露为 REST 端点，应用侧传入用户 ID 和上下文，端点读取在线特征并返回打分结果，要求端到端延迟在百毫秒级。

场景三：需求预测。零售企业把历史销量、促销日历、天气数据统一存入 Snowflake，用时间窗特征生成训练集，训练多个 SKU 粒度的预测模型，按周批量推理并把结果写回预测表，供补货系统消费。

场景四：异常检测。金融场景中对交易流水做无监督或半监督建模，特征和模型都在平台内闭环，检测结果直接写入告警表，由下游规则引擎决定是否拦截。

整体学习路径

本课程后续内容会沿着"数据—特征—训练—注册—推理—治理"这条主线展开。建议的学习顺序是：先掌握 Snowpark 的基本用法，理解 DataFrame 如何映射为 SQL、如何管理会话和依赖；再学习 Feature Store 的实体、特征视图和训练数据集生成，理解时间点正确性的含义；接着进入模型训练与 Model Registry，掌握版本管理和指标记录；然后学习批量推理与在线 Serving 的差异和适用条件；最后补齐权限、监控、成本和排障等工程化能力。