大数据引擎 Greenplum 那些事

https://blog.csdn.net/weixin_38113732/article/details/106537437

社会我857 2020-06-04 07:27:29 190 已收藏 3
版权

程序员杂志-大数据技术深度实践
随着技术迭代的不断加速，大数据极大改变了行业领域对信息流动的限制。本期我们聚焦2017年领域内热门技术与应用实践，带领大家深度解析大数据技术难点和发展趋势。厉兵秣马今点将，群雄逐鹿正当时。
社会我857
¥9.90
订阅专栏
本文介绍了大数据引擎 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为 GPD B 的基本架构，客户端通过网络连接到 gpdb，其中 Master Host 是 GP 的主节点（客户端的接入点），Segment Host 是子节点（连接并提交 SQL 语句的接口），主节点不存储用户数据，子节点存储数据并负责 SQL 查询，主节点负责相应客户端请求并将请求的 SQL 语句进行转换，转换之后调度后台的子节点进行查询，并将查询结果返回客户端。

图1 GPDB 的基本架构
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 中参数的设置是否符合要求，如果对参数的含义感兴趣，可以自行搜索学习。

[gpadmin@gzns-waimai-do-hadoop280 greenplum]$ gpcheck —host mdw
variable not detected in /etc/sysctl.conf: ‘net.ipv4.tcp_max_syn_backlog’
variable not detected in /etc/sysctl.conf: ‘kernel.sem’
variable not detected in /etc/sysctl.conf: ‘net.ipv4.conf.all.arp_filter’
/etc/sysctl.conf value for key ‘kernel.shmall’ has value ‘4294967296’ and expects ‘4000000000’
variable not detected in /etc/sysctl.conf: ‘net.core.netdev_max_backlog’
/etc/sysctl.conf value for key ‘kernel.sysrq’ has value ‘0’ and expects ‘1’
variable not detected in /etc/sysctl.conf: ‘kernel.shmmni’
variable not detected in /etc/sysctl.conf: ‘kernel.msgmni’
/etc/sysctl.conf value for key ‘net.ipv4.ip_local_port_range’ has value ‘10000 65535’ and expects ‘1025 65535’
variable not detected in /etc/sysctl.conf: ‘net.ipv4.tcp_tw_recycle’
hard nproc not found in /etc/security/limits.conf
soft nproc not found in /etc/security/limits.conf
1
2
3
4
5
6
7
8
9
10
11
12
13
另外在安装过程中，用其提供的 gpssh-exkeys 命令打通所有机器免密登录后，可以很方便地使用 gpassh 命令对所有的机器批量操作，如下演示了在 master 主机上执行 gpssh 命令后，在集群的五台机器上批量执行 pwd 命令。

[gpadmin@gzns-waimai-do-hadoop280 greenplum]$ gpssh -f hostlist
=> pwd
[sdw3] /home/gpadmin
[sdw4] /home/gpadmin
[sdw5] /home/gpadmin
[ mdw] /home/gpadmin
[sdw2] /home/gpadmin
[sdw1] /home/gpadmin
=>
1
2
3
4
5
6
7
8
9
诸如上述的工具 GPDB 还提供了很多，比如恢复 segment 节点的 gprecoverseg 命令，比如切换主备节点的 gpactivatestandby 命令等。这类工具让集群的维护变得很简单，当然我们也可以基于强大的工具包开发自己的管理后台，让集群的维护更加傻瓜化。

查询计划和并行执行，SQL 优化利器
查询计划包括了一些传统的操作，比如扫表、关联、聚合、排序等。另外，GPDB 有一个特定的操作：移动（motion）。移动操作涉及到查询处理期间在 Segment 之间移动的数据。

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

explain select
o_orderdate,
o_shippriority
from
customer,
orders
where
c_mktsegment = ‘MACHINERY’
and c_custkey = o_custkey
and o_orderdate < date ‘1995-03-20’
LIMIT 10;
QUERY PLAN
—————————————————-
Limit (cost=98132.28..98134.63 rows=10 width=8)
-> Gather Motion 10:1 (slice2; segments: 10) (cost=98132.28..98134.63 rows=10 width=8)
-> Limit (cost=98132.28..98134.43 rows=1 width=8)
-> Hash Join (cost=98132.28..408214.09 rows=144469 width=8)
Hash Cond: orders.o_custkey = customer.c_custkey
-> Append-only Columnar Scan on orders (cost=0.00..241730.00 rows=711519 width=16)
Filter: o_orderdate < ‘1995-03-20’::date
-> Hash (cost=60061.92..60061.92 rows=304563 width=8)
-> Broadcast Motion 10:10 (slice1; segments: 10) (cost=0.00..60061.92 rows=304563 width=8)
-> Append-only Columnar Scan on customer (cost=0.00..26560.00 rows=30457 width=8) Filter: c_mktsegment = ‘MACHINERY’::bpchar
Settings: enable_nestloop=off
Optimizer status: legacy query optimizer
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
执行计划从下至上执行，可以看到每个计划节点操作的额外信息。

Segment 节点扫描各自所存储的 customer 表数据，按照过滤条件生成结果数据，并将自己生成的结果数据依次发送到其他 Segment；
每个 Segment 上，orders 表的数据和收到的 rs 做 join，并把结果数据返回给 master。
上面的执行过程可以看出，GPDB 将结果数据给每个含有 orders 表数据的节点都发了一份。为了最大限度地实现并行化处理，GPDB 会将查询计划分成多个处理步骤。在查询执行期间，分发到 Segment 上的各部分会并行地执行一系列处理工作，并且只处理属于自己部分的工作。重要的是，可以在同一个主机上启动多个 postgresql 数据库进行更多表的关联以及更复杂的查询操作，单台机器的性能得到更加充分的发挥。

如何查看执行计划

如果一个查询表现出很差的性能，可以通过查看执行计划找到可能的问题点。

计划中是否有一个操作花费时间超长；
规划期的评估是否接近实际情况；
选择性强的条件是否较早出现；
规划期是否选择了最佳的关联顺序；
规划其是否选择性的扫描分区表；
规划其是否合适地选择了 Hash 聚合与 Hash 关联操作。
高效的数据导入，批量不再是瓶颈
前面提到，Greenplum 的 Master 节点只负责客户端交互和其他一些必要的控制，而不承担任何的计算任务。在加载数据的时候，会先进行数据分布的处理工作，为每个表指定一个分发列，接下来所有的节点同时读取数据，根据选定的 Hash 算法，将当前节点数据留下，其他数据通过 interconnect 传输到其他节点上去，保证了高性能的数据导入。通过结合外部表和 gpfdist 服务，GPDB 可以做到每小时导入 2TB 数据，在不改变 ETL 流程的情况下，可以从 impala 快速导入计算好的数据为消费提供服务。

使用 gpfdist 的优势在于其可以确保再度去外部表的文件时，GPDB 系统的所有 Segment 可以完全被利用起来，但是需要确保所有 Segment 主机可以具有访问 gpfdist 的网络。

其他
GPDB 支持 LDAP 认证，这一特性的支持，让我们可以把目前 Impala 的角色权限控制无缝迁移到 GPDB；
GPDB 基于 Postgresql 8.2 开发，通过 psql 命令行工具可以访问 GPDB 数据库的所有功能，另外支持 JDBC、ODBC 等访问方式，产品接口层只需要进行少量的适配即可使用 GPDB 提供服务；
GPDB 支持基于资源队列的管理，可以为不同类型工作负载创建资源独立的队列，并且有效地控制用户的查询以避免系统超负荷运行。比如，可以为 VIP 用户、ETL 生产、任性和 adhoc 等创建不同的资源队列。同时支持优先级的设置，在并发争用资源时，高优先级队列的语句将可以获得比低优先级资源队列语句更多的资源。
最近在对 GPDB 做调研和测试，过程中用 TPCH 做性能的测试。通过和网络上其他服务的对比发现在5个节点的情况下已经有了很高的查询速度，但是由于测试环境服务器问题，具体的性能数据还要在接下来的新环境中得出，不过 GPDB 基于 postgresql 开发，天生支持丰富的统计函数，支持横向的线性扩展，内部容错机制，有很多功能强大的运维管理命令和代码。相比 impala 而言，显然在 SQL 的支持、实时性和稳定性上更胜一筹。

本文只是对 Greenplum 的初窥，接下来更深入的剖析以及在工作中的实践经验分享也请关注 DA 的 wiki。更多关于 Greenplum 基本的语法和特性，也可以参考 PostgreSQL 的官方文档。
————————————————
版权声明：本文为CSDN博主「社会我857」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/weixin_38113732/article/details/106537437