我们的ETL作业有时会在雪花中运行。我们有两个仓库medium和2xl。我们遵循的规则之一是,如果查询运行时间少于10分钟,我们将移动到medium仓库,超过该时间的任何数据都将转移到2XL。但这是隔离的正确方式吗?
我知道Snowflake基于核心可用性并行化查询。例如
2XL集群有32个节点,每个节点8个核心。Snowflake尝试将每个查询拆分为256个部分。例如,如果我们运行一个查询:
select sum(a) from mytable;
然后256个核心中的每一个都扫描该表的1/256。
但是我怎么知道一个表是否可以拆分成256个核心,它可能没有足够的数据来拆分。在这种情况下,在2XL上运行查询是没有意义的。
谢谢
发布于 2020-05-27 08:04:05
这都是一个相当主观的问题。
如果你同时运行Medium和2XL,为什么不在2XL上运行所有的东西并保存媒体,就像你旋转2XL一样,如果它持续少于60秒,你将为这60秒买单。对于以完全线性方式耗时>10分钟的查询,将耗时超过1分钟。
你如何知道它是否可以拆分部分是理论上的,它本质上是平行的吗?
select id, count(*) from table group by id;
如果你有多个id,非常并行,即使你只有一个id,由于计数不冲突,这仍然是可并行的。其中-as
select id, count(distinct column2) ...
需要为每个id构建一组column2,因此通过32个实例并不能获得太多。但IO负载转换可能仍然是代价高昂的部分。
因此,它取决于查询的约束、正在运行的查询以及它所处理的数据。这意味着您应该在不同大小的服务器上运行查询,以查看是否针对您的数据负载进行了扩展。
发布于 2020-05-27 09:45:23
如果您的ETL进程是频繁执行的工作流的一部分,那么实现此目的的最佳方法是在介质和2XL上测试每个查询,并确定您是否获得了最佳性价比。我假设你不只是让两个仓库一直在运行,而且想要找出让这些仓库在你的工作流程中启动和关闭的最好方法。通常,测试每个查询是最好的方法。否则,您可以查看极端情况(例如,在介质造成溢出的情况下,您肯定会需要更大的仓库)。此外,在查询执行期间读取的微分区数量将使您了解仓库可能使用了多少个线程。如果你的微分区比线程少,那么你使用了太多的仓库。
最后,在你的“小”工作负载和“大”工作负载之间有如此大的差距是不寻常的。我也推荐评估大型和XL大小的仓库。配置更多的仓库并将它们提供给您是不需要任何成本的。只需在查询完成时关闭它们,以避免自动挂起带来的额外正常运行时间。
https://stackoverflow.com/questions/62028700
复制相似问题