GP 的计算实例，很多时候也叫 Segment Primary ： GP 的主计算实例 Mirror ： GP 的镜像计算实例 MPP ： 大规模并行处理 算子 ： 执行计划中的运算操作 背景简介 多年前，编者翻译了 GP4.2.2 的 AdminGuide，如今，GP 已经历经了无数个版 本更新和迭代，编者也有了更多的感悟，放眼 GP 的中文资料，为之动容，就想着再为 ............................ - 179 - 理解执行计划与分发 .............................................................................................. - 179 - 理解执行计划 ......................................... ANALYZE 输出 ............................................................................ - 234 - 检查执行计划排查问题 .......................................................................................... - 237

Scale-up 模式遇到了瓶颈， SMP（对称多处理）架构难于扩展，并且在 CPU 计算和 IO 吞吐上不 能满足海量数据的计算需求。 分布式存储和分布式计算理论刚刚被提出来，Google 的两篇著名论文 发表后引起业界的关注，一篇是关于 GFS 分布式文件系统，另外一篇 是关于 MapReduce 并行计算框架的理论，分布式计算模式在互联网 行业特别是收索引擎和分词检索等方面获得了巨大成功。 Big Date2 集群在整体上提供的计算能力已大幅高 于传统 SMP 主机，并且成本很低，横向的扩展性还可带来系统良好 的成长性。 问 题 来 了， 在 X86 集 群 上 实 现 自 动 的 并 行 计 算， 无 论 是 后 来 的 MapReduce 计算框架还是 MPP（海量并行处理）计算框架，最终还 是需要软件来实现，Greenplum 正是在这一背景下产生的，借助于分 布式计算思想，Greenplum 实现了基于数据库的分布式数据存储和并 那一年多的时间里，大咖们很大一部分精力都在不断的设计、优化、 开发 Interconnect 这个核心软件组件。最终实现了对同一个集群中多 个 Postgresql 实例的高效协同和并行计算，Interconnect 承载了并行 查询计划生产和 Dispatch 分发（QD）、协调节点上 QE 执行器的并 行工作、负责数据分布、Pipeline 计算、镜像复制、健康探测等等诸 多任务。 在 Greenplum 开源以前，据说一些厂商也有开发

所有元数据，如表结构定义、索引等等。但其并不存储 实际的数据，实际的数据是存储在segment 数据库 的。 master服务器接受从用户发来的连接，并做用户验证， 接收用户发来的sql，生成分布式执行计划，再把分布 执行计划分发到segment上执行，接收segment返回的 数据，最后返回给用户。 Greenplum架构: Segment介绍 Segment是数据的实际存储的地方，也是一个经过改造 也是可以读写的。而Greenplum4.0版本后，primary与 mirror实际上是物理同步，这时mirror一直处于恢复状 态，不能读也不能写。 高可用之Master Mirroring 对于Greenplum Master的primary与mirror之间的同步 就是使用PostgreSQL的日志同步方案。master的 mirror可以在建库时建，也可以在建完greenplum后再 添加。 理解greenplum分布式数据库 0的新功能） GP的查询处理 用户提交一个SQL到master，master解析这个SQL， 生成一个分布式的执行计划，然后把这个分布式的执行 计划分发到各个segment上，然后segment执行它自己 的特定数据集的本地数据库业务。 所有的数据库操作，如表扫描、表连接（joins)、聚集 （ aggregations），排序，这些操作都会在所有的 segment上并行执行。每个segment执行这些操作时都

........................................................................................ 4 集成分析：改进后的全新分析接口 ............................................................................................ io/cn 白皮书 6 © Copyright 2017 Pivotal Software, Inc.保留所有权利。 PIVOTAL GREENPLUM 5：新一代数据平台 集成分析：改进后的全新分析接口 一直以来，客户都能在 Pivotal Greenplum 中做高级分析，无论是提供将应用逻辑向下推送至数据所在位置的方法，执行 分析功能，还是以大规模并行方式构建数据模型，都可以实现。Greenplum 语句计算大量可能的查询计划。为了生成最快的计划，GPORCA 会计算数千种备选查询 执行计划，并根据成本做出决策。它还能免去不必要的剖析步骤，从而缩短优化时间。与传统查询优化器相比，GPORCA 可以计算更多备选计划，因此能够优化更多查询。3 现代数据分析和商业智能 (BI) 生成的 SQL 查询往往带有相关子查询，内部子查询需要外部查询的相关知识。GPORCA 可 以生成不相关的计划，这种计划只需查询一次

orders WHERE order_date >= ‘Oct 20 2007’ AND order_date < ‘Oct 27 2007’ & orders 表数据均匀分布于各个节点 仅仅扫描 orders 表相关的分区 Segment 1A Segment 1B Segment 1C Segment 1D Segment 2A Segment 2B Segment 2C Segment Motion Table Scan Hash Hash Join Gather Motion SLICE 3 SLICE 1 SLICE 2 SEGMENT 2 SEGMENT 1 生成并行查询计划 12 Pivotal Confidential–Inter nal Use Only master segment1 segment2 QD process slice 3 QE process process slice 1 QE process slice 2 QE process slice 1 QE process slice 2 gang gang gang 执行并行计划 13 Pivotal Confidential–Inter nal Use Only 多态存储 Ÿ 列存储更适合压缩 Ÿ 查询列子集时速度快 Ÿ 不同列可以使用不同压缩方式: gzip

JDBC、ODBC、PHP、Python、命令⾏ Sql 等⽅式访问 UDW 2. Master Node：访问 UDW 数据仓库的⼊⼝ 接收客⼾端的连接请求 负责权限认证 处理 SQL 命令 调度分发执⾏计划 汇总 Segment 的执⾏结果并将结果返回给客⼾端 3. Compute Node： Compute Node 管理节点的计算和存储资源 每个 Compute Node 由多个 Segment dw.cn-bj.ufileos.com/SQL%20Workbench%3AJ%20%E8%AE%BF%E9%97%AE%20udw.pdf 2、数据库管理 、数据库管理 当你成功连接上数据库后，你可以创建你的第⼀个数据库（但这不是必须的，你也使⽤默认创建的数据库来作为你的业务数据库）。下⾯的操作以 psql ⽅式连接到 udw 为例。 2.1 创建数据库 创建数据库 create database UDW⽀持⾏式存储、列式存储。 ⾏存储的应⽤场景： 表数据在载⼊后经常 update; 表数据经常 insert； 查询中选择⼤部分的列； 列存储的应⽤场景： 列存储⼀般适⽤于宽表（即字段⾮常多的表）。在使⽤列存储时，同⼀个字段的数据连续保存在⼀个物理⽂件中，所以列存储的压缩率⽐普通压缩表的压缩率要⾼很多，另外在多数字段中筛 选其中⼏个字段中，需要扫描的数据量很⼩，扫描速度⽐较快。因此，列存储尤其适合在宽表中对

FROM orders JOIN customer USING (cust_id) WHERE date=2008; 生成并行查询计划 8 Pivotal Confidential–Internal Use Only 执行并行计划 Standby Master … Master Host Interconnect Segment Host Node1 Segment SELECT COUNT(*) FROM orders WHERE order_date >= ‘Oct 1 2007’ AND order_date <= ‘Oct 31 2007’ 仅仅扫描 orders 表2017年十月份数据所在的分区C Segment 1A Segment 1B Segment 1C Segment 1D Segment 2A Segment 2B Segment 最长时延 插入速度 9.8亿 18 4 12 16 500ms 170ms 1100ms 300万/s 展望 Greenplum 6.x/7 ■ PostgreSQL合并：BRIN索引和并行扫描 ■ 锁和事务的优化 ■ 磁盘IO的资源管理 ■ 更多思路？ 资源 ■ 中文社区：http://greenplum.cn ■ 文档：https://gpdb.docs.pivotal.i

资产组合分析 客户报表 电汇通知 分部记分卡 客户关系管理、收 购和盈利率 欺诈检测 欺诈分析 客户流失分析 响应时间 流量分析 产品关联/捆绑 零售 存储运营分析 客户忠诚度计划 协作规划和预估 预防亏损 优化供应链 当今的数据仓库方案 基于硬件 专有，昂贵 不可扩展 针对OLTP进行了优化 主流 10 数据库行业所面临的挑战 0 1 2 3 4 rows – D - 75042462 rows – E - 2521897 rows 结论：超过6亿条历史数据导入，用时少于1.5小时，性能非常卓越。 • 全表扫描测试 – DWA测试环境：针对表C（372844366 rows）进行全表扫描，历时少于1.5 分钟。 – 客户投产环境：针对表C的一个子表（记录数约为C表的1/10） 进行全表扫 描，历时超过20分钟。 结论：如果采用DWA替代现有环境，获得超过120倍的性能提升。

superuser_reserved_connections 50 NA Instance实例数的配置建议 • Instance是GPDB的最小并行单元，每个Segment 节点一般配置4~8个Instance，初始化完成后很 难修改，需要提前规划； • 每个Instance都是一套独立的进程，当客户端 发起一个请求时，每个Instance都将FORK子进 程并行工作； • 对于并发请求高、面向于复杂的灵活查询的系 M16 M17 M18 M19 M20 M21 M23 M24 M22 统计信息收集  对于系统表和用户表需要收集统计信息，GPDB的查询计划是cost base的，统计信息的准确性对查询 计划的优劣有很大影响；  对于字段数较多的表，可关闭gp_autostate_mode (on_no_stats=>none)，仅对必要列执行Analyze， 只在结果中返回的列无需收集统计信息； 对系统字段执行Analyze 垃圾空间回收 • GPDB采用MVCC机制，UPDATE 或 DELETE并非物理删除，而只是对无效记 录做标记； • Update/delete操作后，数据库不会自动释放这些空间，这些垃圾空间的回收方 式： 1）Vacuum 2）Vacuum full 3）REORGANIZE • 不进行垃圾空间回收的影响 o 垃圾空间浪费存储空间

初始化Greenplum 集群 $ source env​.​sh $ gpinitsystem ​-​c gpinitsystem_config ​-​a # step 5. 初始化成功后，运行下面命令验证系统状态 $ psql ​-​l $ gpstate # step 6. 简单测试 $ createdb test $ psql test test​# CREATE 有时候单独执行各种命令没有问题，但是使用 SSH 执行时报错。 这通常是由于 ssh 改变了环境变量造成的，查看 .bash_profile, .bashrc, 发现 .bashrc 设 置了不同的默认 PGHOST，删除这个配置后就可以了。 2.2.6 不能连接到server：找不到domain socket ○ → PGOPTIONS='-c gp_session_role=utility' /Users/yyd student_name​,​ c​.​classname FROM students s​,​ classes c WHERE s​.​id​=​c​.​student_id 3.1 查询计划 其对应的查询计划如下所示： test=# explain SELECT s.name student_name, c.classname test-# FROM students s, classes