Question

以下查询SQL导致Redshift群集磁盘的一个节点已满

insert
into
  report.agg_info
  ( pd ,idate ,idate_str ,app_class ,app_superset ,aid ,pf ,is ,camp ,ua_camp_id ,country ,is_predict ,cohort_size ,new_users ,retained ,acc_re ,day_iap_rev ,iap_rev ,day_rev ,rev ) 
select
    p.pd ,
    p.idate ,
    p.idate_str ,
    p.app_class ,
    p.app_superset ,
    p.aid ,
    p.pf ,
    p.is ,
    p.camp ,
    p.ua_camp_id ,
    p.country ,
    1 as is_predict ,
    p.cohort_size ,
    p.new_users ,
    p.retained ,
    ar.acc_re ,
    p.day_iap_rev ,
    ar.iap_rev ,
    p.day_rev ,
    ar.rev
from
    tmp_predict p
join
    tmp_accumulate ar
        on p.pd = ar.pd
        and p.idate = ar.idate
        and p.aid = ar.aid
        and p.pf = ar.pf
        and p.is = ar.is
        and p.camp = ar.camp
        and p.ua_camp_id = ar.ua_camp_id
        and p.country = ar.country

查询计划是

XN Hash Join DS_DIST_BOTH (cost=11863664.64..218084556052252.12 rows=23020733790769 width=218)
    -> XN Seq Scan on tmp_predict p (cost=0.00..3954554.88 rows=395455488 width=188)
    -> XN Hash (cost=3954554.88..3954554.88 rows=395455488 width=165)
      -> XN Seq Scan on tmp_accumulate ar (cost=0.00..3954554.88 rows=395455488 width=165)

从上图可以看出，node-39比其他节点拥有更多的数据。因为join使数据偏斜。

为解决此问题，我们尝试使用update代替join

update
  report.agg_info
set
  acc_re = ar.acc_re,
  iap_rev = ar.iap_rev,
  rev = ar.rev
from
  tmp_accumulate ar
where
  report.agg_info.pd = ar.pd
  and report.agg_info.idate = ar.idate
  and report.agg_info.aid = ar.aid
  and report.agg_info.pf = ar.pf
  and report.agg_info.is = ar.is
  and report.agg_info.camp = ar.camp
  and report.agg_info.ua_camp_id = ar.ua_camp_id
  and report.agg_info.country = ar.country

查询计划

XN Hash Join DS_BCAST_INNER (cost=11863664.64..711819961371132.00 rows=91602 width=254)
    -> XN Seq Scan on agg_info (cost=0.00..2.70 rows=270 width=224)
    -> XN Hash (cost=3954554.88..3954554.88 rows=395455488 width=170)
      -> XN Seq Scan on tmp_accumulate ar (cost=0.00..3954554.88 rows=395455488 width=170)

数据根据图片均匀分布在所有节点上。但是，每个节点中都有更多数据。

我想知道，在Redshift中是否有通过联接处理数据偏斜的最佳实践？

Answer 1

https://docs.aws.amazon.com/redshift/latest/dg/c-analyzing-the-query-plan.html

寻找以下运营成本较高的广播运营商：
  •DS_BCAST_INNER：指示该表已广播到所有计算节点，这对于较小的表是好的，但对于较大的表则不理想。
  •DS_DIST_ALL_INNER：表示所有工作负载都在单个片上。
  •DS_DIST_BOTH：指示大量重新分配。

您的第一个查询中的

DS_DIST_BOTH正在将两个表重新分配到特定列上。您尚未包括在EXPLAIN代码段中选择的列，但它可能是联接中的第一列。

DS_BCAST_INNER正在向每个节点广播tmp_accumulate的完整副本。这两个操作都非常昂贵且缓慢。

您的联接非常广泛，第一列似乎很歪斜。您可以尝试2种方法来解决偏斜并防止广播：

更改连接中声明的列的顺序，以首先声明 most 个唯一（或最小偏斜）的列。第一列通常将用作重新分配键。（注意：如果表已经是diststyle键，这将不起作用。）
推荐。由于联接非常复杂且偏斜，因此您可以预先计算这些列中的哈希值，然后对该值进行联接。

--Example of Pre-Calculated Hash
CREATE TEMP TABLE tmp_predict 
    DISTKEY(dist_hash)
AS SELECT FUNC_SHA1(pd||idate::VARCHAR||aid::VARCHAR||pf::VARCHAR
                      ||is::VARCHAR||camp::VARCHAR||ua_camp_id::VARCHAR
                      ||country::VARCHAR) dist_hash
         ,pd ,idate ,aid ,pf ,is ,camp ,ua_camp_id, country
         ,…
     FROM …
;
CREATE TEMP TABLE tmp_accumulate 
    DISTKEY(dist_hash)
AS SELECT FUNC_SHA1(pd||idate::VARCHAR||aid::VARCHAR||pf::VARCHAR
                      ||is::VARCHAR||camp::VARCHAR||ua_camp_id::VARCHAR
                      ||country::VARCHAR) dist_hash
         ,pd ,idate ,aid ,pf ,is ,camp ,ua_camp_id, country
         ,…
     FROM …
;
INSERT INTO report.agg_info
SELECT …
FROM    tmp_predict p
JOIN    tmp_accumulate ar
    ON  p.dist_hash = ar.dist_hash
;

Answer 2

数据偏斜，因为似乎您要连接的表的所有数据都在一个节点上。这可能是由于缺少DISTKEY或高度偏斜的DISTKEY。

因此，您可以使用DISTSTYLE EVEN在所有节点上平均分配该表的数据，或者选择一个在数据中具有更多分配的DISTKEY。

有没有更好的方法可以通过加入Redshift来避免数据偏斜？

2 个答案: