Greenplum性能调试记录
前言：
以目前的使用体验的话，Greenplum（以下简称GP）的实时性确实比较高，从存储层到计算层，数据吞吐效率比类Hadoop生态圈的sql工具要好得多。
伴随性能的提升，同时加深的是gp对硬件的要求。
就目前的GP集群的硬件配置情况来说：
5台22线程，64G内存，2T硬盘，千兆网卡机器（整体情况是110线程，320GB内存，disk IO 150MB/s，网络 IO 150MB/s）
与现今的spark集群相比（10台22线程，128G内存，30T硬盘，千兆网卡），sql查询性能提高50%-300%。以下是水星线上任务在GP和spark上运行
的对比表：
|
Sql
|
spark用时
|
gp用时
|
Gp提升%
|
|---|---|---|---|
| Sql1 | 132s | 3s | 40倍 |
| Sql2 | 131s | 90s | 30% |
| Sql3 | 3s | 3s | 0% |
| Sql4 | 30s | 18s | 30% |
分析下可能的原因：
1.spark集群使用的远程HDFS数据，数据传输有很大的延迟。
2.spark虽然使用RRD策略实现数据的存储和IO，但是Spark本身还是一个离线的计算模型，
期间存在典型的输出文件的存储和大量的网络传输，相比于MPP（GP计算模型）有很大的缺陷。
这其实也是离线框架和在线框架最本质的区别。
3.在数据库层面，spark-sql框架接入的是hive数据，而hive是一个非结构行数据库，优点在
于大数据量的存储，在数据索引，数据存储结构，元数据信息等方面还收集的不够完善。
而GP是基于postgrel数据库，具有很强的DML和DQL能力，在数据索引和存储方面更优秀。
Greenplum的参数配置记录：
一共5台计算节点，每个节点部署3个segment（postgrel实例）服务，每个segment分配5线程，20G内存。
使用任务队列：目前水星使用mercury队列，设置并行数：ACTIVE_STATEMENTS=5
设置优先级：PRIORITY=MAX
eg: CREATE RESOURCE QUEUE adhoc WITH (ACTIVE_STATEMENTS=3,PRIORITY=MAX);
使用mercury用户：单作业使用内存：set statement_mem = '4GB';
最大使用内存：set max_statement_mem = '10GB';
使用Pivotal Optimizer：set optimizer to on;
不使用groupagg：set enable_groupagg to off;
eg: create user u1 with resource queue mercury;
alter user u1 set statement_mem to '2GB';
alter user u1 set optimizer to on;
系统参数配置：
gp_resqueue_memory_policy = 'eager_free' --提早回收前期阶段的内存
gp_vmem_protect_limit = 19968 --每个segment的分配内存
gp_resqueue_priority_cpucores_per_segment = 4 --每个segment的分配线程数
shared_buffers = 1GB --segment用作磁盘读写的内存缓冲区
work_mem = 4GB --segment用作sort,hash操作的内存大小
maintenance_work_mem = 10GB --segment用于VACUUM,CREATE INDEX等操作的内存大小
effective_cache_size = 10GB --segment能使用的缓存大小
max_connections = 1200 --最大连接数
max_prepared_transactions = 300 --最大预连接数
eg: gpconfig -c gp_resqueue_memory_policy -v eager_free -m eager_free
gpconfig -c work_mem -v 4GB
gpconfig -c max_connections -v 1200 -m 800
Greenplum调优方法：
1.调整表的分布键，常用于join和where条件的列作为分布键，最典型的例子是两张做join的表都用需要连接的列作为分布键。
2.周期使用VACUUM ANALYZE命令维护数据库的统计信息。
3.一般不使用Index，对于需要使用的表如果分布键是粗粒度的使用BitMap索引，如果是细粒度的使用BTree索引。
4.一般使用Pivotal Query Optimizer，在使用Legacy Query Optimizer的时候，使用explain analyze命令查看执行计划，优化不合适的operator。
5.避免大表的broadcast，多使用ANALYZE TABLE.命令。
6.看实际情况多使用enable_hashagg和enable_hashjoin。
7.用group by代替distinct.
8.在多表左连接时，小表放在左边。内连接时调整连接顺序尽量少的把数据带向上层连接。
9.多使用explain analyze看看执行计划。
explain anaylze命令介绍：
example:select count(1) from mercury.mds_mercury_gid_dsp_c where dt='work' and Cbehe=1 and Cbiddingx=1;
除此之外还有以下操作:
Hash Join
HashAggregate
Redistribute Motion
Broadcast Motion等
并发测试：
同时运行5个数据量100G的任务，集群负载情况：
cpu负载良好，存在瓶颈的是磁盘读写和网络读写。但是即使在这样的情况下，执行平时20s的任务延迟也不会太高，执行23秒也就结束了。对于10s内完成的任务如本文的sql1和sql3基本没有影 响。
但是集群的瓶颈也是很明显的，上图中的bjlg-49p122-greenplum-01节点的磁盘读速率已经到达了上限。另一方面，在内存上瓶颈依然存在，我目前还不清楚上图中的内存使用为什么显示还很少。但是从另一个图表中可以看到内存已经过载了（Used(MBytes)）：
而空闲时段的内存情况是这样的：
其实硬件方面瓶颈最严重的是disk IO和network IO，下面是每台机器的IO评测情况：
disk IO：
写最大也只有140MB/s,读最大260MB/s.
Network IO：
，100MB/s左右的网络传输速率对于一个要支持大数据量的在线计算框架来说瓶颈很明显。
下图是一个大Join任务在shuffle阶段的瓶颈，cpu和内存正在空闲状态等待数据的传输：
综上所诉，现在集群存在的问题：
1.网络IO低，目前使用的千兆网卡。
2.磁盘IO低，对于本地读取需求的任务影响大。
3.现有的业务数据所有都存在hdfs，如果需要迁移到GP，不是太效率。
调研结论：
针对现有的硬件条件和数据存储情况，建议迁移实时性要求高的短作业到GP上跑，不建议迁移长时间的批处理作业。