学习Redshift EXPLAIN计划

Question

我需要一些帮助来理解下面的解释计划:

1. 我有以下查询，返回219条记录，需要大约40秒运行:

查询:

SELECT
(TO_CHAR(DATE_TRUNC('second', CONVERT_TIMEZONE('GMT', 'UTC', "ABC"."time")), 'YYYY-MM-DD HH24:MI:SS')) AS "rtime",
COUNT(DISTINCT ABC.s) AS "s"
FROM
ABC
INNER JOIN TE ON "ABC"."e_id" = "TE"."e_id"
WHERE "TE"."e_code" = 'ABCDE'
GROUP by 1 
ORDER BY 1

解释计划:

XN Merge  (cost=1000000944628.86..1000000944629.36 rows=200 width=200)
Merge Key: resp
->  XN Network  (cost=1000000944628.86..1000000944629.36 rows=200 width=200)
Send to leader
->  XN Sort  (cost=1000000944628.86..1000000944629.36 rows=200 width=200)
Sort Key: resp
->  XN HashAggregate  (cost=944620.71..944621.21 rows=200 width=200)
->  XN Subquery Scan volt_dt_0  (cost=944506.75..944606.47 rows=2849 width=200)
->  XN HashAggregate  (cost=944506.75..944577.98 rows=2849 width=29)
->  XN Hash Join DS_DIST_ALL_NONE  (cost=132.60..944492.51 rows=2849 width=29)
Hash Cond: (((("outer".context_id)::text || ':'::text) || ("outer".e_id)::text) = ("inner".e_id)::text)
->  XN Seq Scan on ABC (cost=0.00..151081.63 rows=15108163 width=33)
->  XN Hash  (cost=132.60..132.60 rows=2 width=17)
->  XN Seq Scan on te  (cost=0.00..132.60 rows=2 width=17)
Filter: ((e_code)::text = 'ABCDE'::text)

下面是ABC表和TE表的设置细节:

DISTSTYLE EVEN
SORTKEY ( inserted_datetime );

DISTSTYLE ALL
SORTKEY ( e_id );

我想加快这个查询，我有以下问题:

1. 是顺序子句问题还是顺序扫描问题?我相信这是序列扫描，但我不确定我能修复它吗?
2. 我能说更高的成本价值意味着需要更多的时间吗?我认为，它不是。
3. 为什么'XN散列连接DS_DIST_ALL_NONE'代替'EVEN' DISTSTYLE?是因为两个表有不同的DISTSTYLE吗?
4. 为什么在这里使用子查询扫描?不知道

请指引我。

谢谢

Answer 1

生成volt_dt中间结果的子查询是一个重要的线索。Redshift将以这种方式分解复杂/大数据量计划的查询，以保持事物的有限性。另一个线索是你对DISTINCT的使用。以下是我认为正在发生的事情(但需要一些额外的数据来确定)。

由于on子句上的匹配太多，JOIN正在创建一个非常大的in数据集(数十亿行)。这个大数据集需要在红移周围重新分布以进行聚合。所以你需要做一个大的数据集，然后重新分配它，这需要花费很多时间。聚合是在一个生成的值上，它增加了额外的工作。我怀疑这就是时间流逝的方向。

这种类型的工作不会在EXPLAIN计划中显示为一个步骤，但是您可以看到"成本"值在排序步骤之前跳升。在排序之前的步骤中，开销很小，在排序步骤开始时开销很大。如果我是正确的，您应该能够在此查询的STL_DIST目录表中看到此工作。

要解决这个问题，你需要分析你的表，看看如何减少这个"行创建"，或者改变查询来创建没有DISTINCT的结果。

对于你的问题，这些都是最好的猜测。

1. 订单需要一些时间，但这不是主要问题。起始成本和最终成本之间的差别并不大。

2. EXPLAIN计划成本只是红移对每一步成本的最佳猜测。这两个成本值是开始和结束成本估计。成本值没有一个确切的定义，但它是Redshift用来评估要优化的查询计划的步骤的相对成本的指标。您将需要查看查询实际执行信息，以真正了解发生了什么。

3. 连接样式是好的。这仅仅意味着Redshift使用分布ALL来优化连接。这个连接不需要在集群中移动数据，因为它使用TE表的"本地"副本。当需要在集群中组织和重新分发连接结果时，聚合步骤就会出现问题。

4. 如上所述，生成的子查询是Redshift试图管理一个非常大的查询的数据。这是我评估JOIN生成大量数据的基础。

如果是我，我只会在JOIN的输出上运行一个带有WHERE子句的测试查询，并计算产生的行数。这将告诉您JOIN生成的数据有多大。

(PS。仅供参考，我正在旅行，所以我的回复能力会受到限制一段时间。