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

本文涉及的产品
云原生数据库 PolarDB PostgreSQL 版,标准版 2核4GB 50GB
云原生大数据计算服务 MaxCompute,5000CU*H 100GB 3个月
云原生数据库 PolarDB MySQL 版,通用型 2核8GB 50GB
简介:

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节点的高可用(图2),类似于Hadoop的NameNode HA,如下图,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网络层InterconnectGreenplum,新的解决方案

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

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

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

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

  (点击可查看高清版)

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

  (点击可查看高清版)

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

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

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

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

  (点击可查看高清版)

执行计划执行从下至上,可以看到每个计划节点操作的额外信息。

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的官方文档。

本文转自d1net(转载)

相关实践学习
基于MaxCompute的热门话题分析
本实验围绕社交用户发布的文章做了详尽的分析,通过分析能得到用户群体年龄分布,性别分布,地理位置分布,以及热门话题的热度。
SaaS 模式云数据仓库必修课
本课程由阿里云开发者社区和阿里云大数据团队共同出品,是SaaS模式云原生数据仓库领导者MaxCompute核心课程。本课程由阿里云资深产品和技术专家们从概念到方法,从场景到实践,体系化的将阿里巴巴飞天大数据平台10多年的经过验证的方法与实践深入浅出的讲给开发者们。帮助大数据开发者快速了解并掌握SaaS模式的云原生的数据仓库,助力开发者学习了解先进的技术栈,并能在实际业务中敏捷的进行大数据分析,赋能企业业务。 通过本课程可以了解SaaS模式云原生数据仓库领导者MaxCompute核心功能及典型适用场景,可应用MaxCompute实现数仓搭建,快速进行大数据分析。适合大数据工程师、大数据分析师 大量数据需要处理、存储和管理,需要搭建数据仓库?学它! 没有足够人员和经验来运维大数据平台,不想自建IDC买机器,需要免运维的大数据平台?会SQL就等于会大数据?学它! 想知道大数据用得对不对,想用更少的钱得到持续演进的数仓能力?获得极致弹性的计算资源和更好的性能,以及持续保护数据安全的生产环境?学它! 想要获得灵活的分析能力,快速洞察数据规律特征?想要兼得数据湖的灵活性与数据仓库的成长性?学它! 出品人:阿里云大数据产品及研发团队专家 产品 MaxCompute 官网 https://www.aliyun.com/product/odps 
目录
相关文章
|
3月前
|
运维 监控 负载均衡
动态服务管理平台:驱动微服务架构的高效引擎
动态服务管理平台:驱动微服务架构的高效引擎
57 17
|
3月前
|
大数据
【赵渝强老师】大数据主从架构的单点故障
大数据体系架构中,核心组件采用主从架构,存在单点故障问题。为提高系统可用性,需实现高可用(HA)架构,通常借助ZooKeeper来实现。ZooKeeper提供配置维护、分布式同步等功能,确保集群稳定运行。下图展示了基于ZooKeeper的HDFS HA架构。
|
24天前
|
开发框架 前端开发 .NET
一个适用于 .NET 的开源整洁架构项目模板
一个适用于 .NET 的开源整洁架构项目模板
54 26
|
2月前
|
人工智能 自然语言处理
RWKV-7:RWKV系列开源最新的大模型架构,具有强大的上下文学习能力,超越传统的Attention范式
RWKV-7是RWKV系列的最新大模型架构版本,具有强大的上下文学习能力,超越了传统的attention和linear attention范式。本文详细介绍了RWKV-7的主要功能、技术原理及其在多语言处理、文本生成等领域的应用场景。
163 7
RWKV-7:RWKV系列开源最新的大模型架构,具有强大的上下文学习能力,超越传统的Attention范式
|
2月前
|
存储 SQL 分布式计算
大数据时代的引擎:大数据架构随记
大数据架构通常分为四层:数据采集层、数据存储层、数据计算层和数据应用层。数据采集层负责从各种源采集、清洗和转换数据,常用技术包括Flume、Sqoop和Logstash+Filebeat。数据存储层管理数据的持久性和组织,常用技术有Hadoop HDFS、HBase和Elasticsearch。数据计算层处理大规模数据集,支持离线和在线计算,如Spark SQL、Flink等。数据应用层将结果可视化或提供给第三方应用,常用工具为Tableau、Zeppelin和Superset。
531 8
|
3月前
|
SQL 数据采集 分布式计算
【赵渝强老师】基于大数据组件的平台架构
本文介绍了大数据平台的总体架构及各层的功能。大数据平台架构分为五层:数据源层、数据采集层、大数据平台层、数据仓库层和应用层。其中,大数据平台层为核心,负责数据的存储和计算,支持离线和实时数据处理。数据仓库层则基于大数据平台构建数据模型,应用层则利用这些模型实现具体的应用场景。文中还提供了Lambda和Kappa架构的视频讲解。
360 3
【赵渝强老师】基于大数据组件的平台架构
|
2月前
|
存储 负载均衡 监控
揭秘 Elasticsearch 集群架构,解锁大数据处理神器
Elasticsearch 是一个强大的分布式搜索和分析引擎,广泛应用于大数据处理、实时搜索和分析。本文深入探讨了 Elasticsearch 集群的架构和特性,包括高可用性和负载均衡,以及主节点、数据节点、协调节点和 Ingest 节点的角色和功能。
65 0
|
2月前
|
弹性计算 API 持续交付
后端服务架构的微服务化转型
本文旨在探讨后端服务从单体架构向微服务架构转型的过程,分析微服务架构的优势和面临的挑战。文章首先介绍单体架构的局限性,然后详细阐述微服务架构的核心概念及其在现代软件开发中的应用。通过对比两种架构,指出微服务化转型的必要性和实施策略。最后,讨论了微服务架构实施过程中可能遇到的问题及解决方案。
|
3月前
|
Cloud Native Devops 云计算
云计算的未来:云原生架构与微服务的革命####
【10月更文挑战第21天】 随着企业数字化转型的加速,云原生技术正迅速成为IT行业的新宠。本文深入探讨了云原生架构的核心理念、关键技术如容器化和微服务的优势,以及如何通过这些技术实现高效、灵活且可扩展的现代应用开发。我们将揭示云原生如何重塑软件开发流程,提升业务敏捷性,并探索其对企业IT架构的深远影响。 ####
76 3
|
3月前
|
Cloud Native 安全 数据安全/隐私保护
云原生架构下的微服务治理与挑战####
随着云计算技术的飞速发展,云原生架构以其高效、灵活、可扩展的特性成为现代企业IT架构的首选。本文聚焦于云原生环境下的微服务治理问题,探讨其在促进业务敏捷性的同时所面临的挑战及应对策略。通过分析微服务拆分、服务间通信、故障隔离与恢复等关键环节,本文旨在为读者提供一个关于如何在云原生环境中有效实施微服务治理的全面视角,助力企业在数字化转型的道路上稳健前行。 ####