2017 年象行中国（杭州 站）第一期 Greenplum资源管理器 姚珂男/Pivotal kyao@pivotal.io 2017 年象行中国（杭州 站）第一期 Agenda • Greenplum数据库 • Resource Queue • Resource Group 2017 年象行中国（杭州 站）第一期 Greenplum数据库 • 基于PostgreSQL • 分布式 corruption => PANIC 2017 年象行中国（杭州 站）第一期 Resource Queue • Cost is tricky – 没有明确的定义 – 不同优化器不一致 – 优化器不能被纳入资源管理器 2017 年象行中国（杭州 站）第一期 Resource Queue • Priority is rough – 不能精确控制CPU – CHECK_FOR_INTERRUPTS

.................................................................................. - 179 - 理解执行计划与分发 .............................................................................................. - 179 ............................................................................... - 182 - 关于 ORCA 优化器 ................................................................................................... 身元数据的数据表)，但不存储任何业务数据，业务数据只存储在 Instance 上。 Master 负责客户端的登录认证、SQL 命令接收并生成并行执行计划、对执行计划进行 优化、在 Instance 之间分发执行计划、整合 Instance 处理结果、将 Instance 的 处理结果汇总并反馈给客户端程序。 目前，GP 还不支持 Master 的自动故障切换，不过，已经有很多人适用工具或者 脚本的形式实现了

16-11-22 下午3:38 2 由此，业界认识到对于海量数据需要一种新的计算模式来支持，这种 模式就是可以支持 Scale-out 横向扩展的分布式并行数据计算技术。 当时，开放的X86服务器技术已经能很好的支持商用，借助高速网络（当 时是千兆以太网）组建的 X86 集群在整体上提供的计算能力已大幅高 于传统 SMP 主机，并且成本很低，横向的扩展性还可带来系统良好 的成长性。 问 题 来 是单实例数据库，怎么能在多个 X86 服务器上运行多 个实例且实现并行计算呢？为了这，Interconnnect 大神器出现了。在 那一年多的时间里，大咖们很大一部分精力都在不断的设计、优化、 开发 Interconnect 这个核心软件组件。最终实现了对同一个集群中多 个 Postgresql 实例的高效协同和并行计算，Interconnect 承载了并行 查询计划生产和 Dispatch 分发（QD）、协调节点上 QE QE 执行器的并 行工作、负责数据分布、Pipeline 计算、镜像复制、健康探测等等诸 多任务。 在 Greenplum 开源以前，据说一些厂商也有开发 MPP 数据库的打算， 其中最难的部分就是在 Interconnect 上遇到了障碍，可见这项技术的 关键性。 Greenplum 集群架构 Big Date2.indd 3 16-11-22 下午3:38 4 2. Greenplum

.............................................................................6 GPORCA：Pivotal 查询优化器更新 ................................................................................................. 有云和私有云）中，也适用不同的本地配置。其大规模并行处理 (MPP) SQL 的设计核心是一个称为 GPORCA 的新一代查 询优化器。GPORCA 专为满足在多结构数据环境中进行高级分析的需求而设计，能够处理多种并发混合工作负载的复杂查 询。与旧式 MPP 数据库中常用的传统 RDBMS 查询优化器相比，GPORCA 大幅度地提高了查询性能。 Pivotal Greenplum 5：新一代数据平台 作为重要的新版本，Pivotal 对大多数客户都很有帮助。Greenplum 解决方案的架构设计目的是管理 非常复杂的查询，以及为符合 ANSI 标准的 SQL 提供强有力的分析改进。通过自动对数据进行分区和并行运行查询，它让 服务器群集能够以单一数据超级计算机的方式运行，且性能比传统数据库或其他同类平台高出数十甚至数百倍。其多种分 析扩展功能支持 ANSI SQL，并通过封装扩展提供多种内置语言和附加功能。Greenplum 能够管理各种规模的数据卷，数

Greenplum架构: Master介绍 Master服务器是外面用户访问greenplum的入口。用户 都是连接master服务器的，对于外部用户来说，他并不 与segment host服务器发生任何关系，外部用户的网络 只需要与master服务器连通就可以了，不需要访问 segment host服务器。 所有的用户连接都是直接连接到master服务器上的。 Greenplum数据库是基于PostgreSQL数据库的，所以 分布 式数据库中的 所有元数据，如表结构定义、索引等等。但其并不存储 实际的数据，实际的数据是存储在segment 数据库 的。 master服务器接受从用户发来的连接，并做用户验证， 接收用户发来的sql，生成分布式执行计划，再把分布 执行计划分发到segment上执行，接收segment返回的 数据，最后返回给用户。 Greenplum架构: Segment介绍 Segment是数据的实际存储的地方，也是一个经过改造 活动的SQL最多是多少个 3. 控制活动的SQL的优先级（4.0的新功能） GP的查询处理 用户提交一个SQL到master，master解析这个SQL， 生成一个分布式的执行计划，然后把这个分布式的执行 计划分发到各个segment上，然后segment执行它自己 的特定数据集的本地数据库业务。 所有的数据库操作，如表扫描、表连接（joins)、聚集 （ aggregations），排序，这些操作都会在所有的

gp_bash_functions.sh 是内部一个被频繁调用执行系统命令的函数，可以通过 set -x 可以打印出所有执行的命令的详细信息。对调试 hang 问题很有效。 ● 在合适的代码处启用 Python 调试器，如果不知道什么地方合适，则在入口处。 3. Greenplum SQL执行流程概要 下面介绍下 Greenplum 中 SQL 执行的简单过程。例子中集群一个 Master 两个 Segments。 segment 上。 感兴趣的读者可以尝试把 stendent 的分布键改成其他字段，看看计划有什么变化。 3.2 查询执行 QD(Query Dispatcher) 将上面的并行计划分发到每个 segment 上执行。这个例子中一共有2个 segments。 查询计划包含2个slices，所以每个 segment 会启动 2 个 QE（Query Executor），一个 QE lldb 的 gui 命令可以使用一个简单的源代码浏览器查看当前正在执行的代码区域，以及执行 函数的相关变量。 通过简单的断点和单步执行，可以快速了解SQL的执行过程。譬如上面例子中可以看到 cdbdisp_dispatchToGang 在 ExecutorStart 之后、ExecutorRun 之前运行，用途是将 QD 优化好 的计划分发给 segments 执行。 4.2 调试 Segment

卓越的OLAP特性 列式存储 分区、压缩 高级特性 递归查询、窗口函数 集成分析 多格式、多语言 Madlib: 机器学习 数据库内并行模型训练和预测、分类 ORCA 复杂查询优化器 成熟稳定 完备生态、支撑核心生产系统 13 Pivotal Confidential–Internal Use Only 列式存储 表‘SALES’ 表‘SALES’ ■ 更适合压缩 ■ rank() OVER w FROM employees WINDOW w as (PARTITION BY department ORDER BY salary DESC) ORCA优化器 Common Table Expression and Recursive Queries 02 Efficiently Processing Complex Correlated 40个节点 3. 600+ 服务器, 13k+ 核, 81PB存储（增长 中） 4. 2.5PB 或 25PB 原始数据 按10x压缩率 1 2 3 4 Greenplum在摩根士丹利 OLTP - Online transaction processing - 联机事务处理 出色的OLTP特性 天生的优势 ● 行式存储 ● 索引 ● 直接分发 ● 完整的增删改 Greenplum

的文件数非常多，将这些目的档重分布到新扩展的节 点时间会很长 – 系统表（pg_class,pg_attribute）太大，影响系统工作效率 – 系统元数据检查pg_checkcat等工具运行时间比较长 物理模型经验分享 物理模型对于系统性能有很大影响，因此需要我们特别关注。 以下来自于在某大型银行的使用经验： 行存储和列存储： • 避免过多使用列存储的原因是防止小档数过多。 –m对应使用 -M fast | -f：停止数据库，中断所有数据库连接，回滚正在运行的事务  -u：不停止数据库，只加载pg_hba.conf 和postgresql.conf 中运行时参数，当改动参数配置时候使用。  -r： 重启数据库 Admin常用命令  查看实例配置和状态  select * from gp_segment_configuration order Center，是否有报警信息  检查standby同步状态 – 执行gpstate -f  检查Primary、mirror同步状态 – 执行gpstate -e  检查运行时间长的SQL – select*from pg_stat_activity order by query_start，检查是否有3~6个小时以上的SQL仍在运行  检查空间使用情况 –

©2021 VMware, Inc. Agenda 2 - Greenplum 分布式数据库简介 - Greenplum 集群化概述 - 分布式数据存储与多态存储 - 分布式查询优化器与执行器 - Greenplum 中文社区 3 Confidential │ ©2021 VMware, Inc. Greenplum 分布式数据库简介 Features Confidential PostgreSQL 所实现的大规模并行处理(MPP)开源数据平台，具有良好的弹性 和线性拓展能力，内置并行存储、并行通信、并行计算和并行优化功能，兼容 SQL 标准。拥有独 特的高效的 ORCA 优化器，具有强大、高效的 PB 级数据存储、处理和实时分析能力，同时支持 OLTP 型业务的混合负载。 Greenplum 分布式数据库简介 5 Confidential │ ©2021 VMware, Inc. Greenplum 分布式查询优化器 Motion Confidential │ ©2021 VMware, Inc. 16 当我们插入数据时，Coordinator 将会根据分布键以及分布策略将数据分布到不同的节点中去。那 么在查询时，就需要各个节点将数据处理完毕后发送至 Coordinator 节点并返回给客户端用户。 分布式查询优化器 l 对于普通查询，只需要将 Segment

Master 发起查询请求时，Master 节点上的 postmaster 进程将会 fork 出⼀个⼦进程，叫做 Query Dispatcher（分发 器），简称为 QD 进程 QD 进程会对收到的查询请求进⾏处理，包括解析原始查询语句、优化器优化以及⽣成分布式查询计划，然后将查询计划通过 libpq 库发送 给其它的 Segment 节点 Query Executor Segment