使用 Query Acceleration Service¶

Query Acceleration Service (QAS) 可以加速仓库中的部分查询工作负载。当为仓库启用此功能时，此功能可以通过减少异常查询的影响来提高整体仓库性能，异常查询是比典型查询使用更多资源的查询。Query Acceleration Service 通过将查询处理工作的一部分卸载到由服务提供的共享计算资源来实现这一点。

可能受益于 Query Acceleration Service 的工作负载类型示例包括：

临时分析。
每个查询的数据量不可预测的工作负载。
具有大型扫描和选择性筛选器的查询。

Query Acceleration Service 可以通过并行执行更多工作并减少扫描和筛选所花费的挂钟时间，从而更有效地处理这些类型的工作负载。

备注

Query Acceleration Service 取决于服务器的可用性。因此，性能改进可能会随着时间的推移而波动。

本主题内容：

确定可能受益于 Query Acceleration 的查询和仓库¶

要确定可能受益于 Query Acceleration Service 的查询或仓库，可以查询 QUERY_ACCELERATION_ELIGIBLE 视图。还可以使用 SYSTEM$ESTIMATE_QUERY_ACCELERATION 函数评估特定查询是否符合加速条件。

符合条件的查询¶

一般来说，查询是符合条件的，因为它们有一部分查询计划可以使用 QAS 计算资源并行运行。这些查询分为两种模式之一：

使用聚合或选择性筛选器进行大型扫描。
插入许多新行的大型扫描。

对于如何才能构成符合资格的“足够大”的扫描，Snowflake 没有特定的分界线。资格阈值取决于多种因素，包括查询计划和仓库规模。Snowflake 仅在启用 QAS 后查询会加速的高置信度下将查询标记为符合条件。

查询不符合条件的常见原因¶

某些查询不符合 Query Acceleration 的条件。以下是无法加速查询的常见原因：

扫描中没有足够的分区。如果没有足够的分区进行扫描，查询加速的好处会被获取 Query Acceleration Service 资源的延迟所抵消。
即使查询具有筛选器，筛选器的选择性也可能不够。或者，如果查询具有与 GROUP BY 的聚合，则 GROUP BY 表达式的基数可能过高，不符合条件。
查询包括 LIMIT 子句，但没有 ORDER BY 子句。
查询包括返回非确定性结果的函数（例如，SEQ 或 RANDOM）。

使用 SYSTEM$ESTIMATE_QUERY_ACCELERATION 函数确定查询¶

SYSTEM$ESTIMATE_QUERY_ACCELERATION 函数可以帮助确定先前执行的查询是否可能受益于 Query Acceleration Service。如果查询符合 Query Acceleration 条件，则该函数返回不同 Query Acceleration 比例因子的估计查询执行时间。

示例¶

执行以下语句可帮助确定 Query Acceleration 是否可能有利于特定查询：

SELECT PARSE_JSON(SYSTEM$ESTIMATE_QUERY_ACCELERATION('8cd54bf0-1651-5b1c-ac9c-6a9582ebd20f'));

Copy

在本示例中，查询符合 Query Acceleration Service 的条件，并且包括使用该服务的估计查询时间：

{
  "estimatedQueryTimes": {
    "1": 171,
    "10": 115,
    "2": 152,
    "4": 133,
    "8": 120
  },
  "originalQueryTime": 300.291,
  "queryUUID": "8cd54bf0-1651-5b1c-ac9c-6a9582ebd20f",
  "status": "eligible",
  "upperLimitScaleFactor": 10
}

Copy

以下示例显示不符合 Query Acceleration Service 条件的查询的结果：

SELECT PARSE_JSON(SYSTEM$ESTIMATE_QUERY_ACCELERATION('cf23522b-3b91-cf14-9fe0-988a292a4bfa'));

Copy

上面的语句生成以下输出：

{
  "estimatedQueryTimes": {},
  "originalQueryTime": 20.291,
  "queryUUID": "cf23522b-3b91-cf14-9fe0-988a292a4bfa",
  "status": "ineligible",
  "upperLimitScaleFactor": 0
}

Copy

使用 QUERY_ACCELERATION_ELIGIBLE 视图确定查询和仓库¶

查询 QUERY_ACCELERATION_ELIGIBLE 视图可确定从 Query Acceleration Service 中受益最多的仓库。对于每个查询，该视图包括符合 Query Acceleration Service 条件的查询执行时间量。

示例¶

备注

这些示例假定 ACCOUNTADMIN 角色（或被授予了共享 SNOWFLAKE 数据库 :ref:` IMPORTED PRIVILEGES <label-enabling_usage_for_other_roles>` 的角色）正在使用。如果未使用，请在运行示例中的查询之前执行以下命令：

USE ROLE ACCOUNTADMIN;

Copy

根据符合加速条件的查询执行时间量，确定可能从服务中获益最多的查询：

SELECT query_id, eligible_query_acceleration_time
  FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_ACCELERATION_ELIGIBLE
  ORDER BY eligible_query_acceleration_time DESC;

Copy

确定可能从特定仓库 mywh 中的服务中获益最多的查询：

SELECT query_id, eligible_query_acceleration_time
  FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_ACCELERATION_ELIGIBLE
  WHERE warehouse_name = 'mywh'
  ORDER BY eligible_query_acceleration_time DESC;

Copy

确定在给定时间段内符合 Query Acceleration Service 条件的查询最多的仓库：

SELECT warehouse_name, COUNT(query_id) AS num_eligible_queries
  FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_ACCELERATION_ELIGIBLE
  WHERE start_time > 'Mon, 29 May 2023 00:00:00'::timestamp
  AND end_time < 'Tue, 30 May 2023 00:00:00'::timestamp
  GROUP BY warehouse_name
  ORDER BY num_eligible_queries DESC;

Copy

确定时间最符合 Query Acceleration Service 要求的仓库：

SELECT warehouse_name, SUM(eligible_query_acceleration_time) AS total_eligible_time
  FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_ACCELERATION_ELIGIBLE
  GROUP BY warehouse_name
  ORDER BY total_eligible_time DESC;

Copy

确定给定仓库的 Query Acceleration Service 的上限比例因子：

SELECT MAX(upper_limit_scale_factor)
  FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_ACCELERATION_ELIGIBLE
  WHERE warehouse_name = 'mywh';

Copy

确定给定仓库的 Query Acceleration Service 的比例因子分布：

SELECT upper_limit_scale_factor, COUNT(upper_limit_scale_factor)
  FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_ACCELERATION_ELIGIBLE
  WHERE warehouse_name = '<warehouse_name>'
  GROUP BY 1 ORDER BY 1;

Copy

支持的 SQL 命令¶

Query Acceleration Service 支持以下 SQL 命令：

SELECT

INSERT

CREATE TABLE AS SELECT (CTAS)

如果具有支持的 SQL 命令的查询或查询的一部分（即子查询或子句）符合加速条件，可以由 Query Acceleration Service 加速。

启用 Query Acceleration¶

通过在创建仓库（使用 CREATE WAREHOUSE）时或稍后（使用 ALTER WAREHOUSE）时指定 ENABLE_QUERY_ACCELERATION = TRUE 来启用 Query Acceleration Service。

示例¶

以下示例为名为 my_wh 的仓库启用了 Query Acceleration Service：

CREATE WAREHOUSE my_wh WITH
  ENABLE_QUERY_ACCELERATION = true;

Copy

执行 SHOW WAREHOUSES 命令以显示有关 my_wh 仓库的详细信息。

SHOW WAREHOUSES LIKE 'my_wh';

+---------+---------+----------+---------+---------+--------+------------+------------+--------------+-------------+-----------+--------------+-----------+-------+-------------------------------+-------------------------------+-------------------------------+--------------+---------+---------------------------+-------------------------------------+------------------+---------+----------+--------+-----------+------------+
| name    | state   | type     | size    | running | queued | is_default | is_current | auto_suspend | auto_resume | available | provisioning | quiescing | other | created_on                    | resumed_on                    | updated_on                    | owner        | comment | enable_query_acceleration | query_acceleration_max_scale_factor | resource_monitor | actives | pendings | failed | suspended | uuid       |
|---------+---------+----------+---------+---------+--------+------------+------------+--------------+-------------+-----------+--------------+-----------+-------+-------------------------------+-------------------------------+-------------------------------+--------------+---------+---------------------------+-------------------------------------+------------------+---------+----------+--------+-----------+------------|
| MY_WH   | SUSPENDED | STANDARD | Medium |       0 |      0 | N          | N          |          600 | true        |           |              |           |       | 2023-01-20 14:31:49.283 -0800 | 2023-01-20 14:31:49.388 -0800 | 2023-01-20 16:34:28.583 -0800 | ACCOUNTADMIN |         | true                      |                                   8 | null             |       0 |        0 |      0 |         4 | 1132659053 |
+---------+---------+----------+---------+---------+--------+------------+------------+--------------+-------------+-----------+--------------+-----------+-------+-------------------------------+-------------------------------+-------------------------------+--------------+---------+---------------------------+-------------------------------------+------------------+---------+----------+--------+-----------+------------+

Copy

Query Acceleration Service 可以提高仓库的 credit 消耗率。最大比例因子可以帮助限制消耗速率。有关 QUERY_ACCELERATION_MAX_SCALE_FACTOR 属性的更多详细信息，请参阅 CREATE WAREHOUSE 或 ALTER WAREHOUSE。

QUERY_ACCELERATION_ELIGIBLE 视图和 SYSTEM$ESTIMATE_QUERY_ACCELERATION 函数在为仓库确定适当的比例因子时可能很有用。有关详细信息，请参阅确定可能受益于 Query Acceleration 的查询和仓库（本主题内容）。

调整比例因子¶

比例因子是一种成本控制机制，它允许您设置仓库可以为 Query Acceleration 租用的计算资源量的上限。此值用作基于仓库大小和成本的乘数。

例如，假设您将中型仓库的比例因子设置为 5。这意味着：

该仓库可以租用高达中型仓库 5 倍大小的计算资源。
由于中型仓库的成本为每小时 4 个 credit，因此租赁这些资源的成本可能高达每小时 20 个 credit（每个仓库 4 个 credit x 其大小的 5 倍）。

无论同时有多少查询使用 Query Acceleration Service，成本都是相同的。Query Acceleration Service 仅在使用时按秒计费。这些 credit 与仓库使用量分开计费。

并非所有查询都需要比例因子提供的全套资源。服务请求的资源量取决于有多少查询符合加速条件，以及将处理多少数据来回答相应查询。无论比例因子值或请求的资源量如何，用于 Query Acceleration 的可用计算资源量都受到服务中资源的可用性和其他并发请求的数量的约束。Query Acceleration Service 仅使用所需的资源以及执行查询时可用的资源。

如果未显式设置比例因子，则默认值为 8。将比例因子设置为 0 可以消除上限限制，并允许查询根据需要租用尽可能多的资源来为查询提供服务。

示例¶

下面的示例修改名为 my_wh 的仓库，以启用最大比例因子为 0 的 Query Acceleration Service。

ALTER WAREHOUSE my_wh SET
  ENABLE_QUERY_ACCELERATION = true
  QUERY_ACCELERATION_MAX_SCALE_FACTOR = 0;

Copy

监控 Query Acceleration Service 使用情况¶

使用 Web 界面监控 Query Acceleration 使用情况¶

启用 Query Acceleration Service 后，您可以查看查询配置文件中的配置文件概述面板，以查看 Query Acceleration 结果的效果。

下面的屏幕截图显示了为整个查询显示的统计信息的示例。如果对查询中的多个操作进行了加速，则会在此视图中汇总结果，以便您可以查看 Query Acceleration Service 完成的工作总量。

Profile Overview 面板的 Query Acceleration 部分包括以下统计数据：

服务扫描的分区数 – 为扫描而卸载到 Query Acceleration Service 的文件数。
为加速选择的扫描次数 – 正在加速的表扫描次数。

在操作员详细信息（有关更多信息，请参阅配置文件概述/运算符详细信息）中，点击操作员以查看详细信息。以下屏幕截图显示了为 TableScan 操作显示的统计信息的示例：

TableScan 详细信息面板的 Query Acceleration 部分包括以下统计信息：

服务扫描的分区数 – 为扫描而卸载到 Query Acceleration Service 的文件数。

使用 Account Usage QUERY_HISTORY 视图监控 Query Acceleration 使用情况¶

要查看 Query Acceleration 对查询的影响，可以使用 QUERY_HISTORY 视图中的以下列。

QUERY_ACCELERATION_BYTES_SCANNED
QUERY_ACCELERATION_PARTITIONS_SCANNED
QUERY_ACCELERATION_UPPER_LIMIT_SCALE_FACTOR

您可以使用这些列来确定从 Query Acceleration Service 中受益的查询。对于每个查询，您还可以确定 Query Acceleration Service 扫描的分区和字节总数。

有关这些列中每一列的说明，请参阅 QUERY_HISTORY 视图。

备注

对于给定的查询，使用 Query Acceleration Service 时 QUERY_ACCELERATION_BYTES_SCANNED 和 BYTES_SCANNED 列的总和可能大于不使用该服务时的总和。列 QUERY_ACCELERATION_PARTITIONS_SCANNED 和 PARTITIONS_SCANNED 的总和也是如此。

字节和分区数量的增加是由于服务生成的中间结果，以促进 Query Acceleration。

例如，要查找 Query Acceleration Service 在过去 24 小时内扫描的字节数最多的查询：

SELECT query_id,
       query_text,
       warehouse_name,
       start_time,
       end_time,
       query_acceleration_bytes_scanned,
       query_acceleration_partitions_scanned,
       query_acceleration_upper_limit_scale_factor
  FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY
  WHERE query_acceleration_partitions_scanned > 0 
  AND start_time >= DATEADD(hour, -24, CURRENT_TIMESTAMP())
  ORDER BY query_acceleration_bytes_scanned DESC;

Copy

要查找 Query Acceleration Service 在过去 24 小时内扫描的分区数最多的查询：

SELECT query_id,
       query_text,
       warehouse_name,
       start_time,
       end_time,
       query_acceleration_bytes_scanned,
       query_acceleration_partitions_scanned,
       query_acceleration_upper_limit_scale_factor
  FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY
  WHERE query_acceleration_partitions_scanned > 0 
  AND start_time >= DATEADD(hour, -24, CURRENT_TIMESTAMP())
  ORDER BY query_acceleration_partitions_scanned DESC;

Copy

Query Acceleration Service 成本¶

Query Acceleration 消耗 credit，因为它使用无服务器计算资源来执行符合条件的查询的部分。

Query Acceleration 与 Snowflake 中的其他无服务器功能一样，按秒为所使用的计算资源付费。要了解 Query Acceleration Service 每个计算小时消耗了多少 credit，请参阅 Snowflake 服务使用表中的“无服务器功能 credit 表”。

在 Classic Console 中查看计费信息¶

如果为账户启用了 Query Acceleration，则 Classic Console 中的计费页面将包含一个名为 QUERY_ACCELERATION 的仓库，该仓库显示服务在您账户中的所有仓库中使用的所有 credit。

下面的屏幕截图显示了为 QUERY_ACCELERATION 仓库显示的计费信息的示例：

使用 Account Usage QUERY_ACCELERATION_HISTORY 视图查看计费¶

您可以在 Account Usage QUERY_ACCELERATION_HISTORY 视图中查看计费数据。

示例¶

此查询返回您的账户中每个仓库月初至今用于 Query Acceleration Service 的 Credit 总数：

SELECT warehouse_name,
       SUM(credits_used) AS total_credits_used
  FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_ACCELERATION_HISTORY
  WHERE start_time >= DATE_TRUNC(month, CURRENT_DATE)
  GROUP BY 1
  ORDER BY 2 DESC;

Copy

使用 Organization Usage QUERY_ACCELERATION_HISTORY 视图查看计费¶

您可以在 Organization Usage QUERY_ACCELERATION_HISTORY 视图中查看组织中所有账户的 Query Acceleration Service 的计费数据。

示例¶

此查询返回每个账户中每个仓库月初至今用于 Query Acceleration Service 的总 credit：

SELECT account_name,
       warehouse_name,
       SUM(credits_used) AS total_credits_used
  FROM SNOWFLAKE.ORGANIZATION_USAGE.QUERY_ACCELERATION_HISTORY
  WHERE usage_date >= DATE_TRUNC(month, CURRENT_DATE)
  GROUP BY 1, 2
  ORDER BY 3 DESC;

Copy

使用 QUERY_ACCELERATION_HISTORY 函数查看计费¶

您还可以使用 Information Schema QUERY_ACCELERATION_HISTORY 函数查看计费数据。

示例¶

以下示例使用 QUERY_ACCELERATION_HISTORY 函数返回有关此服务在过去 12 小时内加速的查询的信息：

SELECT start_time,
       end_time,
       credits_used,
       warehouse_name,
       num_files_scanned,
       num_bytes_scanned
  FROM TABLE(INFORMATION_SCHEMA.QUERY_ACCELERATION_HISTORY(
    date_range_start=>DATEADD(H, -12, CURRENT_TIMESTAMP)));

Copy

评估成本和性能¶

本节包括示例查询，这些查询可能有助于您评估启用 Query Acceleration Service 前后的查询性能和成本。

查看仓库和 Query Acceleration Service 成本¶

下面的查询计算特定仓库的仓库和 Query Acceleration Service 的成本。您可以在为仓库启用 Query Acceleration Service 后执行此查询，以比较启用 Query Acceleration 前后的成本。查询的日期范围从首次使用 Query Acceleration Service credit 前 8 周开始，到最后一次产生 Query Acceleration Service 费用后 8 周（或截至当前日期）。

备注

如果仓库属性和工作负载在启用 Query Acceleration Service 之前和之后相同，则此查询对于评估服务成本非常有用。
仅当仓库中存在用于加速查询的 Credit 使用量时，此查询才返回结果。

此示例查询返回仓库和 my_warehouse 的 Query Acceleration Service 成本：

WITH credits AS (
  SELECT 'QC' AS credit_type,
         TO_DATE(end_time) AS credit_date,
         SUM(credits_used) AS num_credits
    FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_ACCELERATION_HISTORY
    WHERE warehouse_name = 'my_warehouse'
    AND credit_date BETWEEN
           DATEADD(WEEK, -8, (
             SELECT TO_DATE(MIN(end_time))
               FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_ACCELERATION_HISTORY
               WHERE warehouse_name = 'my_warehouse'
           ))
           AND
           DATEADD(WEEK, +8, (
             SELECT TO_DATE(MAX(end_time))
               FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_ACCELERATION_HISTORY
               WHERE warehouse_name = 'my_warehouse'
           ))
  GROUP BY credit_date
  UNION ALL
  SELECT 'WC' AS credit_type,
         TO_DATE(end_time) AS credit_date,
         SUM(credits_used) AS num_credits
    FROM SNOWFLAKE.ACCOUNT_USAGE.WAREHOUSE_METERING_HISTORY
    WHERE warehouse_name = 'my_warehouse'
    AND credit_date BETWEEN
           DATEADD(WEEK, -8, (
             SELECT TO_DATE(MIN(end_time))
               FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_ACCELERATION_HISTORY
               WHERE warehouse_name = 'my_warehouse'
           ))
           AND
           DATEADD(WEEK, +8, (
             SELECT TO_DATE(MAX(end_time))
               FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_ACCELERATION_HISTORY
               WHERE warehouse_name = 'my_warehouse'
           ))
  GROUP BY credit_date
)
SELECT credit_date,
       SUM(IFF(credit_type = 'QC', num_credits, 0)) AS qas_credits,
       SUM(IFF(credit_type = 'WC', num_credits, 0)) AS compute_credits,
       compute_credits + qas_credits AS total_credits,
       AVG(total_credits) OVER (
         PARTITION BY NULL ORDER BY credit_date ROWS BETWEEN 6 PRECEDING AND CURRENT ROW)
         AS avg_total_credits_7days
  FROM credits
  GROUP BY credit_date
  ORDER BY credit_date;

Copy

查看查询性能¶

此查询返回给定仓库的符合 Query Acceleration 条件的查询的平均执行时间。查询的日期范围从首次使用 Query Acceleration Service credit 前 8 周开始，到最后一次产生 Query Acceleration Service 费用后 8 周（或截至当前日期）。这些结果可能有助于您评估启用 Query Acceleration Service 后平均查询性能的变化。

备注

如果仓库工作负载在启用 Query Acceleration Service 之前和之后保持不变，则此查询对于评估查询性能最有用。
如果仓库工作负载保持稳定， num_execs 列中的值应该保持一致。
如果查询结果的 num_execs 列中的值急剧增加或减少，则此查询的结果可能对查询性能评估没有用处。

此示例查询按天返回查询执行时间，并计算仓库 my_warehouse 中符合加速条件的查询的前一周的 7 天平均值：

WITH qas_eligble_or_accelerated AS (
  SELECT TO_DATE(qh.end_time) AS exec_date,
        COUNT(*) AS num_execs,
        SUM(qh.execution_time) AS exec_time,
        MAX(IFF(qh.query_acceleration_bytes_scanned > 0, 1, NULL)) AS qas_accel_flag
    FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY AS qh
    WHERE qh.warehouse_name = 'my_warehouse'
    AND TO_DATE(qh.end_time) BETWEEN
           DATEADD(WEEK, -8, (
             SELECT TO_DATE(MIN(end_time))
               FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_ACCELERATION_HISTORY
              WHERE warehouse_name = 'my_warehouse'
           ))
           AND
           DATEADD(WEEK, +8, (
             SELECT TO_DATE(MAX(end_time))
               FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_ACCELERATION_HISTORY
              WHERE warehouse_name = 'my_warehouse'
           ))
    AND (qh.query_acceleration_bytes_scanned > 0
          OR
          EXISTS (
            SELECT 1
              FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_ACCELERATION_ELIGIBLE AS qae
               WHERE qae.query_id = qh.query_id
               AND qae.warehouse_name = qh.warehouse_name
          )
         )
    GROUP BY exec_date
)
SELECT exec_date,
       SUM(exec_time) OVER (
         PARTITION BY NULL ORDER BY exec_date ROWS BETWEEN 6 PRECEDING AND CURRENT ROW
       ) /
       NULLIFZERO(SUM(num_execs) OVER (
         PARTITION BY NULL ORDER BY exec_date ROWS BETWEEN 6 PRECEDING AND CURRENT ROW)
       ) AS avg_exec_time_7days,
      exec_time / NULLIFZERO(num_execs) AS avg_exec_time,
      qas_accel_flag,
      num_execs,
      exec_time
  FROM qas_eligble_or_accelerated;

Copy

该语句的输出包括以下列：

列	描述
EXEC_DATE	查询执行日期。
AVG_EXEC_TIME_7DAYS	前 7 天（含 EXEC_DATE）的平均执行时间。
AVG_EXEC_TIME	平均查询执行时间。
QAS_ACCEL_FLAG	如果加速了任何查询，则为 1；如果没有加速查询，则为 NULL。
NUM_EXECS	加速的查询次数。
EXEC_TIME	所有符合 Query Acceleration 条件的查询的总执行时间。

与搜索优化兼容¶

Query Acceleration 和搜索优化可以协同工作以优化查询性能。首先，搜索优化可以剪切查询不需要的微分区。然后，对于符合条件的查询，Query Acceleration 可以将其余部分工作分流到服务提供的共享计算资源。

这两种服务所加速的查询性能因工作负载和可用资源而异。