Snowflake cloud data platform 查询大型表时的雪花性能问题

我正在尝试查询一个表，该表包含按日期和公司聚集的1Tb数据。一个简单的查询需要很长时间

过帐查询和查询配置文件

SELECT
    sl.customer_code,
    qt_product_category_l3_sid,
    qt_product_brand_sid,
    sl.partner_code,
    sl.transaction_id,
    dollars_spent,
    units,
    user_pii_sid,
    promo_flag,
    media_flag
FROM 
    cdw_dwh.public.qi_sg_promo_media_sales_lines_fact sl
WHERE  
    transaction_date_id >= (to_char(current_date - (52*7) , 'yyyymmdd')  ) 
    AND sl.partner_code IN ('All Retailers')
    AND qt_product_category_l3_sid IN (SELECT DISTINCT qt_product_category_l3_sid 
                                       FROM cdw_dwh.PUBLIC.qi_sg_prompt_category_major_brand 
                                       WHERE qt_product_category_l1_sid IN (246))
                                         AND qt_product_brand_sid IN (SELECT qt_product_brand_sid 
                                                                      FROM cdw_dwh.PUBLIC.qi_sg_prompt_category_major_brand 
                                                                      WHERE qt_product_major_brand_sid IN (246903, 430138))

“简单查询”我不确定是否有这样的事情。一个天真的问题，当然

从really\u large\u表格中选择*，其中column1=值

如果您只关心其中的一列或两列，则性能会非常差。因为雪花必须加载所有数据。通过使用

从列1=值的大表格中选择列1、列2

现在只需要从数据存储中读取两列数据

可能您正在查找值为100的数据，因为您认为不应该发生这种情况。然后

从真正的大表格中选择column1、column2，其中column1>100限制1

将表现得比以前好得多

按column1 desc limit 50从真大表格顺序中选择column1、column2

但是，如果你所做的是尽可能少的工作来得到一个正确的答案，那么你的下一个选择就是增加仓库的规模。这对于IO绑定的工作来说是一个标量改进，但是一些聚合步骤并不是线性的

另一件需要注意的事情是，有时您的计算可能会产生太多的中间状态，它会“外部溢出”（确切的措词不正确），这很像内存耗尽而要交换磁盘

然后，我们看到了在JavaScript UDF中做太多工作时的内存压力，这降低了速度

但是，通过查看查询配置文件和热点可以发现其中的大部分内容。
99%的时间用于扫描表。查询中的过滤器与集群键不匹配，因此没有多大帮助。根据您在此表上拥有的历史数据量，以及您是否将继续读取一年的数据，您最好使用qt_product_brand_sid或qt_product_category_l3_sid进行聚类（或创建物化视图），具体取决于哪个会更快地过滤数据
 大的更改需要将事务日期的数据结构更改为true date字段vs varchar

第二，在子句中有一个值。使用=代替。
但是对于其他IN子句，我建议重新编写查询，将这些子查询分离为CTE，然后只加入这些CTE。
使用此查询：

    SELECT
        sl.customer_code,
        s1.qt_product_category_l3_sid,
        s1.qt_product_brand_sid,
        sl.partner_code,
        sl.transaction_id,
        s1.dollars_spent,
        s1.units,
        s1.user_pii_sid,
        s1.promo_flag,
        s1.media_flag
    FROM 
        cdw_dwh.public.qi_sg_promo_media_sales_lines_fact sl,
        cdw_dwh.PUBLIC.qi_sg_prompt_category_major_brand prod_cat,
        cdw_dwh.PUBLIC.qi_sg_prompt_category_major_brand prod_brand
    WHERE  
        s1.transaction_date_id >= (to_char(current_date - (52*7) , 'yyyymmdd')  ) 
        AND sl.partner_code IN ('All Retailers')
        AND s1.qt_product_category_l3_sid =prod_cat.qt_product_category_l3_sid 
        AND prod_cat.qt_product_category_l1_sid =246
        AND prod_cat.qt_product_brand_sid=prod_brand.qt_product_brand_sid 
        AND prod_brand.qt_product_major_brand_sid IN (246903, 430138)

显然，性能是Snowflake R&D关注的一个领域。在努力使复杂查询在大数据上执行后，我们使用Exasol获得了100倍的改进，没有任何调整。
查看查询配置文件，查看花费的时间（远程IO vs处理）等，如果您有以下问题：“为什么这个查询有这么多远程IO”也许我们可以帮上忙。我看到了查询配置文件，99%的执行时间都是在扫描表上完成的“利用聚集列作为筛选器的查询？除非您按日期进行筛选，否则您并没有真正有效地进行修剪，Snowflake将需要扫描所有分区以获得结果。已发布问题中的查询和查询计划。请提出一个提高性能的想法我们正在使用XL warehouse顺便说一句，我只从表中选择了4列，我运行了1年，扫描了所有分区的一半。很好，您只扫描了一半的表。接下来要看的是，在表扫描之后，行的删除率是多少。所以，如果你要拉n百万行，然后做一个过滤器，它会下降，那么你的集群可能会受益于不同。如果没有行删除，那么您只是在处理大量数据，并获得一个更大的实例。对于简单的东西，它们是相当线性的。可能会发布查询计划的图片。在问题中发布查询和查询计划。请提出一个改进性能的想法。你能具体说明复杂的查询有多大帮助吗？我不知道你的意思。Snowflake可以很好地处理简单查询（查询计划中约有10个节点），即使是在海量数据上。但是，随着复杂性的增加，性能会迅速下降。我们在查询计划中有100多个节点（表生成）。雪花的支持基本上是耸耸肩。总有一天，他们会有索引和更快更高效的查询计划器。我的意思是，如果你能比较一下提供了100倍改进的“复杂查询”和你的基线查询，这将是一个很好的答案。