3 大家都知道 Greenplum 的数据库引擎层是基于著名的开源数据库 Postgresql的（下面会分析为什么采用Postgresql，而不是mysql等等）， 但是 Postgresql 是单实例数据库，怎么能在多个 X86 服务器上运行多 个实例且实现并行计算呢？为了这，Interconnnect 大神器出现了。在 那一年多的时间里，大咖们很大一部分精力都在不断的设计、优化、 开发 Interconnect 的同学应该都看到每个实例都有自己 的 Postgresql 目录结构，都有各自的一套 Postgresql 数据库守护进 程（甚至可以通过 UT 模式进行单个实例的访问）。正因为如此，甚 至一个运行在单节点上的 GreenplumDB 也是一个小型的并行计算架 构，一般一个节点配置 6~8 个实例，相当于在一个节点上有 6~8 个 Postgresql 数据库同时并行工作，优势在于可以充分利用到每个节点 提供的 22 条 Oracle SQL 语句，不做任何改动就能运行在 Greenplum 上。 最 后， 需 要 强 调 的 是：Greenplum 绝 不 仅 仅 只 是 简 单 的 等 同 于 “Postgresql+interconnect 并行调度 + 分布式事务两阶段提交”， Greenplum 还研发了非常多的高级数据分析管理功能和企业级管理模 块，如下这些功能都是

Standby)是不能接受连接请求和 SQL 访问的。虽然只 有一个 Master，就目前已有用户的使用情况来看，即便是编者有幸参与建设的 192 台计算节点的集群，Master 的资源依然很空闲，并不会成为性能的瓶颈，同时，因为 是单 Master，可以最大限度的规避多 Master 架构的系统表频繁不一致的缺陷。 GP 是基于 PostgreSQL 发展而来，用户端可以如同访问 PostgreSQL 那样与 GP 进行交互。可以通过 18616691889) 编写：陈淼 - 19 - 海量数据仓库的一个重大挑战是，要在一个受限的时间窗口内完成大量数据的装载。 GP 通过外部表(External Table)支持高速并行数据装载。外部表可以使用[单条记 录出错隔离]模式，以允许在装载数据过程中将出错的数据记录下来。可以设置错误容 忍的阈值，以实现对数据装载质量的控制。也可以对错误信息进行分析，以帮助改善数 据装载的质量。 结合使用外部表和 DAY 4 DAY 'Friday' DAY 5 DAY 'Saturday' DAY 6 每日中的时间可以使用 12 小时或者 24 小时格式。在 TIME 关键字之后跟随单引 号引起来的时间格式。仅仅含有小时和分钟的时间即可(也可以使用秒单位)，且使用 冒号(:)作为分隔符。如果使用 12 小时格式，需要指定 AM 或者 PM 结尾以确定上下午。 下面的例子表明了几种时间格式：

如果过多的侵占到OS的内存，可能导致Instance down – 系统运行缓慢 – 其它异常 OOM-解决办法  优化查询以减少内存的消耗  在资源队列中降低查询的并发数  降低GP集群中单节点的Segment Instance数量  增加机器的内存  检查gp_vmem_protect_limit 参数, 确保其不要超过安全的最大值  在会话层面降低statement_mem 可增量备份-识别AO的方式与gpcrondump一致，同时支持heap表的增备(是否发生过变化)  可指定并发数(同时多张表备份)，可指定编码Encoding  乐观锁设计——单表尝试加锁失败即认为该表本次备份失败  命令简单易用——单命令无需部署，参数基本保持与gpcrondump一致，自劢完成全部必要的准备工作  恢复可选表清单，可指定条件恢复部分数据，可恢复到指定增备日期 源端可以是视图，自劢识别是否使用快速模式  命令可部署在可在集群外执行  自劢识别低速模式，快速模式和全速模式  可指定并发数(同时多张表传输)，可指定编码Encoding，解决特殊的乱码问题  命令简单易用——单命令无需部署，参数基本保持与gptransfer一致，自劢完成全部必要的准备工作

来自阿里巴巴旗下商家服务市场的最新数据显示，聚水潭已是企业 ERP类目中使用商家数最多的软件。自双十一购物节诞生以来，团队 经历了每一次电商大促的考验，尽管每年承载单量成几何倍数增加， 聚水潭系统依然保持平稳、安全和顺畅地运行。2018年11月11日， 聚水潭系统处理订单总量达1.51亿单，成交额达341亿。 聚水潭简介 关键字 数据架构 推 送 库 中 间 库 商 品 库 核 心 库 辅 助 库 推 送 库

Master-Segment 则会同时进⾏数据分区（⽔平扩展）和复制（冗余） 分区与分⽚ 在项⽬初期，我们使⽤⼀张表 T 存储数据。随着业务的增多，单表出现性能瓶颈，因⽽将 T ⽔平拆分成多个表进⾏存储，这个过程通常称为分区。紧接着，单⼀ 的数据库实例出现瓶颈，因此需要使⽤多个节点创建多个数据库实例，再按照某种规则将数据尽可能均匀地分布到各个节点上 ，这个过程通常称之为分⽚ GP 同

公司IDC_03机房Greenplum体系 • 服务器资源 Ø 三大Greenplum集群，共用 422 个postgresql实例 Ø 实例分布成为 28 个Greenplum集群或postgresql单实例 • 服务器资源 Ø 三大Greenplum集群，共使用 51 台服务器资源 Ø 12台虚拟机，39台物理机 17 Greenplum现状说明 三大Greenplum集群定位分类 • 分区表的分区键性能不佳 • 加载易出现问题 Ø 文件加载出现特殊字符 Ø 数据校验标准问题 35 Greenplum开发规范 业务库表设计规范 • GP中表的范围 Ø 最大时间为年表 Ø 数据量小，可用单表 • 多种表类型 Ø 堆表 （选好常用列作为三列键） Ø 分区表 （按照 yyyymmdd 分区，建议都添加 datenum int8） Ø append表 Ø 列存储表 Ø 多种表类型结合 •

\ --disable-gpfdist --prefix=$HOME/gpdb.master $ make [-j4] $ make install 在苹果系统上初始化Greenplum单节点集群时，需要做些准备工作： ● 添加​export PGHOST=localhost​至​~/.bash_profile ● 将本机的​hostname​与​127.0.0.1​的map写到/etc/hosts中。例如 Motion），返回给客户端。 4. 调试 Greenplum MPP 数据库 4.1 调试 Master 节点Backend进程 调试 Master 的Backend进程（也称为 QD）和调试单节点的PostgreSQL 非常类似。 通常遇到解析、优化、调度相关问题时，需要调试QD。 下面以一个例子介绍如何调试 Greenplum QD 进程。 启动两个窗口，一个运行psql，一个运行

EXPAND每个表 – 对表加最高级别锁（其他读写均被阻塞） – 移动数据到新节点 – 修改numsegments – 释放锁 改进与实现 • numsegments的收益 – 不需要将表改成随机分布，单表查询可以做优化 – 对于Join查询，如果分布状态相同的情况下，可以被优化 改进与实现 • 减少重分布数据移动量 – Greenplum 5及之前版本采用取模分布 – 节点数量发生变化后重新计算取模，移动数据量大

十几个甚至几十个国内国外的衍生项 目（我们是真开源，欢迎大家贡献） Confidential │ ©2022 VMware, Inc. 6 Greenplum的MPP架构 Ø Massively: q PB级的数据，单台主机无法处理 q 所以数据分布在多个主机上 q 高效、灵活的数据分布，和实际业务相关 Ø Parallel: q 数据并行处理计算 q 通过网络进行数据交换和汇总 Confidential

区贡献者包括阿里云、中移动等大公司，也有诸多中小公司和数据库爱好者。 开源之后，Greenplum 把敏捷软件开发方法学引入到分布式数据库的开发中，通过使用站立会议、 回顾会议、结对编程、持续集成、测试驱动、单周迭代等敏捷方法建立了高效的快速反馈系统， 大大提高了产品的质量和客户的满意度。Greenplum 5.0 是开源之后发布的第一个稳定版本，大 约保持 1 个半月一个版本的发布速度。Greenplum