Greenplum进阶篇_Greenplum企业应用实战

第五章 执行计划详解
5.3.4 关联
 hash join
 hash left join
 NestLoop
 Merge join & merge left join: 因为要对左右表按关联键先进行排序，所以效率比hash join差
 Merge full join：唯一可以执行full outer join的方式
 Hash exists join


5.3.5 sql消耗

1. cost
2. rows：估计sql返回结果集行数
3. width: 返回结果集每一行长度

5.3.6 其他术语

1. filter过滤
2. index cond
3. recheck cond：在使用位图扫描索引时 ，由于使用MVCC协议，故需重新检查
4. hash cond
5. merge
6. hash key：在数据重分布时指定的重算hash值的分布键
7. materialize
8. join filter
9. sort, sort key
10. window, partition by, order by: 这个是使用开窗函数（window function），执行计划中显示使用分析函数的标识；
    开窗函数：用于为行定义一个窗口，它对一组值进行操作，不需要使用group by子句对数据进行分组，能够在同一行中同时返回基础行和列和聚合列；
    开窗函数主要分为
     排名开窗函数：row_number, dense_rank, rank
     聚合开窗函数: sum, avg, max, min, count
11. limit
12. append

5.4 数据库统计信息收集
5.4.1 analyze分析

5.4.2 固定执行计划

5.5 控制执行计划的参数介绍
Hint
控制执行计划的参数是在会话级别

5.6 规划器开销的计算方法

Relname：表名
Relpages：数据页数
Reltuples: 数据量大小

5.7 各种执行计划原理分析
5.7.1 详解关联的广播与重分布
当两张表关联时，若一张表关联键不是分布键，则会发生表的广播或重分布，将数据移动到一个节点上进行关联，从而获得数据。
分布的关联有两种：
 单库关联
 跨库关联

1. 内连接
    分布键与关联键相同，属于单库关联，不会造成广播或重分布
    其中一张表a的关联键是分布键，另一张表b的关联键不是分布键
   1） 对b表数据按关联键进行重分布，再与表a关联
   2） 将abiao进行广播，每个节点都放一份全量数据，再与b表进行关联得到结果
   判断准则：当重分布数据量>广播数据量 * 节点数，则进行广播，否则进行重分布
    两张表关联键和分布键都不一样
   1） 将表a和表b都按照关联键进行重分布到每个节点，代价是两个表的总数据量
   2） 将其中一张表广播后再关联，其中是选择小表广播，广播的代价是min(表a数据量，表b数据量)*节点数
   3） 判断准则：当两个表总数据量> min(表a数据量，表b数据量) * 节点数，选择小表广播，否则两个表都重分布

2. 左连接
    分布键与关联键相同，属于单库关联
    若左表a分布键是关联键，右表b分布键不是关联键，则无论表b数据量多大，都要将表b进行重分布
    左表a的关联键不是分布键，右表b是关联键；由于左表a肯定不能被广播，故
   1） 将表a进行重分布，再与表b关联，代价为表a数据量
   2） 将表b广播，代价为表b数据量* 节点数
    左表a和右表b关联键都不是分布键
   1） 将表a和表b都按关联键进行重分布，代价是两个表的数据量和
   2） 表a不能被广播，只能对表b进行广播，代价为表b数据量 * 节点数

3. 全连接
    对关联键都是分布键时，只能采用merge join实现
    对关联键不是分布键的表进行重分布；无论表A和表B大小分别是多少，为实现全连接，不能将表广播，只能是重分布

5.7.2 hashAggregate与groupAggregate
1）HashAggregate：根据group by字段后面值计算出hash值
2）groupAggregate：将表中数据按group by字段排序，这样同一个group by值就在一起
groupAggregate由于要进行排序，故一般比hashAggregate差；但是，hashAggregate在少数聚合函数时表现优异，但对于很多聚合函数时，性能和消耗内存差异很明显；尤其受group by字段唯一性影响，字段count值越大，hashAggregate消耗内存越多，性能下降越明显；故sql中有大量聚合函数，groupby字段重复值较少，应用groupAggregate，而不能用hashAggregate.

5.7.3 nestloop join, hash join, merge join

1. nestloop join：就是笛卡尔积，关联效率极差
   2）hash join: 先对其中一张关联表计算hash值，在内存用一个散列表保存，再对另一张表进行全表扫描，之后将每行与这个散列表进行关联
   3）merge join: 对两张表按关联字段进行排序，再按排序好的内容顺序遍历一遍，将相同值连接起来，从而实现连接。

5.7.4 分析函数：开窗函数和grouping sets

5.8.4 分布键选择不当
分布键不当情况：
 随便选择一个字段作为分布键
 分布键导致选择数据分布不均，sql卡在一个segment计算
对于第一种情况，当执行计划出现redistribute motion或broadcast motion时，就知道重新分布了数据

Greenplum与其他数据库在执行计划上最大区别就是广播与重分布，而这两个过程又严重依赖于统计信息完整性，对于因统计信息不完善而导致的执行计划更易出错，这需要将sql拆分来实现。Greenplum执行计划相对其他数据库执行计划更易出错，且广播大表有可能耗尽数据库所有资源，故分析执行时间过长的sql时，应先从执行计划入手。

第6章 greenplum高级应用
6.1 appendOnly表与压缩表
压缩表必须是appendOnly表
appendOnly表：只能不断追加的表，不能进行更新和删除

压缩表应用场景
1） 业务上不用对表进行更新和删除，用truncate+insert即可
2） 访问表基本是全表扫描，不用建立索引
3） 不能对表加字段或修改字段类型，对appendOnly表加字段比普通表慢很多

6.4.3 plpython
Python可以调用类库实现；对于项目中一些用sql运行比较复杂的逻辑，可以直接调用python包来实现

6.5 greenplum mapreduce
允许用户自己编写map和reduce函数，然后提交给greenplum并发处理引擎处理，greenplum在分布式环境下运行mapReduce代码，并处理所有segment报错信息。

小结：
压缩表：对数据采用压缩存储的方法，可利用cpu节省存储空间，降低IO消耗，对数据库应用性能有重要影响
列存储：将数据按列存储，可提升压缩率，但列存储会带来大量小文件，对文件系统造成压力，故不能大规模使用
外部表：可方便进行数据导入导出，通过并行处理，性能非常高；greenplum通过提供与hdfs快速交互方式，使数据库与hadoop可灵活结合使用
自定义函数：使数据库使用更容易，在拓展sql上有重要作用，通过自定义函数，再结合sql，可实现很多功能，另外，greenplum提供非常灵活语言实现，如python，C等，用户可选择合适语言编写自己的UDF
mapReduce：简化编程模型，可解决很多sql无法完成的功能，greenplum的mapReduce很好地与数据库进行结合，提供了另外一种处理数据方法。

第7章 greenplum架构介绍

Greenplum配置了镜像节点后，当主节点不可用时会自动切换到镜像节点，集群仍保持可用状态；当主节点恢复并启动后，主节点就会自动恢复期间的变更。
只要master不能连接上segment实例，就会在系统表中将此实例标识为不可用，并用镜像节点来代替。
注意：如果配置服务器集群时，没有开启镜像功能，任何一个segment实例不可用，整个集群都将不可用，大大降低集群可用性。
7.5 数据分布及负载均衡
Greenplum是一个分布式数据库系统，故其所有业务都是物理存放在集群的所有segment实例数据库上。
数据库中所有表都是分布式的，所以每张表都会被切片，每个segment实例数据库会存放相应的数据片段，切片规则由用户定义，可选方案是根据用户对每张表指定的hash key进行hash分片或选择随机分片。

数据库在创建或修改表时可选的数据分散策略：
 Hash distribution
数据库默认采用hash distribution；会指定表的一列或多列组合形成hash key，数据库根据指定的hash key列计算每行数据对应的hash值，并映射到相应的segment实例；当选择的hash key列的值唯一时，数据会均匀分散到所有segment实例；若未指定distribution key，则会选择primary key作为distributed key，若primary key也不存在，则会选择第一列为distributed key。
 Random distribution
该策略下，数据会随机分配到segment，相同值的数据行不一定会分发到同一个segment；虽然该策略可确保数据平均分散到所有segment，但在进行表关联分析时，仍然会按关联键重分布数据，因此该策略通常不是一个明智的选择。
注意：在表分片规则选取时，应尽可能选择唯一且常用于join的列作为distribution key，这样数据才会均匀分散到所有segment实例，相应查询及计算的负载也会平摊到整个集群，进而最大程度体现分布式计算优势。

7.6 跨库关联
1） join操作的两个表的distributed key即join key
由于join key也是两个表的distributed key，故两表关联行本身就在本地数据库，即同一个segment，直接关联即可

2）join操作的两个表中一个distributed key和join key相同
数据需要跨节点移动，将关联的行组织在同一个segment实例，最终完成join操作。
 将join key和distributed key不一致的表按关联字段重分布
 将join key和distributed key不一致的表在每个segment进行广播

3）join操作的两个表的distributed key和join key都不同
 将两个表都按关联字段重分布
 将其中一个表在每个segment进行广播，即每个segment都复制一份全量表

7.7分布式事务
分布式事务：一个事务可能涉及多个数据库操作，分布式关键在于两阶段提交；两阶段提交用于确保所有分布式事务能同时提交或回滚，以便数据库处于一致性状态

7.8 其他大数据分析方案
1）hadoop
它由HDFS, MAP/REDUECE, HBASE, HIVE和Zookeeper组成；其中，HDFS和MapReduce是两个最基础，最重要的成员。