Snowflake使用External Access Integration上传SFTP过慢问题求助

以下是针对你遇到的上传耗时异常问题的具体排查方向：

• 检查Snowflake与SFTP服务器的网络链路
  Snowflake通过External Access Integration出站的网络路径和本地环境完全不同，可能存在高延迟、低带宽或中转节点瓶颈。可以在Snowflake的Python代码中添加网络性能测试：比如在建立SSH连接后，用paramiko.SSHClient.exec_command执行简单的echo命令，记录往返耗时；或者拆分文件传输为多个块，记录每个块的传输时间，判断是连接握手慢还是持续传输慢。同时确认SFTP服务器的防火墙是否对Snowflake的出站IP段做了带宽限制或QoS管控。

• 验证Snowflake仓库的资源可用性
  虽然配置了Medium仓库，但要确认执行上传时仓库是否有足够的空闲资源：

  • 查询WAREHOUSE_METERING_HISTORY视图，查看上传时间段内仓库的CPU/内存使用率、集群运行状态；
  • 检查QUERY_HISTORY中该查询的WAREHOUSE_QUEUE_TIME是否过长，排除资源被其他查询挤占的情况；
  • Snowflake的Python UDF/存储过程有默认的资源限制（如CPU配额、内存上限），可以确认是否达到了这些限制导致传输效率降低。

• 优化paramiko的传输参数
  本地传输快但Snowflake内慢，大概率是传输配置未适配Snowflake的运行环境：

  • 调整SFTPFile.putfo的chunk_size参数，默认chunk较小（通常是32KB），在Snowflake环境下会导致频繁的IO调用，建议尝试64KB、128KB甚至256KB的块大小；
  • 关闭SSH压缩：设置SSHClient.connect的compress=False，CSV文件本身压缩空间有限，开启压缩会额外消耗CPU资源拖慢传输；
  • 指定高效的加密算法：在connect时通过ciphers参数指定aes256-gcm@openssh.com这类高性能算法，避免使用Snowflake运行时中性能较差的加密套件。

• 分析Snowflake侧的详细日志

  • 查看QUERY_HISTORY中该查询的EXECUTION_TIME_BREAKDOWN，定位上传阶段的具体耗时环节（如网络等待、CPU处理）；
  • 检查External Access Integration的日志（通过DESCRIBE INTEGRATION查看日志位置），确认是否存在连接重试、权限验证超时等异常；
  • 在Python代码中添加更细粒度的遥测，比如记录SSH连接建立耗时、每个文件块的传输耗时，精准定位瓶颈点。

• 考虑替代传输方案
  如果上述优化后仍无改善，可能是Snowflake的External Access Integration本身存在传输性能限制。可以换用以下方案：

  • 先将CSV文件写入Snowflake的云存储Stage（如AWS S3、Azure Blob）；
  • 利用云厂商的原生SFTP服务（如AWS Transfer Family、Azure SFTP）或者第三方工具，将Stage中的文件同步到目标SFTP服务器，这类方案的传输路径经过云厂商优化，性能远优于Snowflake内部Python进程的直接传输。

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