我们的ETL作业有时会在雪花中运行。我们有两个中型和2xl仓库。我们遵循的规则之一是，如果查询运行的时间少于10分钟，我们将移至中型仓库，而2XL则不然。但这是隔离的正确方法。
我知道Snowflake根据核心可用性对查询进行了并行处理。例如
2XL群集具有32个节点，每个节点8个核心。 Snowflake尝试将每个查询分为256个部分。 例如，如果我们运行一个查询：
select sum(a) from mytable;
然后256个核中的每个核扫描表的1/256。
但是我怎么知道一个表是否可以拆分为256个核，它可能没有足够的数据可以拆分。在这种情况下，在2XL上运行查询是没有意义的。
谢谢
答案 0 :(得分：0)
这都是一个主观的问题。
如果同时运行中号和2XL，为什么不在2XL上运行所有内容并保存中号，就像您向上/向下旋转2XL（如果保持不超过60秒）一样，付出了60秒。对于以完美线性方式进行> 10分钟的查询，将花费1分钟以上的时间。
如何知道它是否可以拆分是部分理论上的问题，它本质上是平行的
select id, count(*) from table group by id;
您有很多id的地方，非常并行，即使您只有一个id，由于计数没有冲突，这仍然是可并行的。.where-as
select id, count(distinct column2) ...
需要为每个id构建column2的集合，因此32个实例将获得不多的收益。但是，IO负载转换仍然可能是代价高昂的部分。
因此它取决于查询的约束，正在运行的查询以及它所处理的数据。这意味着您应该在不同大小的服务器上运行查询，以查看是否可以扩展您的数据负载。
答案 1 :(得分：0)
如果您的ETL流程是频繁执行的工作流的一部分，那么解决此问题的最佳方法是在Medium和2XL上测试每个查询，并确定您是否物有所值。我假设您不仅有两个仓库都一直在运行，而且想找出使这些仓库在工作流程中启动和关闭的最佳方法。通常，测试每个查询是最好的方法。否则，您可以查看极端情况（例如，介质正在造成泄漏的情况下，您肯定需要更大的仓库）。同样，在查询执行期间读取的微分区数量将使您了解仓库可能正在使用多少个线程。如果您的微分区较少，那么您就有线程，那么您正在使用过多的仓库。
最后，在“小”工作量和“大”工作量之间存在如此大的差距是不寻常的。我也建议您评估大型和XL大小的仓库。您无需花费更多时间即可配置更多的仓库并使之可用。只是让您在查询完成后将其关闭，以避免自动挂起带来的额外正常运行时间。