.................. - 345 - 规划数据重分布 .............................................................................................................. - 346 - 管理大规模集群的数据重分布 .............................. ................................ - 347 - 重分布 AO 表和压缩表 ........................................................................................... - 348 - 重分布分区表 ..................................... ..................................................................... - 348 - 重分布有索引的表 .................................................................................................. - 349 - 准备并添加新的计算节点主机

Postgresql 而不是其它的？ 我想大家可能主要想问为什么是 Postgresql 而不是 Mysql ？（其实， 还有很多开源关系型数据库，但相比这两个主流开源库，实在不在 一个起跑线上）。我们无意去从技术点上PK这两个数据库孰优孰劣， 我相信它们的存在都有各自的特点，它们都有成熟的开源社区做支 持，有各自的庞大的 fans 群众基础。我们认为，Greenplum 选择 Postgressql 有以下考虑： 行 的 Style 贯 穿 了 Greenplum 功能设计的方方 面面： 外部表数据加载是并行的、 查询计划执行是并行的、索 引的建立和使用是并行的， 统计信息收集是并行的、表 关联（包括其中的重分布或 广播及关联计算）是并行的，排序和分组聚合都是并行的，备份恢复 也是并行的，甚而数据库启停和元数据检查等维护工具也按照并行方 式来设计。得益于这种无所不在的并行，Greenplum 在数据加载和数 统数据仓库平台上耗时半天以上。 在该用户的生产环境中，1 个数百亿表和 2 个 10 多亿条记录表的全表 关联中（只有 on 关联条件，不带 where 过滤条件，其中一个 10 亿 条的表计算中需要重分布），Greenplum 仅耗时数分钟就完成了， 当其它传统数据平台还在为千万级或亿级规模的表关联性能发愁时， Greenplum 已经一骑绝尘，在百亿级规模以上表关联中展示出上佳的 表现。 Big

TB 级别数据 • 1000+ 特征 平台 建模⼯工具 PL/pgSQL 数据和技术预览 2017.thegiac.com 数据整理理 数据准备 信息价值和证据权 重 成对相关性 删除⾼高度相关变量量 逻辑回归 计算 KS 分值 模型验证 ⼿手动预测 1 2 3 4 5 6 7 8 原始⼯工作流程 2017 逻辑回归迭代需要 ~1.86 分钟 ~16x/迭代 ⼯工作流程优化 2017.thegiac.com 原始模型 改良后的模型 ● 模型精确度 = 99.7% ● 真正率(True Positive Rate) = 0% ● 模型精确度= 62.8% ● 真正率 = 66% 该模型善于预测不不会点击邮件的⽤用户， 但是⽆无法预测会点击邮件的⽤用户 该模型更善于预测会点击邮件的用户，

归并连接 45 ● 聚集中的去重操作同样可以基于排序算法完成 ● Step 1： 延时执行转移函数，tuplesort_putdatum(peraggstate->sortstate, value, isnull); ● Step 2： 排序， tuplesort_performsort(peraggstate->sortstate); ● Step 3： 去重，如果当前元组distinc

垃圾空间回收  Vacuum：标记垃圾空间为可再利用 Vacuum用于将数据表垃圾空间标记到FSM（自由空间映射），一般也不回收空间，当往该表插入新数据时，数据库会重 新这些空间。 FSM驻留在内存中，FSM的大小必须足够标记数据库中的所有过期记录。如果尺寸不够大,超出自由映像空间的过期记录 占用的空间将无法被VACUUM命令标记。可通过修改max_f 超过10 0000个对象，在数据目录下地文件数会可能达到上百万 个档，这些文件的拷贝需要花费很长时间 – 使用gpexpand扩容节点时，对象数多，对应到每个实例下的文件数非常多，将这些目的档重分布到新扩展的节 点时间会很长 – 系统表（pg_class,pg_attribute）太大，影响系统工作效率 – 系统元数据检查pg_checkcat等工具运行时间比较长 数据压缩对于高并发查询分析系统可以大幅降低IO消耗，提升并行处理、混合负载的性能 分布键使用： • 尽量采用一个常用关联字段作为分布键，例如账号、客户号，这个可以提高关联条件的命中率，减少关联时数据重分布 （主要对大表） • 选用分布键同时考虑数据平均分布（一个例子，日志号不是最好的分布键，大量的空值导致资料倾斜） 物理模型经验分享（续） 分区表使用： • 不建议使

UCloud 优刻得 41/206 操作指南 Greenplum数据仓库 UDW Copyright © 2012-2021 UCloud 优刻得 42/206 数据仓库扩容过程中需要对数据进⾏重分布，因此，扩容完成的时间根据数据量的⼤⼩⽽不同。⽬前，暂时不⽀持数据仓库的缩容。 更改数据仓库密码 更改数据仓库密码 操作指南 Greenplum数据仓库 UDW Copyright © 2012-2021 上亿⾏或者更多的的数据，可以通过分区把数据通过分区分为很多⼩的部分、从⽽提⾼性能。如果⼀个表只有⼏千⾏和⼏ 万⾏就不需要再做分区。 查询模式固定：例如你经常按照⽇期去查找表格数据、我们可以按照每⽉或者每天做分区；如果你需要按照地区去访问数据，我们可以按照地区去做分区。 数据仓库保留⼀个时间窗⼝的数据：例如您数据仓库需要保留⼀年的数据、如果按⽉做分区、可以通过分区很⽅便的删除最早的⽉份分区、把数据加载到最新的⽉份分区。

– 没有明确的定义 – 不同优化器不一致 – 优化器不能被纳入资源管理器 2017 年象行中国（杭州 站）第一期 Resource Queue • Priority is rough – 不能精确控制CPU – CHECK_FOR_INTERRUPTS – BackoffBackendTick – sweeper process (backoff.c) 2017 年象行中国（杭州 站）第一期 第三方库的malloc 2017 年象行中国（杭州 站）第一期 Resource Group • SQL语句并发控制 => 事务并发控制 • 基于cost的并发控制 • 基于优先级的CPU控制 => 精确CPU比例 • 内存控制 => 严格资源隔离 2017 年象行中国（杭州 站）第一期 Running Example • CREATE RESOURCE Group rg WITH ( concurrency=1 – 设置cpu/gpdb/cpu.cfs_quota_us – cpu/gpdb/cpu.shares足够大 – rg1和rg2的cpu.shares按比例配置 – 空闲group配额会被抢占 – 精确控制 2017 年象行中国（杭州 站）第一期 Resource Group • Memory – Not using CGroups – 重构resource queue内存管理 – 严格资源隔离

gpactivatestandby一样，是一个 用python写的命令行脚本。 GPExpand简介与具体用法 • GPExpand工作流程 – 建立并添加新节点 – 数据重分布 GPExpand简介与具体用法 • 增加新节点 – gpexpand –i 配置文件 • 数据重分布 – gpexpand • 清理 – gpexpand -c GPExpand简介与具体用法 • 增加新节点 – gpexpand status —扩容状态 ▪ status_detail —将所有需要扩容的表都存到这个表里 ▪ expansion_progress —记录扩容时的状态 GPExpand简介与具体用法 • 数据重分布 – GPExpand – 会遍历postgres数据库下面gpexpand.status_detail表对所有表执行 ALTER TABLE {schema.table} EXPAND TABLE; GPExpand简介与具体用法 • 清理 – gpexpand –c – 会将gpexpand schema和下面关于扩容的表都清理掉 Greenplum 6中GPExpand的改进与实现 • 在线不停机 • 数据重分布优化 • 并行的优化 改进与实现 • 如何做到不停机 – 增加新节点只要在gp_segment_configuration里添加新节点信息即可 – 新节点以Master为模板生成，只包含catalog，没有数据

query optimizer (6 rows) Confidential │ ©2021 VMware, Inc. 20 Redistribute Motion 将数据根据某一个或多个字段对数据进行哈希重分布，目的在于完成诸如连 接(JOIN)、聚合(Agg) 等操作。 Redistribute Motion postgres=# explain (costs off) select * from Redistribute Motion 3:3 (slice1; segments: 3) Hash Key: brand -> Seq Scan on sales 一阶段聚集 l 我们需要对所有数据进行重分布，网络开销昂贵 l 若分组数量远小于集群节点数量，则会造成严重的计算倾斜 Confidential │ ©2021 VMware, Inc. 23 Multi-Stage Aggregate brand -> HashAggregate Group Key: sales.brand -> Seq Scan on sales 二阶段聚集 l 此时，只需要对在各个节点聚合后的数据进行重分布 l 但需要额外实现 combine() 方法 24 Confidential │ ©2021 VMware, Inc. Greenplum 分布式执行器 QD/QE/火山模型/Gang

要数据移动。在这个例子中classes 的分布键（id）和关联键（student_id) 不同，所以需要数据 重分布。 数据重分布由 Motion 操作符节点处理，它分成2个部分，一部分负责发送数据，一部分负责接收 数据。发送数据者可以根据不同的策略将数据发送给接收方，现在支持的策略有1）重分布（ redistribution）；2）广播（broadcast）。 最后每个segment执行结束后，将结果发送给