Greenplum , HAWQ outer join与motion问题讲解

本文涉及的产品
Redis 开源版,标准版 2GB
推荐场景:
搭建游戏排行榜
云数据库 Tair(兼容Redis),内存型 2GB
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
简介:

Greenplum , HAWQ outer join与motion问题讲解

作者

digoal

日期

2016-09-05

标签

PostgreSQL , HAWQ , Greenplum , OUTER JOIN , Motion


背景

Greenplum,HAWQ是分布式的数据库,在建表时,我们可以选择分布列,或者选择随机分布。

多个表做等值JOIN时,如果JOIN列为分布列,则不需要进行数据的重分布。

但是,如果使用的是OUTER JOIN,情况就不一样了,你可能会发现多个表进行outer join时,如果JOIN列都是HASH分布列,某些写法就可能导致需要重分布。

下面给大家分析一下原因。

创建几张测试表

其中tab1,tab2,tab3的bucketnum一致,分布列一致。

tab4,tab5,tab6的分布列与前面几张表一致,但是bucketnum不一致(所以显然HASH取模后的值也不一致)。

bucketnum默认是实体segments的6倍(意思是每台实体segment上跑6个虚拟segment),用户可以根据表的大小来调试,例如要发挥最大的计算能力,实际设置时可以设置为主机CPU核数的0.8,小表则建议设置为较小的值。

tab7与tab8为随机分布,对于随机分布的表,bucketnum设置会忽略,在实体segments之间随机分布(查看hdfs对应的文件也能看出端倪)。

postgres=# create table tab1(c1 int, c2 int, c3 text, c4 timestamp) with (bucketnum=6) distributed by(c1,c2);
postgres=# create table tab2(c1 int, c2 int, c3 text, c4 timestamp) with (bucketnum=6) distributed by(c1,c2);
postgres=# create table tab3(c1 int, c2 int, c3 text, c4 timestamp) with (bucketnum=6) distributed by(c1,c2);
postgres=# create table tab4(c1 int, c2 int, c3 text, c4 timestamp) with (bucketnum=10) distributed by(c1,c2);
postgres=# create table tab5(c1 int, c2 int, c3 text, c4 timestamp) with (bucketnum=12) distributed by(c1,c2);
postgres=# create table tab6(c1 int, c2 int, c3 text, c4 timestamp) with (bucketnum=3) distributed by(c1,c2);
postgres=# create table tab7(c1 int, c2 int, c3 text, c4 timestamp) with (bucketnum=3) distributed randomly;
postgres=# create table tab8(c1 int, c2 int, c3 text, c4 timestamp) with (bucketnum=6) distributed randomly;
postgres=# insert into tab7 select generate_series(1,1000000),generate_series(1,1000000),'test',now();
INSERT 0 1000000
postgres=# insert into tab8 select generate_series(1,1000000),generate_series(1,1000000),'test',now();
INSERT 0 1000000
postgres=# analyze tab7;
ANALYZE
postgres=# analyze tab8;
ANALYZE

下面开始几组测试,通过执行计划的motion node,观察query是否需要重分布,以及重分布那张表,重分布的键值是哪些。

测试1

HAWQ的hash分布取模值取决于bucket num,如果bucket num不一致,则JOIN时有一张表需要重分布

postgres=# explain select * from tab1 join tab6 on (tab1.c1=tab6.c1 and tab1.c2=tab6.c2);
                                              QUERY PLAN                                               
-------------------------------------------------------------------------------------------------------
 Gather Motion 6:1  (slice2; segments: 6)  (cost=0.00..862.00 rows=1 width=48)
   ->  Hash Join  (cost=0.00..862.00 rows=1 width=48)
         Hash Cond: tab1.c1 = tab6.c1 AND tab1.c2 = tab6.c2
         ->  Table Scan on tab1  (cost=0.00..431.00 rows=1 width=24)
         ->  Hash  (cost=431.00..431.00 rows=1 width=24)
               ->  Redistribute Motion 6:6  (slice1; segments: 6)  (cost=0.00..431.00 rows=1 width=24)    重分布tab6
                     Hash Key: tab6.c1, tab6.c2
                     ->  Table Scan on tab6  (cost=0.00..431.00 rows=1 width=24)
 Settings:  default_hash_table_bucket_number=6
 Optimizer status: PQO version 1.638
(10 rows)

测试2

如果JOIN的其中一个表为随机分布式,随机分布的表需要复制或按JOIN列进行重分布

postgres=# explain select * from tab6 join tab7 on (tab6.c1=tab7.c1 and tab6.c2=tab7.c2);
                                              QUERY PLAN                                               
-------------------------------------------------------------------------------------------------------
 Gather Motion 3:1  (slice2; segments: 3)  (cost=0.00..862.00 rows=1 width=48)
   ->  Hash Join  (cost=0.00..862.00 rows=1 width=48)
         Hash Cond: tab6.c1 = tab7.c1 AND tab6.c2 = tab7.c2
         ->  Table Scan on tab6  (cost=0.00..431.00 rows=1 width=24)
         ->  Hash  (cost=431.00..431.00 rows=1 width=24)
               ->  Redistribute Motion 3:3  (slice1; segments: 3)  (cost=0.00..431.00 rows=1 width=24)  重分布tab7
                     Hash Key: tab7.c1, tab7.c2
                     ->  Table Scan on tab7  (cost=0.00..431.00 rows=1 width=24)
 Settings:  default_hash_table_bucket_number=6
 Optimizer status: PQO version 1.638
(10 rows)

测试3

随机分布策略的表,在每个segment上只有一个bucket

postgres=# explain select count(*) from tab7;
                                     QUERY PLAN                                     
------------------------------------------------------------------------------------
 Aggregate  (cost=0.00..452.11 rows=1 width=8)
   ->  Gather Motion 1:1  (slice1; segments: 1)  (cost=0.00..452.11 rows=1 width=8)
         ->  Aggregate  (cost=0.00..452.11 rows=1 width=8)
               ->  Table Scan on tab7  (cost=0.00..450.25 rows=1000000 width=1)
 Settings:  default_hash_table_bucket_number=6
 Optimizer status: PQO version 1.638
(6 rows)

测试4

如果两个随机分布的表JOIN,数据需要在所有的实体segments(每个datanode对应一个实体segment)上按JOIN列重分布

postgres=# explain select * from tab8 join tab7 on (tab8.c1=tab7.c1 and tab8.c2=tab7.c2);
                                                 QUERY PLAN                                                  
-------------------------------------------------------------------------------------------------------------
 Gather Motion 1:1  (slice3; segments: 1)  (cost=0.00..2151.49 rows=10000 width=42)
   ->  Hash Join  (cost=0.00..2148.64 rows=10000 width=42)
         Hash Cond: tab8.c1 = tab7.c1 AND tab8.c2 = tab7.c2
         ->  Redistribute Motion 1:1  (slice1; segments: 1)  (cost=0.00..555.04 rows=1000000 width=21)  重分布tab8
               Hash Key: tab8.c1, tab8.c2
               ->  Table Scan on tab8  (cost=0.00..450.25 rows=1000000 width=21)
         ->  Hash  (cost=555.04..555.04 rows=1000000 width=21)
               ->  Redistribute Motion 1:1  (slice2; segments: 1)  (cost=0.00..555.04 rows=1000000 width=21)  重分布tab7
                     Hash Key: tab7.c1, tab7.c2
                     ->  Table Scan on tab7  (cost=0.00..450.25 rows=1000000 width=21)
 Settings:  default_hash_table_bucket_number=6
 Optimizer status: PQO version 1.638
(12 rows)

测试5

outer join,2张表的outer join,如果JOIN列就是分布列,不需要重分布

postgres=# explain select * from tab1 left join tab2 on (tab1.c1=tab2.c1 and tab1.c2=tab2.c2);
                                  QUERY PLAN                                   
-------------------------------------------------------------------------------
 Gather Motion 6:1  (slice1; segments: 6)  (cost=0.00..862.00 rows=2 width=48)
   ->  Hash Left Join  (cost=0.00..862.00 rows=1 width=48)
         Hash Cond: tab1.c1 = tab2.c1 AND tab1.c2 = tab2.c2
         ->  Table Scan on tab1  (cost=0.00..431.00 rows=1 width=24)
         ->  Hash  (cost=431.00..431.00 rows=1 width=24)
               ->  Table Scan on tab2  (cost=0.00..431.00 rows=1 width=24)
 Settings:  default_hash_table_bucket_number=6
 Optimizer status: PQO version 1.638
(8 rows)

测试6

outer join,3张表的outer join,需要注意JOIN的条件

1.
tab1与tab2 left join后,关联不上时tab2可能会返回一些NULL值

因此再次与tab3 join时,如果JOIN条件是tab2与tab3,则不能圈定在虚拟segment内完成tab2与tab3的JOIN,必须要对tab1与tab2的outer JOIN中间结果进行重分布,对齐tab3的分布策略,再进行JOIN。

但是实际上,并不需要重分布,因为null和null比较返回的还是null,所以null实际上不需要重分布到一起去JOIN,本条SQL,对于HAWQ的优化器来说,是有优化余地的。

postgres=# explain select * from tab1 left join tab2 on (tab1.c1=tab2.c1 and tab1.c2=tab2.c2) left join tab3 on (tab2.c1=tab3.c1 and tab2.c2=tab3.c2);
                                           QUERY PLAN                                            
-------------------------------------------------------------------------------------------------
 Gather Motion 6:1  (slice2; segments: 6)  (cost=0.00..1293.00 rows=3 width=72)
   ->  Hash Left Join  (cost=0.00..1293.00 rows=1 width=72)
         Hash Cond: tab2.c1 = tab3.c1 AND tab2.c2 = tab3.c2
         ->  Redistribute Motion 6:6  (slice1; segments: 6)  (cost=0.00..862.00 rows=1 width=48)
               Hash Key: tab2.c1, tab2.c2
               ->  Hash Left Join  (cost=0.00..862.00 rows=1 width=48)
                     Hash Cond: tab1.c1 = tab2.c1 AND tab1.c2 = tab2.c2
                     ->  Table Scan on tab1  (cost=0.00..431.00 rows=1 width=24)
                     ->  Hash  (cost=431.00..431.00 rows=1 width=24)
                           ->  Table Scan on tab2  (cost=0.00..431.00 rows=1 width=24)
         ->  Hash  (cost=431.00..431.00 rows=1 width=24)
               ->  Table Scan on tab3  (cost=0.00..431.00 rows=1 width=24)
 Settings:  default_hash_table_bucket_number=6
 Optimizer status: PQO version 1.638
(14 rows)

2.
这样的条件下,则不需要重分布,因为第一次LEFT JOIN后,TAB1不会产生空值,使用tab1再与tab3进行join也不需要重分布。

postgres=# explain select * from tab1 left join tab2 on (tab1.c1=tab2.c1 and tab1.c2=tab2.c2) left join tab3 on (tab1.c1=tab3.c1 and tab1.c2=tab3.c2);
                                   QUERY PLAN                                    
---------------------------------------------------------------------------------
 Gather Motion 6:1  (slice1; segments: 6)  (cost=0.00..1293.00 rows=3 width=72)
   ->  Hash Left Join  (cost=0.00..1293.00 rows=1 width=72)
         Hash Cond: tab1.c1 = tab3.c1 AND tab1.c2 = tab3.c2
         ->  Hash Left Join  (cost=0.00..862.00 rows=1 width=48)
               Hash Cond: tab1.c1 = tab2.c1 AND tab1.c2 = tab2.c2
               ->  Table Scan on tab1  (cost=0.00..431.00 rows=1 width=24)
               ->  Hash  (cost=431.00..431.00 rows=1 width=24)
                     ->  Table Scan on tab2  (cost=0.00..431.00 rows=1 width=24)
         ->  Hash  (cost=431.00..431.00 rows=1 width=24)
               ->  Table Scan on tab3  (cost=0.00..431.00 rows=1 width=24)
 Settings:  default_hash_table_bucket_number=6
 Optimizer status: PQO version 1.638
(12 rows)

3.
如果第三张关联表是JOIN条件,而非OUTER JOIN,同样不需要重分布。

postgres=# explain select * from tab1 left join tab2 on (tab1.c1=tab2.c1 and tab1.c2=tab2.c2) join tab3 on (tab2.c1=tab3.c1 and tab2.c2=tab3.c2);
                                               QUERY PLAN                                               
--------------------------------------------------------------------------------------------------------
 Gather Motion 6:1  (slice1; segments: 6)  (cost=0.00..1293.00 rows=1 width=72)
   ->  Hash Join  (cost=0.00..1293.00 rows=1 width=72)
         Hash Cond: tab2.c1 = tab3.c1 AND tab2.c2 = tab3.c2 AND tab1.c1 = tab3.c1 AND tab1.c2 = tab3.c2
         ->  Hash Join  (cost=0.00..862.00 rows=1 width=48)
               Hash Cond: tab1.c1 = tab2.c1 AND tab1.c2 = tab2.c2
               ->  Table Scan on tab1  (cost=0.00..431.00 rows=1 width=24)
               ->  Hash  (cost=431.00..431.00 rows=1 width=24)
                     ->  Table Scan on tab2  (cost=0.00..431.00 rows=1 width=24)
         ->  Hash  (cost=431.00..431.00 rows=1 width=24)
               ->  Table Scan on tab3  (cost=0.00..431.00 rows=1 width=24)
 Settings:  default_hash_table_bucket_number=6
 Optimizer status: PQO version 1.638
(12 rows)

4.
只有JOIN时,也不需要考虑重分布。

postgres=# explain select * from tab1 join tab2 on (tab1.c1=tab2.c1 and tab1.c2=tab2.c2) join tab3 on (tab2.c1=tab3.c1 and tab2.c2=tab3.c2);
                                               QUERY PLAN                                               
--------------------------------------------------------------------------------------------------------
 Gather Motion 6:1  (slice1; segments: 6)  (cost=0.00..1293.00 rows=1 width=72)
   ->  Hash Join  (cost=0.00..1293.00 rows=1 width=72)
         Hash Cond: tab2.c1 = tab3.c1 AND tab2.c2 = tab3.c2 AND tab1.c1 = tab3.c1 AND tab1.c2 = tab3.c2
         ->  Hash Join  (cost=0.00..862.00 rows=1 width=48)
               Hash Cond: tab1.c1 = tab2.c1 AND tab1.c2 = tab2.c2
               ->  Table Scan on tab1  (cost=0.00..431.00 rows=1 width=24)
               ->  Hash  (cost=431.00..431.00 rows=1 width=24)
                     ->  Table Scan on tab2  (cost=0.00..431.00 rows=1 width=24)
         ->  Hash  (cost=431.00..431.00 rows=1 width=24)
               ->  Table Scan on tab3  (cost=0.00..431.00 rows=1 width=24)
 Settings:  default_hash_table_bucket_number=6
 Optimizer status: PQO version 1.638
(12 rows)

小结

1. 随机分布的表与随机分布的表进行JOIN时,可能无法充分利用计算资源,因为每个物理节点只能用到一个核。
2. 随机分布的表与哈希分布的表JOIN时,会根据实际情况,重分布,并行计算。(如果哈希分布的表bucketnum较多,这种QUERY也能用上多核JOIN)。
3. outer join时,如果多次进行,请注意实际的场景逻辑,建议在JOIN时过滤,而不是JOIN完后过滤NULL,以避免重分布。

Count

相关实践学习
基于Redis实现在线游戏积分排行榜
本场景将介绍如何基于Redis数据库实现在线游戏中的游戏玩家积分排行榜功能。
目录
相关文章
|
存储 弹性计算 大数据
阿里云服务器怎么样?云服务器ECS功能、租用费用全解析
阿里云ECS是弹性计算服务,提供安全可靠的云服务器,包括多种实例规格如经济型、通用型、计算型等,适合不同场景。ECS支持VPC专有网络、快照与镜像、多种付费模式。用户可按需选择计算架构、存储类型,享受灵活的网络控制、自动化数据备份和低成本计算资源。适用于Web应用、在线游戏、大数据分析和深度学习等场景。阿里云提供免费试用和优惠价格,服务众多知名企业,如新浪微博。
399 5
|
8月前
|
JSON 供应链 搜索推荐
淘宝APP分类API接口:开发、运用与收益全解析
淘宝APP作为国内领先的购物平台,拥有丰富的商品资源和庞大的用户群体。分类API接口是实现商品分类管理、查询及个性化推荐的关键工具。通过开发和使用该接口,商家可以构建分类树、进行商品查询与搜索、提供个性化推荐,从而提高销售额、增加商品曝光、提升用户体验并降低运营成本。此外,它还能帮助拓展业务范围,满足用户的多样化需求,推动电商业务的发展和创新。
234 5
|
开发工具 数据安全/隐私保护 索引
LDAP学习笔记之二:389-DS(RHDS) 增删改查基本操作
LDAP学习笔记之二:389-DS(RHDS) 增删改查基本操作
|
Web App开发 资源调度 前端开发
electron 中如何安装或更新 vuejs-devtool 最新稳定版
electron 中如何安装或更新 vuejs-devtool 最新稳定版
|
数据可视化 算法 PyTorch
贝叶斯优化实战(一)(3)
贝叶斯优化实战(一)
322 2
|
监控 Linux Shell
|
网络协议 网络性能优化 定位技术
ip呼叫是什么意思?
ip呼叫是什么意思?
|
JavaScript 安全 开发工具
​Vue 应用程序性能优化:代码压缩、加密和混淆配置详解
简介在 Vue 应用程序的开发中,代码压缩、加密和混淆是优化应用程序性能和提高安全性的重要步骤。 Vue CLI 是一个功能强大的开发工具,它提供了方便的配置选项来实现这些功能。本文将介绍如何使用 Vue CLI 配置代码压缩、加密和混淆功能,以提高应用程序的性能和安全性。
|
Java 索引
深入浅出JVM(五)之Java中方法调用
深入浅出JVM(五)之Java中方法调用
|
机器学习/深度学习 测试技术
LLM-Blender:大语言模型也可以进行集成学习
最近在看arxiv的时候发现了一个有意思的框架:LLM-Blender,它可以使用Ensemble 的方法来对大语言模型进行集成。
528 0