作者：周雷皓，百度外卖大数据工程师。
来自：《程序员》月技术板原创投稿。
摘要：本文介绍了大数据引擎Grnplum的架构和部分技术特点，从GPDB基本背景开始，在架构的层面上讲解GPDB系统内部各个模块的概貌，然后围绕GPDB的自身特性，并行执行和运维等技术细节，阐述了为什么选择使用Grnplum作为下一代的查询引擎解决方案。
Grnplum的MPP架构Grnplum（以下简称GPDB）是一款开源数据仓库。基于开源的PostgrSQL改造，主要用来处理大规模数据分析任务，相比Hadoop，Grnplum更适合做大数据的存储、计算和分析引擎。
GPDB是典型的Mastr/Slav架构，在Grnplum集群中，存在一个Mastr节点和多个Sgmnt节点，其中每个节点上可以运行多个数据库。Grnplum采用shardnothing架构（MPP）。典型的ShardNothing系统会集数据库、内存Cach等存储状态的信息；而不在节点上保存状态的信息。节点之间的信息交互都是通过节点互联网络实现。通过将数据分布到多个节点上来实现规模数据的存储，通过并行查询处理来提高查询性能。每个节点仅查询自己的数据。所得到的结果再经过主节点处理得到最终结果。通过增加节点数目达到系统线性扩展。
图1GPDB的基本架构如上图1为GPDB的基本架构，客户端通过网络连接到gpdb，其中MastrHost是GP的主节点（客户端的接入点），SgmntHost是子节点（连接并提交SQL语句的接口），主节点是不存储用户数据的，子节点存储数据并负责SQL查询，主节点负责相应客户端请求并将请求的SQL语句进行转换，转换之后调度后台的子节点进行查询，并将查询结果返回客户端。
GrnplumMastrMastr只存储系统元数据，业务数据全部分布在Sgmnts上。其作为整个数据库系统的入口，负责建立与客户端的连接，SQL的解析并形成执行计划，分发任务给Sgmnt实例，并且收集Sgmnt的执行结果。正因为Mastr不负责计算，所以Mastr不会成为系统的瓶颈。
Mastr节点的高可用（图），类似于Hadoop的NamNodHA，如下图，StandbyMastr通过synchronizationprocss，保持与PrimaryMastr的catalog和事务日志一致，当PrimaryMastr出现故障时，StandbyMastr承担Mastr的全部工作。
图Mastr节点的高可用SgmntsGrnplum中可以存在多个Sgmnt，Sgmnt主要负责业务数据的存储和存取（图），用户查询SQL的执行，每个Sgmnt存放一部分用户数据，但是用户不能直接访问Sgmnt，所有对Sgmnt的访问都必须经过Mastr。进行数据访问时，所有的Sgmnt先并行处理与自己有关的数据，如果需要关联处理其他Sgmnt上的数据，Sgmnt可以通过Intrconnct进行数据的传输。Sgmnt节点越多，数据就会打的越散，处理速度就越快。因此与SharAll数据库集群不同，通过增加Sgmnt节点服务器的数量，Grnplum的性能会成线性增长。
图Sgmnt负责业务数据的存取每个Sgmnt的数据冗余存放在另一个Sgmnt上，数据实时同步，当PrimarySgmnt失效时，MirrorSgmnt将自动提供服务，当PrimarySgmnt恢复正常后，可以很方便的使用gprcovrsg-F工具来同步数据。
IntrconnctIntrconnct是Grnplum架构中的网络层（图4），是GPDB系统的主要组件，默认情况下，使用UDP协议，但是Grnplum会对数据包进行校验，因此可靠性等同于TCP，但是性能上会更好。在使用TCP协议的情况下，Sgmnt的实例不能超过，但是使用UDP则没有这个限制。
图4Grnplum网络层IntrconnctGrnplum，新的解决方案前面介绍了GPDB的基本架构，让读者对GPDB有了初步的了解，下面对GPDB的部分特性描述可以很好的理解为什么选择GPDB作为新的解决方案。
丰富的工具包，运维从此不是事儿对比开源社区的其他项目在运维上的困难，GPDB提供了丰富的管理工具，图形化的wb监控页面，帮助管理员更好的管理集群，监控集群本身以及所在服务器的运行状况。
最近的公有云集群迁移过程中，impala总查询段达到的时候，系统开始变得极不稳定，后来在外援的帮助下发现是系统内核本身的问题，在恶补系统内核参数的同时，发现GPDB的工具也变相的填充了我们的短板，比如提供了gpchck和gpchckprf等命令，用以检测GPDB运行所需要的系统配置是否合理以及对相关硬件做性能测试，如下，执行gpchck命令后，检测sysctl.conf中参数的设置是否符合要求，如果对参数的含义感兴趣，可以自行百度学习。
（点击可查看高清版）
另外，在安装过程中，用其提供的gpssh-xkys命令打通所有机器免密登录后，可以很方便的使用gpassh命令对所有的机器批量操作，如下图演示了在mastr主机上执行gpssh命令后，在集群的五台机器上批量执行pwd命令。
（点击可查看高清版）
诸如上述的工具GPDB还提供了很多，比如恢复sgmnt节点的gprcovrsg命令，比如切换主备节点的gpactivatstandby命令，等等。这类工具的提供让集群的维护变得很简单，当然我们也可以基于强大的工具包开发自己的管理后台，让集群的维护更加的傻瓜化。
查询计划和并行执行，SQL优化利器查询计划包括了一些传统的操作，比如：扫表、关联、聚合、排序等。另外，GPDB有一个特定的操作：移动（motion）。移动操作涉及到查询处理期间在Sgmnt之间移动数据。
下面的SQL是TPCH中Qury1的简化版，用来简单描述查询计划。
（点击可查看高清版）
执行计划执行从下至上，可以看到每个计划节点操作的额外信息。
Sgmnt节点扫描各自所存储的customr表数据，按照过滤条件生成结果数据，并将自己生成的结果数据依次发送到其他Sgmnt。
每个Sgmnt上，ordrs表的数据和收到的rs做join，并把结果数据返回给mastr
上面的执行过程可以看出，GPDB是将结果数据给每个含有ordrs表数据的节点都发了一份。为了最大限度的实现并行化处理，GPDB会将查询计划分成多个处理步骤。在查询执行期间，分发到Sgmnt上的各部分会并行的执行一系列的处理工作，并且只处理属于自己部分的工作。重要的是，可以在同一个主机上启动多个postgrsql数据库进行更多表的关联以及更复杂的查询操作，单台机器的性能得到更加充分的发挥。
如何查看执行计划？如果一个查询表现出很差的性能，可以通过查看执行计划找到可能的问题点。
?计划中是否有一个操作花费时间超长？?规划期的评估是否接近实际情况？?选择性强的条件是否较早出现？?规划期是否选择了最佳的关联顺序？?规划其是否选择性的扫描分区表？?规划其是否合适的选择了Hash聚合与Hash关联操作？
高效的数据导入，批量不再是瓶颈前面提到，Grnplum的Mastr节点只负责客户端交互和其他一些必要的控制，而不承担任何的计算任务。在加载数据的时候，会先进行数据分布的处理工作，为每个表指定一个分发列，接下来，所有的节点同时读取数据，根据选定的Hash算法，将当前节点数据留下，其他数据通过intrconnct传输到其他节点上去，保证了高性能的数据导入。通过结合外部表和gpfdist服务，GPDB可以做到每小时导入TB数据，在不改变ETL流程的情况下，可以从impala快速的导入计算好的数据为消费提供服务。
使用gpfdist的优势在于其可以确保再度去外部表的文件时，GPDB系统的所有Sgmnt可以完全被利用起来，但是需要确保所有Sgmnt主机可以具有访问gpfdist的网络。
其他GPDB支持LDAP认证，这一特性的支持，让我们可以把目前Impala的角色权限控制无缝的迁移到GPDB。
GPDB基于Postgrsql8.开发，通过psql命令行工具可以访问GPDB数据库的所有功能，另外支持JDBC、ODBC等访问方式，产品接口层只需要进行少量的适配即可使用GPDB提供服务。
GPDB支持基于资源队列的管理，可以为不同类型工作负载创建资源独立的队列，并且有效的控制用户的查询以避免系统超负荷运行。比如，可以为VIP用户，ETL生产，任性和adhoc等创建不同的资源队列。同时，支持优先级的设置，在并发争用资源时，高优先级队列的语句将可以获得比低优先级资源队列语句更多的资源。
最近在对GPDB做调研和测试，过程中用TPCH做性能的测试，通过和网络上其他服务的对比发现在5个节点的情况下已经有了很高的查询速度，但是由于测试环境服务器问题，具体的性能数据还要在接下来的新环境中得出，不过GPDB基于postgrsql开发，天生支持丰富的统计函数，支持横向的线性扩展，内部容错机制，有很多功能强大的运维管理命令和代码，相比impala而言，显然在SQL的支持、实时性和稳定性上更胜一筹。
本文只是对Grnplum的初窥，接下来更深入的剖析以及在工作中的实践经验分享也请北京儿童医院白癜风外用药皮肤白癜风能治的好吗