Greenplum MPP 架构

2023-11-27 14:13:49 浏览数 (2)

1.Greenplum MPP架构

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

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

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

1.1.Greenplum Master

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

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

1.2.Segment

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

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

1.3.Interconnect

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

2.集群配置

master host 主机为 X4200,standby master主机为X4500，使用 e1000g4 和 e1000g5 网口建立本地网络为外部提供服务。

Segment host 1 主机为 X4500,standby host 2 主机为X4500，使用 e1000g1，e1000g2，e1000g3 和 e1000g4 网口在不同的 VLAN 中建立网络链接以保证单主机上建立多个Segment 。

每台主机使用ilom 链接到私有网络中进行服务器的主机的管理。

2.1.Greenplum 高可用性架构

Master节点和standby备用节点通过synch process来保证主备数据库的一致行；数据节点 segement 存在mirrio（一般存储在临近服务器上）。

2.2.Master/Standby 镜像保护

Standby 节点用于当 Master 节点损坏时提供 Master 服务 Standby 实时与 Master 节点的 Catalog 和事务日志保持同步

在一个高可用集群中，有两种master实例，primary和standby。像segment一样，master和standby 应该部署在不同的主机上，以保证集群不出现单节点故障问题。客户端只能连接到primary master并在上面执行查询。standby master采用基于预写日志（WAL）流复制的方式保持与primary master的数据一致。

如果master故障了，管理员可以通过运行gpactivatestandby工具切换standby master成为 新的primary master。可以通过在master和standby上配置一个虚拟IP地址来保证当发生切换后，客户端不需要在不同的网址之间切换。如果master主机故障，虚拟IP可以漂移到新的活动master节点上继续提供服务。

Master mirror 服务的使用:

  1. 创建一个standby master host
  2. 切换
  3. 激活master

2.3.数据冗余-Segment 镜像保护

每个Segment的数据冗余存放在另一个Segment上，数据实时同步 当Primary Segment失败时，Mirror Segment将自动提供服务 Primary Segment 恢复正常后，使用 “gprecoverseg –F” 同步数据。

Greenplum数据库将数据存储在多个segment实例中，每一个实例都是Greenplum数据库的一个PostgreSQL实例，数据依据建表语句中定义的分布策略在segment节点中分布。启用segment镜像时，每个segment实例都由一对 primary和mirror*组成。镜像segment采用基于预写日志（WAL）流复制的方式保持与主segment 的数据一致。 镜像实例通常采用gpinitsystem或gpexpand工具进行初始化。作为最佳实践，为了保证单机失败镜像通常运行在与主segment不同的主机上。将镜像分配到不同的主机上也有不同的策略。当搭配镜像和主segment的放置位置时，要充分考虑单机失败发生时处理倾斜最小化的场景。

2.4.主机硬件配置

  • Master 节点
  1. 网卡 1、2块万兆网卡内部互联 2、1-2块千兆网卡带外管理及接入客户网络
  2. 内存 DDR4 64GB以上，建议256G
  3. 磁盘 1、6块600G/900G 10k RPM SAS盘 2、采用RAID5或RAID10 3、单独预留hotspare 盘
  4. 1块RAID卡，cache 1GB以上，带有掉电保护功能
  5. CPU 1、2路8核及以上 2、主频2.5G HZ以上
  • Segment 节点
  1. 网卡 1、2块万兆网卡内部互联 2、1-2块千兆网卡带外管理及接入客户网络
  2. 内存 DDR4 64GB以上，建议256G
  3. 磁盘 1、24块600G/900G 10k RPM SAS盘 2、采用RAID5或RAID10 3、单独预留hotspare 盘 4、1-2块RAID卡，cache 1GB以上，带有掉电保护功能
  4. CPU 1、2路8核及以上 2、主频2.5G HZ以上

2.5.存储评估

计算可用的空间

步骤1：初始存储能力=硬盘大小硬盘数 步骤2：配置RAID10，格式化磁盘空间=(初始存储能力0.9)/2 步骤3：可用磁盘空间=格式化磁盘空间0.7 ；保留 0.3 个百分比的空间，以保数据存储可以空间 步骤4：用户数据使用空间 使用镜像：(2用户数据) 用户数据/3=可用磁盘空间 不使用镜像：用户数据 用户数据/3=可用磁盘空间

计算用户数据大小：

平均来说，实际占用磁盘空间大小=用户数据*1.4，其中 0.4 个百分比的数据如下：

  • 页面开销：32KB页面需要 20 bytes
  • 行开销：每行 24 bytes，’append-only’表需要 4 bytes
  • 索引开销： B-tree:唯一值*(数据类型大小 24 bytes) Bitmap:(唯一值行数1bit压缩比率/8) (唯一值32)

为元数据和日志计算空间需求

  • 系统元数据：20M
  • 预写日志(WAL)：WAL被拆分成多个64M的文件，WAL文件数最多为2*checkpoint_segments 1，checkpoint_segments默认值为8。也就意味着每个实例需要1088MB的WAL空间
  • GP数据库日志文件：日志轮转
  • 性能监控数据

2.6.网络冗余

2.7.部署方案

  1. Group Mirroring 部署方案

Group mirroring是最容易设置的镜像配置，并且是Greenplum的默认镜像配置。组镜像的扩展代价最低，因为 可以通过增加仅仅两台主机来完成扩展。在扩展之后无需移动镜像来维持镜像配置的一致性。

下面的图显示了一个在四台主机上带有八个主segment的group mirroring配置。

除非同一个segment实例的主segment和镜像都出现故障，最多可以有一半的主机故障并且集群将继续运行，只要 资源（CPU、内存和IO）足以满足需求。

任何主机故障将会让性能退化一半以上，因为具有镜像的主机将承担两倍的活动主segment。如果用户的资源利用 通常会超过50%，用户将不得不调整其负载，直至故障主机被恢复或者替换。如果用户通常的资源利用低于50%，则 集群会继续以退化的性能水平运行，直至故障被修复。

按照以下4台机器Group Mirroring的部署方案总结 缺点: 一台机器down掉后，会把流量全部放在下一个节点，下一个节点的流量会变成2倍的流量 优点: down掉一台机器后，集群能正常的提供服务,如果再down掉第二台集群就不可用

  1. Spread Mirroring 部署方案 通过spread mirroring，每台主机的主要Segment的镜像被散布在若干台主机上，涉及到的主机数量与每台主机上 segment数量相同。在集群初始化时设置spread mirroring很容易，但是要求集群中的主机数至少为每台主机上的 segment数加一。

下面的图展示了一个在四台主机上有三个主segment的集群的spread mirroring配置。

扩展使用spread mirroring的集群要求更多的规划并且可能会花费更多时间。用户必须要么增加一组数量等于每台 主机上主segment数加一的主机，要么在group mirroring配置中增加两个节点并且在扩展完成后移动镜像来重建 spread mirror配置。

对于单主机故障，spread mirroring的性能影响最小，因为每台主机的镜像都散布在多台主机上。负载的增加是 1/Nth，其中N是每台主机上主segment的数量。如果两台以上主机同时故障，spread mirroring 是最有可能遭受到灾难性故障的配置方案。

按照以下4台机器Spread Mirroring的部署方案总结 缺点: 一台机器down掉后，会把流量全部放在下两个节点 优点: down掉一台机器后，集群能正常的提供服务,如果再down掉第二台集群就不可用

3.Block Mirroring 对于block mirroring，节点被划分成块，例如具有四台或者八台主机的块，而每台主机上segment的镜像被放置在 块中的其他主机上。根据块中主机的数量以及每台主机上主segment的数量，每台主机会为其他每一台主机的segment 维护超过一个镜像。

下面的图展示了单block mirroring配置，块中有四台主机，每台主机有八个主segment：

如果有八台主机，则额外增加的一个四主机块中有32至63号主segment的镜像，其设置也是同样的模式。

使用block mirroring的集群很容易扩展，因为每一个块都是一个自包含的主镜像组。集群可以通过增加一个或者多个 块来扩展。扩展之后无需移动镜像来维持镜像设置的一致。只要故障的主机处于不同的块中，这种配置就能够容忍多主机 故障。

因为块中的每台主机都有块中其他每台主机的多个镜像实例，对于主机故障block mirroring的性能影响比spread mirroring更大，但比group mirroring影响要小。预期的性能影响随着块尺寸和每节点主segment数变化。和group mirroring类似，如果资源可用，性能将会受到负面的影响，但是集群仍将可用。如果资源不足以容纳增加的负载，用户 必须降低负载直至故障节点被替换。

实现Block Mirroring 在用户设置或者扩展集群时，block mirroring并非Greenplum数据库提供的一种自动选项。要使用block mirroring， 用户必须创建自己的配置。

对于一个新的Greenplum系统，用户可以把集群初始化为没有镜像，然后用一个自定义镜像配置文件运行 gpaddmirrors -i mirror_config_file来为每一个块创建镜像。在用户运行gpaddmirrors之前，用户必须为镜像segment创建文件系统位置。详见Greenplum 数据库管理工具指南中的gpaddmirrors参考页。

如果用户扩展一个有block mirroring的系统或者用户想要在扩展集群时实现block mirroring，推荐用户先用默认的 grouping mirror配置完成扩展，然后使用gpmovemirrors工具把镜像移到块配置中。

要在使用不同镜像方案的现有系统中实现block mirroring，用户必须首先根据其块配置确定每个镜像的位置，然后确定 哪些现有的镜像必须被重定位。按照下列步骤：

step 1.运行下列查询来查找主segment和镜像segment的当前位置：

代码语言：javascript复制
SELECT dbid, content, role, port, hostname, datadir FROM gp_segment_configuration WHERE content > -1 ;

The gp_segment_configuration系统目录表包含当前的segment配置。

step 2.用当前镜像位置和想要的block mirroring位置创建一个列表，然后从中移除已经在正确主机上的镜像。 step 3.用列表中必须要移动的每一个项（镜像）为gpmovemirrors工具创建一个输入文件。 gpmovemirrors输入文件的格式如下：

代码语言：javascript复制
contentID:address:port:data_dir new_address:port:data_dir

Where contentID 是segment实例的contentID， address是对应主机的主机名或IP地址， port是通信端口，data_dir是segment实例的数据目录

下面的gpmovemirrors输入文件定义了三个需要移动的镜像segment。

代码语言：javascript复制
1:sdw2:50001:/data2/mirror/gpseg1 sdw3:50001:/data/mirror/gpseg1
2:sdw2:50001:/data2/mirror/gpseg2 sdw4:50001:/data/mirror/gpseg2
3:sdw3:50001:/data2/mirror/gpseg3 sdw1:50001:/data/mirror/gpseg3

step 4.用以下命令运行gpmovemirrors：

代码语言：javascript复制
gpmovemirrors -i mirror_config_file

gpmovemirrors工具会验证该输入文件、调用gp_recoverseg 来重定位每一个指定的镜像，并且移除原始的镜像。它会创建一个撤销配置文件，该文件可以被用作 gpmovemirrors的输入来撤销所作的更改。撤销文件和输入文件同名，但会增加后缀 _backout_timestamp。

greenplum 架构 镜像 数据 主机

0 人点赞