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

gepage/enabled 一般不建议直接修改/boot/grub/grub.conf文件或者/boot/grub/menu.lst 常用数据库参数 参数名 Master节点值 Segment节点值 checkpoint_segments 32 32 max_connections 500 2500 max_prepared_transactions 500 Instance是GPDB的最小并行单元，每个Segment 节点一般配置4~8个Instance，初始化完成后很 难修改，需要提前规划； • 每个Instance都是一套独立的进程，当客户端 发起一个请求时，每个Instance都将FORK子进 程并行工作； • 对于并发请求高、面向于复杂的灵活查询的系 统，建议每个Segment配置4个或以下Instance， 这样来保证每个Instance所需资源，保证系统 系统运行稳定性，例如，减少OOM发生的概率； max_fsm_pages、max_fsm_relations放大这些参数  Vacuum Full/REORGANIZE：立即释放垃圾空间还给操作系统 Vacuum Full相当于碎片整理； Reorganize相当于重建表，数据表对应的文件名（pg_class -> relfilenode)将会发生改变。 Vacuum Full的处理性能非常低，一般情况下不

18616691889) 编写：陈淼 - 2 - 序言 术语约定 GP ： Greenplum 数据库 Master ： GP 的控制节点/实例 Standby ： GP 的备用控制节点/实例 Host(主机) ： GP 的一台独立的机器设备 Instance ： GP 的计算实例，很多时候也叫 Segment Primary ： ........................................................................................ - 11 - 管理节点：Master ........................................................................................... .................... - 45 - 第六章：资源管理 .................................................................................................................... - 46 - 使用资源组................................

Interconnect 这个核心软件组件。最终实现了对同一个集群中多 个 Postgresql 实例的高效协同和并行计算，Interconnect 承载了并行 查询计划生产和 Dispatch 分发（QD）、协调节点上 QE 执行器的并 行工作、负责数据分布、Pipeline 计算、镜像复制、健康探测等等诸 多任务。 在 Greenplum 开源以前，据说一些厂商也有开发 MPP 数据库的打算， 其中最难的部分就是在 车轮一样，经过几十年磨砺，数据库引擎技术已经非常成熟，大可 不必去重新设计开发，而且把数据库底层交给其它专业化组织来开 发（对应到 Postgresql 就是社区），还可充分利用到社区的源源不 断的创新能力和资源，让产品保持持续旺盛的生命力。 这也是我们在用户选型时，通常建议用户考察一下底层的技术支撑 是不是有好的组织和社区支持的原因，如果缺乏这方面的有力支持 或独自闭门造轮，那就有理由为那个车的前途感到担忧，一个简单 的最小并行单元不是节点层级，而是在 实例层级。安装过 Greenplum 的同学应该都看到每个实例都有自己 的 Postgresql 目录结构，都有各自的一套 Postgresql 数据库守护进 程（甚至可以通过 UT 模式进行单个实例的访问）。正因为如此，甚 至一个运行在单节点上的 GreenplumDB 也是一个小型的并行计算架 构，一般一个节点配置 6~8 个实例，相当于在一个节点上有 6~8 个

AGENDA 云数据库背景 云数据库实现方案 Greenplum on Kubernetes Greenplum Operator 总结 云数据库背景 云数据库背景 ● 资源变化 ○ 本地资源 → 云 ○ 静态资源 → 弹性需求 ● 数据变化 ○ 内部数据 → 多数据源 ○ 数据规模 → 不易预测 ○ 数据格式 → 半结构化/无模式 ○ 数据隔离 → 数据共享 ● 云数据库市场巨大 云数据库市场巨大 ● 云数据库增速巨大 ● DBasS的需求 ● 跨云的需求 云数据库实现方案 云数据库需求 ● DBasS ○ 自动化运维 ○ 自动化调优 ● 弹性资源管理 ○ 存储资源 ○ 计算资源 ● 安全 ○ 用户数据 ○ 临时文件 ○ 网络传输 ○ 权限控制 ● 跨云 ○ 公有云 ○ 私有云 云数据库实现方案 ● 全新数据库 ○ Snowflake ● Master节点和Standby Master节点 Greenplum 架构 Interconnect高速网络 Segment主机部署多个Segment实例 （Primary Segment和Mirror Segment） Greenplum 部署方案 ● Master节点和Standby Master分机部署 ● Primary Segment节点和Mirror Segment节点分机部署

segment mirror segment 6 Pivotal Confidential–Internal Use Only 数据分布: 并行化的根基 最重要的策略和目标是均匀分布数据到各个数据节点。 43 Oct 20 2005 12 64 Oct 20 2005 111 45 Oct 20 2005 42 46 Oct 20 2005 64 77 Oct 20 2005 32 48 Oct Use Only 执行并行计划 Standby Master … Master Host Interconnect Segment Host Node1 Segment Host Node2 Segment Host Node3 Segment Host NodeN Greenplum (MPP) Oracle (SMP) OLAP - Online Analytical line Source and Footnotes Guideline . PROD Space usage (compressed) 1. 24 个生产集群 2. 2个选项: 20个节点或 40个节点 3. 600+ 服务器, 13k+ 核, 81PB存储（增长 中） 4. 2.5PB 或 25PB 原始数据 按10x压缩率 1 2 3 4 Greenplum在摩根士丹利

...................................................................................... 11 Master 节点自动 Failover ....................................................................................... atoVirt 安全容器方案，相比传统 docker+qemu 方案，底噪和启动时间 优化 40%。 • 双平面部署工具 eqqo：ARM/X86 双平面混合集群 0S 高效一键式安装，百节点部署时间<15min。 3. 探索场景创新 边缘计算：发布面向边缘计算场景的版本 openEuler21.09Edae.集成 KubeEdae+边云协同框架，具备边云应用统一管 理和发放等基础能力。 、优异性能、环境适应性强在 MPP 数据库领域独占鳌头，基于 Shared Nothing 的 MPP 高性能系统架构，Greenplum 可以将 PB 级的数据仓库负 载分解，并使用所有的系统资源并行处理单个查询。同时 Greenplum 具备数据库 ACID 特性，运行符合 ANSI 标准 的 SQL，可以让服务器群集能够以单一数据超级计算机的方式运行，且性能比传统数据库或其他同类平台高出数十甚

创建好数据仓库之后怎么连接到UDW？ UDW⽀持从mysql导⼊数据吗？ HDFS/Hive与UDW之间可以导⼊导出数据吗？ UDW中怎么kill掉正在执⾏的SQL语句？ 如何通过外⽹访问UDW？ 节点扩容时数量有没有什么限制？ 数据仓库价格 数据仓库价格 ⽬录 Greenplum数据仓库 UDW Copyright © 2012-2021 UCloud 优刻得 5/206 概览 概览 产品架构 Client、Master Node 和 Compute Node 组成。基本组成部分的功能如下： 产品架构 Greenplum数据仓库 UDW Copyright © 2012-2021 UCloud 优刻得 7/206 1. Client：访问 UDW 的客⼾端 ⽀持通过 JDBC、ODBC、PHP、Python、命令⾏ Sql 等⽅式访问 UDW 2. Master Node：访问 UDW 数据仓库的⼊⼝ Compute Node： Compute Node 管理节点的计算和存储资源 每个 Compute Node 由多个 Segment 组成 Segment 负责业务数据的存储、⽤⼾ SQL 的执⾏ ⾼可⽤ ⾼可⽤ 产品架构 Greenplum数据仓库 UDW Copyright © 2012-2021 UCloud 优刻得 8/206 如上图所⽰： 1. Compute Node 中任⼀ Segment

GPDB：为大数据存储、计算、挖掘而设计 Ÿ 标准 SQL 数据库：ANSI SQL 2008 标准，OLAP，JDBC/ODBC Ÿ 支持ACID、分布式事务 Ÿ 分布式数据库：线性扩展，支持上百物理节点 Ÿ 企业级数据库：全球大客户超过 1000+ 安装集群 Ÿ 百万行源代码，超过10年的全球研发投入 Ÿ 开源数据库(greenplum.org)，良性生态系统 5 Pivotal Confidential–Inter Confidential–Inter nal Use Only MPP(大规模并行处理）无共享体系架构 从主节点 … 主节点 SQL • 主节点和从主节点，主节点负责协调整个集群 • 一个数据节点可以配置多个节点实例（Segment Instances) • 节点实例并行处理查询（SQL） • 数据节点有自己的CPU、磁盘和 内存（Share nothing） • 高速Interconnect处理持续 Segment Instance 节点1 Segment Host Segment Instance Segment Instance Segment Instance Segment Instance 节点2 Segment Host Segment Instance Segment Instance Segment Instance Segment Instance 节点3 Segment Host

• greenplum的架构特点 Ø MPP ShareNothing 海量并行处理+完全无共享 Ø cpu计算能力 Ø 数据从Disk上的I/O吞吐性能 Ø master管理节点 Ø segment数据节点 • greenplum的核心功能 Ø 无共享MPP Ø 多态存储 Ø 高效数据加载 （gpfdist+外部表，每小时4TB+） Ø 分布分区 Ø 数据压缩 Ø 外部访问 15 公司IDC_02机房Greenplum体系 Ø 公司IDC_03机房Greenplum体系 • 服务器资源 Ø 三大Greenplum集群，共用 422 个postgresql实例 Ø 实例分布成为 28 个Greenplum集群或postgresql单实例 • 服务器资源 Ø 三大Greenplum集群，共使用 51 台服务器资源 Ø 12台虚拟机，39台物理机 17 Greenplum现状说明 三大Greenplum集群定位分类 准备硬件资源 Ø 修改系统参数 Ø 安装 Greenplum 软件 / postgresql软件 Ø 初始化实例 Ø 修改实例参数文件 Ø 初始化业务所需库表环境、用户环境 Ø 加载数据 Ø 业务程序访问 23 Greenplum运维体系 环境创建与部署 • 部署注意点 Ø 资源要充足（ETL，管理节点，数据节点，数据集市） Ø 万兆网络 （网络环境对功能和性能的影响） Ø 节点规划 （数据节点6-10个segment节点）