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

............................................................................................. 10 集群在线扩容 .............................................................................................. ................................................................................... 10 Greenplum 集群多站点复制 ............................................................................................. KubeOS：云原生场景，实现 OS 容器化部署、运维，提供与业务容器一致的基于 K8S 的管理体验。 • 安全容器方案：iSulad+shimv2+StratoVirt 安全容器方案，相比传统 docker+qemu 方案，底噪和启动时间 优化 40%。 • 双平面部署工具 eqqo：ARM/X86 双平面混合集群 0S 高效一键式安装，百节点部署时间<15min。 3. 探索场景创新

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

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

Ø历史数据归档与冷热分离 Ø实时与延时需求的权衡 6 数据仓库体系架构 数据流转过程 • 1 业务数据的产生 —— OLTP • 2 业务数据的中转 —— ETL服务器 • 3 数据的存储和计算 —— OLAP集群 • 4 结果数据的展现 —— 数据集市 • 5 访问接口的封装 —— API接口服务器 • 6 最终数据的显示 —— 前端界面 • 7 结果数据的交互 —— OLTP，趋势分析 • 8 OLAP数据流转 Greenplum集群现状概述 • 三大Greenplum集群体系 Ø 公司IDC_01机房Greenplum体系 Ø 公司IDC_02机房Greenplum体系 Ø 公司IDC_03机房Greenplum体系 • 服务器资源 Ø 三大Greenplum集群，共用 422 个postgresql实例 Ø 实例分布成为 28 个Greenplum集群或postgresql单实例 • 服务器资源 Ø 三大Greenplum集群，共使用 三大Greenplum集群，共使用 51 台服务器资源 Ø 12台虚拟机，39台物理机 17 Greenplum现状说明 三大Greenplum集群定位分类 • 公司IDC_01机房Greenplum体系 Ø 公司第一套Greenplum集群，网络环境为千兆网 Ø 数据来源为OLTP库，针对小数据量传输和计算，部分实时交互操作 Ø 以对账业务为主，统计计算为辅 • 公司IDC_02机房Greenplum体系

发起一个请求时，每个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

数据库：ANSI SQL 2008 标准，OLAP，JDBC/ODBC Ÿ 支持ACID、分布式事务 Ÿ 分布式数据库：线性扩展，支持上百物理节点 Ÿ 企业级数据库：全球大客户超过 1000+ 安装集群 Ÿ 百万行源代码，超过10年的全球研发投入 Ÿ 开源数据库(greenplum.org)，良性生态系统 5 Pivotal Confidential–Inter nal Use Only 5 Pivotal Confidential–Inter nal Use Only MPP(大规模并行处理）无共享体系架构 从主节点 … 主节点 SQL • 主节点和从主节点，主节点负责协调整个集群 • 一个数据节点可以配置多个节点实例（Segment Instances) • 节点实例并行处理查询（SQL） • 数据节点有自己的CPU、磁盘和 内存（Share nothing） • 高速Interconnect处理持续 Use Only 调度器 本地存储 主节点Segment 系统表 分布式事务 Interconnect 执行器 解析器 发送查询计划给各 个Segments 分配处理查询需要 的集群资源，收集 并返回结果给客户 端 主节点 Segment 实例 本地事务 执行器 系统表 本地存储 Segment 主机 Segment 实例 Local TM 执行器Executor

Transition 函数 操作一小批数据并更新 模型状态 1 Merge 函数 2 Final函数 3 Segment 1 19 Madlib: PageRank性能 Greenplum集群: ● 1 master ● 4*6 segment 50亿条链接 (1K) (10K) (100K) (1M) (10M) (100M) Note: log-log scale (100s) content below this 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 Pivotal Confidential–Internal Use Only TPC-B基准测试：环境 基于谷歌云平台（Google Cloud Platform，简称GCP），为5个虚拟主机的集群，包含一 个master主机和四个segment主机，master和segment虚拟主机的配置信息如下 master segment 虚拟机类型 n1-standard-16 n1-standard-8

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

Greenplum VS hadoop 比较项 Greenplum Hadoop+hive 软件性质 商业软件 开源 集群规模 一般在100台以下 可以到上万台。 性能 在100台以下时，性能 比hadoop好。 单个SQL可以做到秒级 别 集群规模越大，总体性 能越好。 单个SQL最少也有数十 秒。 SQL的支持程度 支持完善，几乎所有 PostgreSQL支持的SQL， 器上。而 Greenplum4.0版本增加了功能，当备份节点坏的时 候，主节点可以把增量数据记下来，这样当备份节点的 主机恢复时，只需要恢复增量数据就可以了。 要让原先已offline的节点再加入集群中，需要重启集 群。 Greenplum中的高可用方案 对于Greenplum 3.X的版本，segment 的primary与 mirror之间是做的逻辑同步，mirror端的数据库实际上 并行数据装载 Greenplum Database’s parallel file server(gpfdist),可 以达到1小时装载2T数据。 GP的工作负载的资源控制 GP提供了对工作负载和资源控制的功能。 在GP可以建一个资源队列（resource queue)，然后把 用户加入到这个队列中，然后就可以控制： 1. 所有活动的SQL的cost值最多是多少？ 2. 活动的SQL最多是多少个