通过ODBC将2000万条记录从SSIS加载到SNOWFLAKE

我正在尝试使用ODBC连接将大约2000万条记录从SSI加载到snowflake，这个加载需要花费很长时间才能完成。有没有比使用ODBC更快的方法？我可以考虑将其加载到平面文件中，然后使用平面文件加载到snowflake中，但我确定如何做到这一点

更新： 我使用bcp生成了一个文本文件，并使用ODBC连接将该文件放在雪花暂存上，然后使用copy into命令将数据加载到表中

---

问题：生成的txt文件是一个2.5gb文件，ODBC正在努力将该文件发送到snowflake stage。这方面有什么帮助吗

将压缩对象写入云提供商的对象存储（AWS S3、Azure blob等）然后

复制到

雪花中应该会更快。但也更加复杂

---

对于20000000个数据库调用，您一次不会写入一行？

生成文件，然后使用Snow CLI将其放入内部阶段。将Cooy用于stage->table。要进行一些编码，您永远无法避免通过网络传输GB，但将coukd压缩并传输成块的文件

ODBC在这样的数据库上运行速度很慢，Snowflake（和类似的柱状仓库）也希望吃掉零碎的文件，而不是单个的大文件。您最初的方法的问题是，在一个设计用于跨碎片暂存文件并行加载节点的系统上，ODBC使用方法不会特别快

第二种方法的问题是没有发生任何变化。带有head节点的非柱状数据库（比如Netezza）想要吃掉并切碎您的单个文件，但雪花或红移基本上会将其作为单个线程吸收到单个节点中。因此，在XS 1节点雪花集群上摄取单个2.5 GB文件所需的时间与L8节点雪花集群所需的时间相同。您的单个节点本身并没有饱和，并且有大量的CPU周期可供备用，什么也不做。Snowflake似乎在一个节点上使用最多8个写线程来执行提取或摄取操作。您可以在此处看到一些测试：

我的建议是制作至少8个大小（2.5GB/8）的文件，或者大约8个315MB的文件。对于2节点，至少16个。如果不是本机分解和水平缩放，则可能需要在文件创建过程中付出一些努力；尽管作为一种奖励，它可以将您的数据分解成更简单的小流程，以便在出现任何问题时中止/恢复/等等

---

还要注意的是，一旦数据被批量插入到Snowflake中，就不太可能以最佳方式放置以利用微分区的好处——因此我建议使用加载的数据重建表，并至少在经常受限的列上对其进行排序，一个事实表，我至少会重建和排序的日期

不，我不是一次只做一行，我正在尝试您建议的方法。我使用bcp命令创建了一个文件，并尝试使用copy-into加载