📚 课程目录第3章数据加载方式概览与选型

3. 数据加载方式概览与选型

Snowflake 提供的数据接入能力并不是“一个工具打天下”，而是围绕数据到达形态、延迟要求、数据量级、转换位置和运维成本形成了一组互补方案。理解它们的差异，关键不是背功能清单，而是先判断数据在进入 Snowflake 之前处于什么状态：是已经落在对象存储中的文件，还是持续产生的消息流，还是需要由计算引擎批量写入的结果集。选型错误通常不是“不能用”，而是用了成本更高、延迟更长或运维更复杂的路径。

六种加载方式的定位

COPY INTO 是最基础的批量加载命令，适合文件已经存在于内部 Stage、Amazon S3、Azure Blob 或 Google Cloud Storage 的场景。它按批执行，支持模式匹配、文件格式定义、错误处理与加载历史查询。典型用法是：

COPY INTO sales_raw
FROM @my_stage/sales/
FILE_FORMAT = (TYPE = CSV FIELD_OPTIONALLY_ENCLOSED_BY = '"' SKIP_HEADER = 1)
PATTERN = '.*2024-06.*[.]csv'
ON_ERROR = 'CONTINUE';

它的优势是可控、可审计、成本低；缺点是必须由外部调度器触发，延迟通常以分钟到小时计。若数据每天到达一次、文件数量有限，COPY INTO 往往是最稳妥的选择。

Snowpipe 解决的是“文件到达后自动加载”的问题。它通过云存储事件通知或 REST API 触发，按文件粒度近实时加载，延迟通常在数十秒到几分钟。Snowpipe 仍然基于文件，因此适合 S3、GCS、Azure Blob 中不断产生的小文件或中批文件。它的计费按实际计算资源消耗，文件越小、触发越频繁，单位成本越高，因此需要控制文件大小和合并策略。

Snowpipe Streaming 则跳过了“先写文件再加载”的路径，通过 SDK 将行级数据直接写入 Snowflake 表，延迟可到秒级甚至亚秒级。它适合应用日志、点击流、IoT 事件等持续产生且要求低延迟的场景。与 Snowpipe 相比，它不依赖对象存储暂存，但需要客户端持续运行并处理重试、批大小和内存控制。

外部表不加载数据，而是把 Snowflake 表结构映射到外部存储中的文件，查询时按需读取。它适合“数据已在 S3/GCS/Azure 中、查询频率低、不希望复制一份”的场景，例如归档数据探索或数据湖联邦查询。由于每次查询都要访问外部存储，性能通常低于原生表，且不支持所有 DML 操作。

Kafka 连接器面向消息流。Snowflake 提供 Kafka Connector，将 Kafka topic 中的数据写入内部表，底层可选用 Snowpipe 或 Snowpipe Streaming 模式。它适合已有 Kafka 基础设施、需要把事件流持续接入数仓的团队。选型时要区分“Kafka 只是传输通道”还是“Kafka 本身就是数据源”，前者可考虑先落对象存储再 COPY，后者更适合连接器直写。

Spark 连接器面向已经使用 Spark 做转换或聚合的场景。通过 Snowflake Spark Connector，Spark 作业可以把 DataFrame 直接写入 Snowflake 表，适合大数据量批处理、复杂转换后落库，或从 Snowflake 读取数据参与 Spark 计算。它的优势是复用 Spark 生态，缺点是引入 Spark 集群运维，且写入性能受分区、并发和提交批次影响。

企业选型决策要点

实际选型时，建议按以下顺序判断。第一，数据是否已经以文件形式落在对象存储。如果是，优先考虑 COPY INTO 或 Snowpipe；如果文件到达频率高且要求自动触发，选 Snowpipe；如果只是每天一次批量，COPY INTO 加调度更简单、成本更可控。第二，延迟要求是否低于分钟级。若要求秒级，Snowpipe Streaming 或 Kafka 连接器更合适；若可以接受分钟级，Snowpipe 足够。第三，是否已有 Kafka 或 Spark 基础设施。已有 Kafka 且希望减少自研接入代码，用 Kafka 连接器；已有 Spark 且转换逻辑复杂，用 Spark 连接器把结果写入 Snowflake，避免在 Snowflake 内重复实现复杂计算。

还需要关注几个容易忽略的成本与运维因素。Snowpipe 按文件触发，小文件过多会导致频繁唤醒计算资源，建议在写入端做文件合并，例如把单文件控制在 100～250 MB。Snowpipe Streaming 需要客户端常驻，必须考虑断点续传、重复写入和 exactly-once 语义，通常要配合 offset 管理。外部表虽然省去加载，但查询延迟高，不适合高频 BI 查询。Kafka 连接器在 Snowpipe 模式下仍受文件大小影响，在 Streaming 模式下则要关注 SDK 版本与 Snowflake 账户的兼容性。Spark 连接器写入时，分区数、并发度和提交批次会直接影响加载时间，建议先用小批量验证再放大。

一个实用的判断口诀：文件批 → COPY INTO；文件自动 → Snowpipe；事件流 → Snowpipe Streaming；已有 Kafka → Kafka 连接器；已有 Spark → Spark 连接器；不想复制 → 外部表。但口诀只是起点，最终要结合延迟、成本、运维能力和数据治理要求综合决定。

最后，选型不是一次性的。很多企业会同时使用多种方式：历史数据用 COPY INTO 一次性导入，日常文件用 Snowpipe 自动加载，实时事件用 Snowpipe Streaming，数据湖探索用外部表。关键是为每条数据路径明确延迟目标、成本上限、责任人和监控指标，例如加载延迟、失败文件数、积压消息数和写入吞吐。只有把选型落到可观测的指标上，数据管道才能稳定运行。