snowflake-cloud-data-platform - 需要有关雪花优化器的信息

Question

Snowflake 使用哪种优化器，基于规则还是基于成本。无法获得任何文档，需要解释如何编写更好的查询。

标签： snowflake-cloud-data-platform

Answer 1

我发现“了解‘规则’”比了解系统在做什么更有帮助。

我发现向新团队成员描述它有大量的表扫描，可以进行 map/reduce/merge 连接。

您可以通过选择获得所需答案所需的最小列集来加快表格扫描速度。

存在分区修剪，因此如果您有按“插入/排序”顺序的数据x 1-2,3-4,5-6并且您的查询有x = 5，那么前两个分区将不会被读取。

接下来因为都是合并连接，所以等连接是最快的事情。[编辑：] 这是想说，以百万行以上的顺序。基于复杂的连接逻辑将 1m 行连接到 1m 行a.v1 > b.v2 or a.v2 < b.v3 ... etc意味着你必须或多或少地让你超过万亿行，然后尝试看看。就像您a.v1 = b.v2 and a.v2 = b.v2现在可以加入确切的值一样，可以根据这些键对数据进行排序，并且可以完成合并连接，并且您的性能非常好（维基百科上的排序合并连接）。

这意味着有时在不同的 CTE 中多次从同一组源表中读取并加入这些表可能是处理大量数据的最快方法。[编辑：] 在上述语句的上下文中，人们经常在小型数据库 SQL 中执行相关的子查询，因为 a）你可以，为什么不呢，并且 b）他们可以在索引数据库上快速。但是在没有索引的雪花中，除了优化器不支持大多数相关子查询之外，您通常应该避免它们并在两个 CTE 中读取数据两次并通过等值连接加入/左加入这些数据以回答问题完成，因为 CTE 的任务是独立的，因此是可并行的，并且合并连接是接近最优的。并且为不在主要连接体中的数据计算（让我们假装小计）的浪费少于并行性的收益。（与加速小于 5 秒大小的查询相比，这最适合 30 秒或更长时间范围内的查询）。但是有了所有的东西，有一个基础模型，尝试/实验，戳和慢的东西，直到你无法重组你的数据或查询以使其更快。

与往常一样，查看运行查询的配置文件，查找删除了许多行的区域，并思考如何重构逻辑以在管道中更早地推动这些限制。