详解开源大数据引擎Greenplum的架构和技术特点

2023-03-27 00:00:00 查询 数据 多个 执行 节点

本文介绍了大数据引擎Greenplum的架构和部分技术特点。从GPDB基本背景开始,在架构的层面上讲解GPDB系统内部各个模块的概貌,然后围绕GPDB的自身特性、并行执行和运维等技术细节,阐述了为什么选择Greenplum作为下一代的查询引擎解决方案。

Greenplum的MPP架构

Greenplum(以下简称GPDB)是一款开源数据仓库,基于开源的PostgreSQL改造而来,主要用来处理大规模数据分析任务。相比Hadoop,Greenplum更适合做大数据的存储、计算和分析引擎。

GPDB是典型的Master/Slave架构,在Greenplum集群中,存在一个Master节点和多个Segment节点,每个节点上可以运行多个数据库。Greenplum采用shared nothing架构(MPP),典型的Shared Nothing系统汇集了数据库、内存Cache等存储状态的信息,不在节点上保存状态的信息。节点之间的信息交互都是通过节点互联网络实现的。通过将数据分布到多个节点上来实现规模数据的存储,再通过并行查询处理来提高查询性能。每个节点仅查询自己的数据,所得到的结果再经过主节点处理得到终结果。通过增加节点数目达到系统线性扩展。

图1 GPDB的基本架构

图1为GPDB的基本架构,客户端通过网络连接到gpdb,其中Master Host是GP的主节点(客户端的接入点),Segment Host是子节点(连接并提交SQL语句的接口),主节点不存储用户数据,子节点存储数据并负责SQL查询,主节点负责相应客户端请求并将请求的SQL语句进行转换,转换之后调度后台的子节点进行查询,并将查询结果返回客户端。

Greenplum Master

Master只存储系统元数据,业务数据全部分布在Segments上。其作为整个数据库系统的入口,负责建立与客户端的连接,SQL的解析并形成执行计划,分发任务给Segment实例,并且收集Segment的执行结果。正因为Master不负责计算,所以Master不会成为系统的瓶颈。

Master节点的高可用类似Hadoop的NameNode HA,如图2,Standby Master通过synchronization process,保持与Primary Master的catalog和事务日志一致,当Primary Master出现故障时,Standby Master承担Master的全部工作。

图2 Master节点的高可用

Segments

Greenplum中可以存在多个Segment,Segment主要负责业务数据的存储和存取(图3),用户查询SQL的执行时,每个Segment会存放一部分用户数据,但是用户不能直接访问Segment,所有对Segment的访问都必须经过Master。进行数据访问时,所有的Segment先并行处理与自己有关的数据,如果需要关联处理其他Segment上的数据,Segment可以通过Interconnect进行数据的传输。Segment节点越多,数据就会打的越散,处理速度就越快。因此与Share All数据库集群不同,通过增加Segment节点服务器的数量,Greenplum的性能会成线性增长。

图3 Segment负责业务数据的存取

每个Segment的数据冗余存放在另一个Segment上,数据实时同步,当Primary Segment失效时,Mirror Segment将自动提供服务。当Primary Segment恢复正常后,可以很方便地使用gprecoverseg -F工具来同步数据。

Interconnect

Interconnect是Greenplum架构中的网络层(图4),也是GPDB系统的主要组件,它默认使用UDP协议,但是Greenplum会对数据包进行校验,因此可靠性等同于TCP,但是性能上会更好。在使用TCP协议的情况下,Segment的实例不能超过1000,但是使用UDP则没有这个限制。

图4 Greenplum网络层Interconnect

Greenplum,新的解决方案

前面介绍了GPDB的基本架构,让读者对GPDB有了初步了解。下面对GPDB的部分特性进行了描述,可以很好地理解为什么选择GPDB作为新的解决方案。

丰富的工具包,运维从此不是事儿

对比开源社区中其他项目在运维上面临的困难,GPDB提供了丰富的管理工具和图形化的web监控页面,帮助管理员更好地管理集群,监控集群本身以及所在服务器的运行状况。

近的公有云集群迁移过程中,impala总查询段达到100的时候,系统开始变得极不稳定,后来在外援的帮助下发现是系统内核本身的问题,在恶补系统内核参数的同时,发现GPDB的工具也变相填充了我们的短板,比如提供了gpcheck和gpcheckperf等命令,用于检测GPDB运行所需的系统配置是否合理以及对相关硬件做性能测试。如下,执行gpcheck命令后,检测sysctl.conf中参数的设置是否符合要求,如果对参数的含义感兴趣,可以自行搜索学习。

1.  [gpadmin@gzns-waimai-do-hadoop28 greenplum]$ gpcheck --host mdw
2. variable not detected in /etc/sysctl.conf: 'net.ipv4.tcp_max_syn_backlog'
3. variable not detected in /etc/sysctl.conf: 'kernel.sem'
4. variable not detected in /etc/sysctl.conf: 'net.ipv4.conf.all.arp_filter'
5. /etc/sysctl.conf value for key 'kernel.shmall' has value '4294967296' and expects '4000000000'
6. variable not detected in /etc/sysctl.conf: 'net.core.netdev_max_backlog'
7. /etc/sysctl.conf value for key 'kernel.sysrq' has value '0' and expects '1'
8. variable not detected in /etc/sysctl.conf: 'kernel.shmmni'
9. variable not detected in /etc/sysctl.conf: 'kernel.msgmni'
10. /etc/sysctl.conf value for key 'net.ipv4.ip_local_port_range' has value '10000 65535' and expects '1025 65535'
11. variable not detected in /etc/sysctl.conf: 'net.ipv4.tcp_tw_recycle'
12. hard nproc not found in /etc/security/limits.conf
13. soft nproc not found in /etc/security/limits.conf


另外在安装过程中,用其提供的gpssh-exkeys命令打通所有机器免密登录后,可以很方便地使用gpassh命令对所有的机器批量操作,如下演示了在master主机上执行gpssh命令后,在集群的五台机器上批量执行pwd命令。

1.  [gpadmin@gzns-waimai-do-hadoop280 greenplum]$ gpssh -f hostlist 
2. => pwd
3. [sdw3] /home/gpadmin
4. [sdw4] /home/gpadmin
5. [sdw5] /home/gpadmin
6. [ mdw] /home/gpadmin
7. [sdw2] /home/gpadmin
8. [sdw1] /home/gpadmin
9. =>



诸如上述的工具GPDB还提供了很多,比如恢复segment节点的gprecoverseg命令,比如切换主备节点的gpactivatestandby命令等。这类工具让集群的维护变得很简单,当然我们也可以基于强大的工具包开发自己的管理后台,让集群的维护更加傻瓜化。

查询计划和并行执行,SQL优化利器

查询计划包括了一些传统的操作,比如扫表、关联、聚合、排序等。另外,GPDB有一个特定的操作:移动(motion)。移动操作涉及到查询处理期间在Segment之间移动的数据。

下面的SQL是TPCH中Query 1的简化版,用来简单描述查询计划。

  1. 相关文章