对比开源社区的其他项目在运维上的困难，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。

(责任编辑：本港台直播)