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 – Resource Queue • Memory – Chaotic – 没有严格资源隔离 – 第三方库的malloc 2017 年象行中国（杭州 站）第一期 Resource Group • SQL语句并发控制 => 事务并发控制 • 基于cost的并发控制 • 基于优先级的CPU控制 => 精确CPU比例 • 内存控制 => 严格资源隔离 2017 年象行中国（杭州 站）第一期 Running Example

.................... - 45 - 第六章：资源管理 .................................................................................................................... - 46 - 使用资源组................................ ........................................ - 46 - 资源组基于角色或基于外部组件 ............................................................................ - 47 - 资源组的属性 ............................................ ........................... - 48 - 配置与使用资源组 .................................................................................................... - 57 - 监控资源组状态 ......................................

AGENDA 云数据库背景 云数据库实现方案 Greenplum on Kubernetes Greenplum Operator 总结 云数据库背景 云数据库背景 ● 资源变化 ○ 本地资源 → 云 ○ 静态资源 → 弹性需求 ● 数据变化 ○ 内部数据 → 多数据源 ○ 数据规模 → 不易预测 ○ 数据格式 → 半结构化/无模式 ○ 数据隔离 → 数据共享 ● 云数据库市场巨大 云数据库市场巨大 ● 云数据库增速巨大 ● DBasS的需求 ● 跨云的需求 云数据库实现方案 云数据库需求 ● DBasS ○ 自动化运维 ○ 自动化调优 ● 弹性资源管理 ○ 存储资源 ○ 计算资源 ● 安全 ○ 用户数据 ○ 临时文件 ○ 网络传输 ○ 权限控制 ● 跨云 ○ 公有云 ○ 私有云 云数据库实现方案 ● 全新数据库 ○ Snowflake ● Instance Segment 5 (Mirror) 容器化Greenplum ? + = 容器化Greenplum ● 容器粒度 ○ Segment主机 VS. Segment实例 ● 容器资源分配 ○ CPU ○ 内存 ○ 磁盘 ● 容器间网络互联 ○ 本机网络 ○ 跨机网络 ● 容器化Greenplum部署策略 ○ Master部署策略 ○ Primary Segment部署策略

车轮一样，经过几十年磨砺，数据库引擎技术已经非常成熟，大可 不必去重新设计开发，而且把数据库底层交给其它专业化组织来开 发（对应到 Postgresql 就是社区），还可充分利用到社区的源源不 断的创新能力和资源，让产品保持持续旺盛的生命力。 这也是我们在用户选型时，通常建议用户考察一下底层的技术支撑 是不是有好的组织和社区支持的原因，如果缺乏这方面的有力支持 或独自闭门造轮，那就有理由为那个车的前途感到担忧，一个简单 ·行、列混合存储 ·数据表多级分区 ·Bitmap 索引 ·Hadoop 外部表 ·Gptext 全文检索 ·并行查询计划优化器和 Orca 优化器 ·Primary/Mirror 镜像保护机制 ·资源队列管理 ·WEB/Brower 监控 Big Date2.indd 7 16-11-22 下午3:38 8 3. Greenplum 的艺术 -- Parallel Everything 都运转起来，无共享架构将这种并行处理发挥到极致。 相比一些其它传统数据仓库的 Sharedisk 架构，后者最大瓶颈就是在 IO 吞吐上，在大规模数据处理时，IO 无法及时 feed 数据给到 CPU， CPU 资源处于 wait 空转状态，无法充分利用系统资源，导致 SQL 效 率低下： 一台内置 16 块 SAS 盘的 X86 服务器，每秒的 IO 数据扫描性能约在 2000MB/s 左右，可以想象，20 台这样的服务器构成的机群

发起一个请求时，每个Instance都将FORK子进 程并行工作； • 对于并发请求高、面向于复杂的灵活查询的系 统，建议每个Segment配置4个或以下Instance， 这样来保证每个Instance所需资源，保证系统 系统运行稳定性，例如，减少OOM发生的概率； • 对于以批处理、串行工作为主的系统，可以配 置到8个Instance，这样可以尽可能的发挥每个 CPU的处理性能。 Master 优化查询以减少内存的消耗  在资源队列中降低查询的并发数  降低GP集群中单节点的Segment Instance数量  增加机器的内存  检查gp_vmem_protect_limit 参数, 确保其不要超过安全的最大值  在会话层面降低statement_mem 参数的设定值  在数据库层面降低statement_mem参数的设定值  在资源队列中限制内存使用量 physical_memory_in_MB ) / #_of_primary_segments X =1~1.5，建议采用1，避免过多占用OS的内存.  调整资源队列中MEMORY_LIMIT的总和小于 gp_vmem_protect_limit *0.9.  调整资源中的Active_statement和Max_cost，CCB的参考值如下： – Max_Cost :30亿 – Active_Statements:30

OLTP数据库 OLAP数据仓库 ■ 实时性 ■ 数据同步复杂性 ■ 应用复杂性 HTAP HTAP = ? ■ 卓越的OLAP特性 ■ 出色的OLTP特性 ■ 多态存储 ■ 有效的并发和资源管理 OLTP-OLAP独立部署 OLTP数据库 OLAP数据仓库 ■ 实时性 ■ 数据同步复杂性 ■ 应用复杂性 43 Pivotal Confidential–Internal Use 9月 8月 用户自定义数据存储格式 并发管理 ■ pgbouncer ■ 资源组（resource group） create resource group rg1 (cpu_rate_limit=20, memory_limit=10, concurrency=5) 资源管理：CPU使用受限和超限 资源管理：CPU，短查询延迟 ■ 更稳定延迟，CPUSET特性：create resource resource group rg1 (cpu_set=’4,5’, memory_limit=10, concurrency=5) 资源管理：内存 ■ 隔离 ○ segment级 ○ 资源组 ○ 查询 ■ 共享 ○ 全局segment级 ○ 资源组内 资源管理：磁盘配额 SELCT diskquota.set_schema_quota ('s1', '1 MB'); SELECT

.......................................................................................7 Greenplum资源组和Workload Manager ................................................................................ 的功能逐渐增多，传统查询优化器能够在性能上胜出 的情况将变得极为罕见。4 Greenplum资源组和Workload Manager 管理并发性能和用户资源分配是 Greenplum 的主要功能之一。这一版本不仅增强了 Workload Manager 的功能，还引入了 一种管理数据库查询的新方法——资源组，可让数据库管理员更好地控制用户活动，尤其是在 CPU 和内存管理方面。资 源组一经定义， 源组一经定义，便会将所有用户活动纳入管理范围，包括超级用户。某个超级用户执行的所有语句都会路由至一个默认资 源组，管理员可以根据需要调整该资源组，增加或减少其系统资源。如果队列中没有可用于某个查询的空位，或者内存不 足以运行该查询，它会自动排队，直到有能够成功执行的资源为止。 1. Marshall Presser，Data Warehousing with Greenplum:Open Source Massively

公司IDC_02机房Greenplum体系 Ø 公司IDC_03机房Greenplum体系 • 服务器资源 Ø 三大Greenplum集群，共用 422 个postgresql实例 Ø 实例分布成为 28 个Greenplum集群或postgresql单实例 • 服务器资源 Ø 三大Greenplum集群，共使用 51 台服务器资源 Ø 12台虚拟机，39台物理机 17 Greenplum现状说明 三大Greenplum集群定位分类 环境创建与部署 • 部署流程 Ø 规划部署方案 Ø 准备硬件资源 Ø 修改系统参数 Ø 安装 Greenplum 软件 / postgresql软件 Ø 初始化实例 Ø 修改实例参数文件 Ø 初始化业务所需库表环境、用户环境 Ø 加载数据 Ø 业务程序访问 23 Greenplum运维体系 环境创建与部署 • 部署注意点 Ø 资源要充足（ETL，管理节点，数据节点，数据集市） Ø 万兆网络 一 Greenplum开发规范 五 Greenplum运维体系 四 Greenplum扩展规划 六 34 Greenplum开发规范 不规范容易出现的问题 • GP架构易出现问题 Ø 资源不足 Ø 连接、语句执行失败 Ø 多任务冲突 • 库表使用易出现问题 Ø 表定义过大 Ø 表类型单一 Ø 表的散列键不恰当 Ø 分区表的分区键性能不佳 • 加载易出现问题 Ø 文件加载出现特殊字符

Use Only 调度器 本地存储 主节点Segment 系统表 分布式事务 Interconnect 执行器 解析器 发送查询计划给各 个Segments 分配处理查询需要 的集群资源，收集 并返回结果给客户 端 主节点 Segment 实例 本地事务 执行器 系统表 本地存储 Segment 主机 Segment 实例 Local TM 执行器Executor nal Use Only 执行器 本地存储 主节点Segment 系统表 分布式事务 Interconnect 解析器 发送查询计划给各 个Segments 分配处理查询需要 的集群资源，收集 并返回结果给客户 端 主节点 Segment 实例 本地事务 执行器 系统表 本地存储 Segment 主机 Segment 实例 Local TM 执行器Executor Only Interconnect 本地存储 主节点Segment 系统表 分布式事务 Interconnect 解析器 发送查询计划给各 个Segments 分配处理查询需要 的集群资源，收集 并返回结果给客户 端 主节点 Segment 实例 本地事务 执行器 系统表 本地存储 Segment 主机 Segment 实例 Local TM 执行器Executor

一阶段提交不能保证 分布式事务的原子性 23 两阶段提交协议 ● Jim Gray等研究者在1978年提出了两阶段提交协议，用于保证分布式事务提交的原子性 ● 可以用于单机集中式系统，由事务管理器协调多个资源管理器；也可以用于分布式系 统，由一个全局的 事务管理器协调各个子系统的局部事务管理器完成两阶段提交 ● 广泛应用于商业分布式数据库 ❏ A节点是事务的协调者（coordinator） ❏ 日志落盘 协调者 参与者 发送prepare消息 ready 发送commit/abort消息 ack 阶段2 阶段1 25 2PC同样可以应用在单机系统上 协调者 资源管理器1 资源管理器2 资源管理器3 日志1 日志2 日志3 PREPARE / COMMIT / ROLLBACK 命令 参与者 读写操作 26 两阶段提交协议需要处理的故障 1. 参与者故障