Confidential │ ©2021 VMware, Inc. Greenplum 分布式数 据库内核揭秘 Greenplum内核开发工程师 2022-03-16 李正龙 Confidential │ ©2021 VMware, Inc. Agenda 2 - Greenplum 分布式数据库简介 - Greenplum 集群化概述 - 分布式数据存储与多态存储 - 分布式查询优化器与执行器 Table)：默认存储方式，同时也是 PostgreSQL 的默认存储方式。支持高效的更新 和删除操作，通常用于 OLTP 。 l Append-Optimized 表：以追加的方式写入数据，有着极高的写入性能，通常用于存储数据仓 库中的事实数据，不适合做频繁的更新、删除操作。 l Append-Optimized, Column Oriented 表：即 AOCO 表，在 Append-Optimized 的基础之 上 Greenplum、PostgreSQL、MySQL 以及 Oracle 等主流数据库均采用拉模型。 拉模型的每个算子都实现了从下层节点获取一条元组的 GetNext 函数，每次调用该函数都会从下 层节点返回一条元组或者 EOF 的 NULL 指针。上层节点不断地调用 GetNext 函数从下层节点获 取数据，直至数据全部获取完毕。 火山模型 postgres=# explain select

中国于2008年12月正式成立. 2010/4/8 官方网站： www.greenplum.com www.greenplum-china.com Greenplum：简介 Greenplum数据引擎软件为新一代数 据仓库所需的大规模数据和复杂查询功 能所设计 3 推动数据依赖型企业的发展 全球各地的一些Greenplum客户 4 亚太地区 欧洲、中东、非洲 北美 中国的客户 5 金融 交通 互联网 通过实体整合提供企业级数据访问功能 • 灵活的扩展和配置降低了投资的平均风险 源文件 源数据 源数据 源文件 数据仓库和分析应 用程序 Greenplum数据架构 商用硬件集群 分析 数据 市场 企业数 据仓库 企业数据集合：主要的优势 • 实体整合 • 提高服务器使用率 • 降低总硬件成本 • 降低能量成本 • 可以预估的服务等级 • 确保关键任务的可靠性 • 最出色的性能 • 高度灵活性 在数据增长的同时确保 高性能分析 统一的分析处理功能 • 为数据仓库、市场、 ELT、文本挖掘、统计 运算提供统一的平台 • 可以使用SQL、 MapReduce、R等在 所有层次上对任何数 据进行并行分析 19 通过经济的方案扩展 到千万亿字节规模 • 不用担心数据增长或 者开始的规模太小 • 在商用硬件上通过线 性、经济的方式扩展 Greenplum数据引擎体系 主机

售后支持，帮助我们的 Greenplum 用户解决生产需求和技术问题，我们坚持提供最专 业的建议和解决方案，提供最专业的技术支持服务，提供最专业的落地实施支持。 十多年来，参与过的项目不计其数，有 POC 测试，有开发支持，有故障支持，有 长期驻场支持，有临时的功能支持，甚至可能会作为用户看不见的后端支持，总之，我 们的目标是，努力解决用户的一切不违背自然规律的诉求，我们跟随着 Greenplum ........................................................................................ - 17 - 网络层冗余 ................................................................................................. 18616691889) 编写：陈淼 - 13 - Master 的连接数是有限的，缺省值为 250 个，如果要大规模提升连接的可用数 量，可以配置使用 GP 自带的 pgbouncer 连接池，这对于一些应用场景会很有帮助， 例如 SAS 等软件连接 GP 时，由于这些软件自身无法严格限制连接数，pgbouncer 会 是一个有效的缓解连接数过大的方案，例如按照如下方式进行配置：

性能却远远超过传统高 昂的专有系统。 Big Date2.indd 2 16-11-22 下午3:38 Greenplum 精粹文集 3 大家都知道 Greenplum 的数据库引擎层是基于著名的开源数据库 Postgresql的（下面会分析为什么采用Postgresql，而不是mysql等等）， 但是 Postgresql 是单实例数据库，怎么能在多个 X86 服务器上运行多 个 Postgresql 作为实例（该实例非 Oracle实例概念，这里指的是一个分布式子库架构在Interconnect下）， 在 Interconnect 的指挥协调下，数十个甚至数千个 Sub Postgresql 数 据库实例同时开展并行计算。而且，这些 Postgresql 之间采用 share- nothing 无共享架构，从而更将这种并行计算能力发挥到极致，除此之 外，MPP 采用两阶段提交和全局事务管理机制来保证集群上分布式事 单个节点上运行能力比其它数据库也快很多，如果运行在 多节点上，其提供性能几乎是线性的增长，这样一个集群提供的性能 能够很轻易的达到传统数据库的数百倍甚至数千倍，所管理数据存储 规模达到 100TB~ 数 PB，而你在硬件上的投入，仅仅是数台一般的 X86 服务器和普通的万兆交换机。 Big Date2.indd 6 16-11-22 下午3:38 Greenplum 精粹文集 7

⼯工作原理理 2017.thegiac.com C API (Greenplum, PostgreSQL, HAWQ) 底层抽象层 (数组操作、类型转换、数值计算库等) 数据库内建函 数 ⽤用户接⼝口 ⾼高层抽象层 (迭代控制器器) 内循环函数 (实现机器器学习逻辑) Python SQL C++ MADlib 架构 2017.thegiac

Ø事务大，频率相对小，并发低 • 未来的数据 —— 趋势分析 Ø非实时，离线+在线流系统，趋势分析 Ø算法分析，持续计算 5 数据仓库体系架构 OLAP场景举例 • 业务相关场景 Ø用户状态 （注册数，活跃数，并发量，峰值） Ø金币状态 Ø道具/物品状态 Ø对账状态 Ø活动反馈 • 架构相关场景 Ø不同数据量，不同事务特点，不同查询需求 Ø历史数据归档与冷热分离 Ø实时与延时需求的权衡 6 数据仓库体系架构 数据来源为OLTP库，针对小数据量传输和计算，部分实时交互操作 Ø 以对账业务为主，统计计算为辅 • 公司IDC_02机房Greenplum体系 Ø 针对数据来源主要是kfk产生csv文件的业务，不直接从数据库传数 Ø 以重点业务线、活动数据、非OLTP业务数据的任务计算为主 • 公司IDC_03机房Greenplum体系 Ø 数据来源来源为OTLP库库，针对大数据量传输和计算，采用T+1方式 Ø 以核心业务的数据计算、统计为主 Ø 列存储表 Ø 多种表类型结合 • 表的命名 Ø GP内所有名称都小写 Ø table_name命名要符合命名规则，做到见名知义 36 Greenplum开发规范 用户与权限规范 • 四层授权保保障 Ø 角色 role ： 管理数据库内对象权限 Ø 用户 user ： 用户认证权限 Ø pg_hba.conf ： 实例权限配置文件 Ø iptables : 防火墙IP访问配置策略 •

问题三：合并阶段，如何减少合并顺串过程中磁盘的读取的顺串数量。 归并排序的三个问题 31 ● 多路归并排序 32 ● 以两路归并排序为例，需要使用4个文件分别作为输入和输出文件来存储顺串， 两路归并排序需要文件中的顺串数呈现均匀的分布 多路归并排序 文件1 文件2 文件3 文件4 32 32 0 0 0 0 16(2) 16(2) 8(4) 8(4) 0 0 0 0 4(8) 4(8) 2(16) 2(16) 顺串进行归并排序，排序结果写入输出缓冲区的顺串。此时每个输入缓冲区的 顺串数减1，输出缓冲区顺串数加1。 ● 3. 如果任何一个输入缓冲区的顺串数都大于0，重复第2步。 ● 4. 如果所有缓冲区的顺串数和大于1，选取顺串数为0的输入缓冲区作为新的输 出缓冲区，将原输出缓冲区设置为新的输入缓冲区，重复第2步。 ● 5. 如果所有缓冲区的顺串数和为1，则该顺串就是排好序的元组，算法结束。 多相归并排序 34 34 ● 同样以4个文件为假设，多相归并排序使用3个文件作为输入文件，1个文件作为 输出文件。多相归并排序需要文件中的顺串数呈现不均匀的分布 多相归并排序 文件1 文件2 文件3 文件4 24 20 13 0 11 7 0 13(3) 4 0 7(5) 6(3) 0 4(9) 3(5) 2(3) 2(17) 2(9) 1(5) 0 1(17) 1(9) 0 1(31) 0 0 1(57)

Greenplum运维常用命令  Greenplum日常检查和故障处理  Greenplum项目经验分享 内核参数  通常情况下，内核参数按照GPDB安装手册配置，如需要增加连接数支持，以下参数需要增大  kernel.shmmax = 1000000000  kernel.sem = 250 512000 100 2048  Redhat 6.2以后，内核增 GPDB最佳实践所推荐的对象管理要求是：一个数据库内对象不要超过10 0000个  最佳实践是出于对系统性能和稳定性因素建议对pg_class 所维护的对象数进行约束  减少对象数的方法： – 提高分区粒度 – 避免大范围使用列存储  pg_class对象数如果不进行约束，可能会产生以下问题： – gprecoverseg –F效率低，数据库实例修复如果增量同步失败，我们一般会建议使用gprecoverseg –F进行全量同 步，全量同步是在两个节点之间全量拷贝文件，超过10 0000个对象，在数据目录下地文件数会可能达到上百万 个档，这些文件的拷贝需要花费很长时间 – 使用gpexpand扩容节点时，对象数多，对应到每个实例下的文件数非常多，将这些目的档重分布到新扩展的节 点时间会很长 – 系统表（pg_class,pg_attribute）太大，影响系统工作效率 – 系统元数据检查pg_checkcat等工具运行时间比较长

个master主机和四个segment主机，master和segment虚拟主机的配置信息如下 master segment 虚拟机类型 n1-standard-16 n1-standard-8 CPU核数 16 8 内存大小（GB） 60 30 CPU平台 Intel Haswell 存储类型 SSD persistent disk 存储大小（GB） 512 Linux发行版 Ubuntu Linux Use Only TPC-B基准测试：SELECT 表‘SALES’ 表‘SALES’ ■ 3.5倍的TPS提升 ■ master CPU使用率大幅提高 ■ TPS随着master CPU核数增加同 步提高 ■ 22万 TPS （192核单机部署 ，master+18 segments） 34 Pivotal Confidential–Internal Use Only TPC-B基准测试：UPDATE RLE • 访问多列时速度快 • 支持高效更新和删除 • AO 主要为插入而优化 表‘SALES’ 11月 列存储 行存储 7月 一年前 二年前 外部表 • 历史数据和不常访问的数 据存储在 HDFS 或者其他 外部系统中 • 无缝查询所有数据 • Text, CSV, Binary, Avro, Parquet 格式 6月 5月 10月 9月 8月 用户自定义数据存储格式

pruning calculating optimizing Data (Encrypted) TDE key GPDB数据透明加解密流程 秘钥管理 GPDB透明加密解析 GPDB TDE 使用三层key结构 • Master key: 加解密 major keys • Major keys: 加解密对应的 object keys • Object keys: 加解密对应的数据文件 秘钥管理 • 加密的major key会被送进KMS中，由master key来解密，KMS只返回解密后的Major key. • 所有的object keys和major keys 存储于数据库本地. 三层key结构 GPDB透明加密解析 Master Key Major Keys Object Keys Encrypted table files Encrypted log files Encrypted