Snowflake中SNS/SQS能否为COPY INTO提供细粒度加载路径

问题1解答 #

你的理解完全正确。
配置S3事件通知→SNS主题→Snowpipe的链路后，S3在新文件写入时会主动将包含文件完整对象键（全路径）、文件ETag、更新时间的事件消息推送给Snowpipe，Snowpipe直接根据消息里的单文件路径定位读取文件，本质就是你列出的第三种「指定命名文件」的最快加载模式，全程不会扫描@landing_data/sales/transactions路径下的全量历史文件，天然规避了目录文件增长带来的扫描性能损耗。
这里只需要注意一个配置细节：Snowpipe定义里的stage路径前缀必须和你要加载的文件路径前缀匹配，否则收到SNS消息后会自动过滤掉路径不匹配的文件，不会触发加载。按你当前的路径配置，只要Snowpipe绑定的stage前缀是@landing_data/sales/transactions，该路径下所有新增文件的通知都会被正常处理。

问题2解答 #

哪怕你因为场景限制不能使用Snowpipe自动摄入，在不调整S3结构、不删除源文件的约束下，也有成熟方案保证加载性能不随文件量增长衰减，按推荐优先级排序：

方案1：优先使用SNS驱动的Snowpipe自动摄入（最优解） #

这个方案完全匹配你的约束条件：

• 不需要修改现有S3文件夹结构，不需要对源文件做任何删除/移动操作
• 没有全目录扫描开销，加载性能和目录下总文件量无关，不会随时间衰减
• Snowpipe自带基于文件全路径+ETag的幂等去重机制，就算SNS重复推送同一文件的通知，也不会出现重复加载的问题，刚好适配你不能删除已加载源文件的要求

注意：配置时不要给Snowpipe设置过宽的扫描规则，保持默认基于事件通知触发加载的逻辑即可，避免引入不必要的扫描开销。

方案2：定时任务触发COPY时显式指定新增文件列表 #

如果你必须使用手动/定时调度的COPY INTO命令，完全可以避免全目录扫描：核心思路是每次加载前先获取上次调度后新增的文件清单，把文件路径直接传给COPY语句的FILES参数，此时Snowflake会直接读取指定文件，不会遍历整个目录做匹配，性能和单文件加载一致。
获取新增文件清单有两种无侵入实现方式：

• 方式A：调用S3的ListObjectsV2接口，按文件最后修改时间过滤出自上次加载完成后新增的文件，组装成文件路径列表传入COPY语句，示例语法如下：

copy into sales_table
  from @landing_data/sales/transactions
  files = ('2024/05/20/sales_001.csv', '2024/05/20/sales_002.csv')
  pattern='.*[.]csv';

• 方式B：给对应的外部stage开启目录表（Directory Table）功能。Snowflake会自动同步stage下所有文件的路径、大小、最后修改时间等元数据，元数据查询性能不会随文件量增长下降。每次加载前直接查询目录表，过滤出自上次加载后的新增文件路径，再传入COPY的FILES参数即可，不需要额外调用S3接口，所有逻辑都可以在Snowflake侧完成。

常见误区澄清：很多人认为只要COPY的FROM路径是粗粒度的父级目录，就一定会触发全目录扫描——实际上只要显式传入FILES参数指定具体文件列表，Snowflake就不会做任何目录遍历操作，性能和指定最细粒度单文件路径完全一致。

内容的提问来源于stack exchange，提问作者Long Luu