Greenplum开发规范 五 Greenplum运维体系 四 Greenplum扩展规划 六 3 数据仓库体系架构 业务数据与数据使用归类 时间维度：过去 - 现在 - 未来 （数据的生命周期） • “现在”的数据 —— OLTP • “过去”的数据 —— OLAP • “未来”的数据 —— 趋势分析 4 数据仓库体系架构 业务数据与数据特点 • 现在的数据 —— OLTP Ø 结果数据csv文件备份 Ø 结果数据到备份postgresql实例 28 Greenplum运维体系 数据库数据传输与同步 • 数据同步情况分类 Ø reader端与writer端 Ø 全量，id列增量，date列增量 Ø datax,csv,load,copy Ø 数据同步结果确认与显示 • 数据同步方式 Ø gpfdist+外部表 ： UMGW大表 Ø db_sync同步程序 ：

一直保持失败状态。失 败的 Primary 可以在系统处于运行状态下被恢复回来。恢复进程仅仅复制失败期间发 生变化的增量差异，当然，如果失败时间太久或者因失败的 Instance 文件有损毁， 将需要全量恢复或者需要选择全量恢复。在 6 之前的版本，GP 的 Primary 和 Mirror 之间采用的是 filerep 的方式进行 block 级别的变化同步的机制，从 6 版本开始， 使用 WAL 复制，这将可以从根本上解决以往的 的值，这用于限制该资源 组可用的 CPU 的百分比。可以指定 MEMORY_LIMIT 为资源组配置专享内存配额的百分 比，如果 MEMORY_LIMIT 设置为 0，GP 将不会为该资源组配置专享内存，而是使用全 局共享内存来满足该资源组中的内存需求。 例如，创建一个名称为 rgroup1 的资源组，CPU 配额为 20，内存配额为 25，内 Greenplum Database 管理员指南 V6.2 rimary和Mirror指向不同的目录， 因为这样会有一个很大的问题，当出现Primary和Mirror的故障切换时，在做 gprecoverseg全量恢复时，GP数据库并不清楚软连接的目标是不同的，这个软连接 的信息是不会存储在系统表中的，做全量恢复时，只是按照对应Content活着的 Instance的信息去重建。 使用表空间存储 DB 对象 表、索引、甚至整

Kubernetes 101 Kubernetes 101 Master组件 Node组件 Kubernetes存储资源 PV ● PersistentVolume ○ 表示一种存储资源，独立容器生命周期 ○ AWSElasticBlockStore, AzureDisk, AzureFile, GCEPersistentDisk, CephFS, Glusterfs, NFS, Cinder

VMware, Inc. 13 分布式执行和事务 Ø 火山/流水线模型 Ø QD(query dispatcher)负责下发查询，QE(query executor)负责执行查询 Ø 查询的生命周期: 1) 客户端连接coordinator, coordinator fork出QD 2) QD 拿到纯文本的查询，解析、优化、生成一个树形结构的分布式计划 3) QD 生成slice结构，

com/s/zgCfcbMKOJRYROdxjW6RNA 14 Compare Products 需求：利用GP自建数据仓库面临的数据集成问题 ➢ 支持MySQL的全量以及增量备份 ➢ 支持Oracle的全量以及增量备份 ➢ 支持SQL Server的全量同步 ➢ 对于增量备份可以支持准实时的同步也可以支持延时同步 ➢ 同步软件不会对源库造成负载上升的问题 ➢ 同步中断后能够记录中断点，在下次同步时可以自动从中断点开始继续同步数据 Compare Products 参考：https://mp.weixin.qq.com/s/zgCfcbMKOJRYROdxjW6RNA 16 Compare Products ➢ 支持全量同步，但增量同步延时，数据量越大，延时更久。 ➢ JDBC驱动强依赖。 ➢ 版本更新不及时，对GreenPlum新版本无法持续性支持，不稳定。 ➢ 需开发人员支持，二次开发或脚本支持，开发时间成本和人力成本高。 参考：https://mp.weixin.qq.com/s/zgCfcbMKOJRYROdxjW6RNA 18 Compare Products ➢ 案例需求全部满足 ➢ 生产环境实验同步 ➢ 支持全量同步、增量实时同步，无延时 ➢ 支持多种数据同构、异构数据同步 ➢ 过滤器制作规则处理异常数据 ➢ 可以达到BI系统的实时要求 ➢ 网络带宽利用率低，且支持数据的安全传输 一些事前没有考虑到的问题：

pg_class对象数如果不进行约束，可能会产生以下问题： – gprecoverseg –F效率低，数据库实例修复如果增量同步失败，我们一般会建议使用gprecoverseg –F进行全量同 步，全量同步是在两个节点之间全量拷贝文件，超过10 0000个对象，在数据目录下地文件数会可能达到上百万 个档，这些文件的拷贝需要花费很长时间 – 使用gpexpand扩容节点时，对象数多，对应到每个实例下 物理模型对于系统性能有很大影响，因此需要我们特别关注。 以下来自于在某大型银行的使用经验： 行存储和列存储： • 避免过多使用列存储的原因是防止小档数过多。 • 列存储能够提升查询性能，对于更新和全字段类操作性能反而会下降 • 对于少数频繁查询的宽表，例如交易表、帐户表、客户表等采用列存储，其它表采用行存储 数据压缩： • 在金融业，行压缩的数据压缩比在1:6左右，一般采用zlib5级压缩

E - 2521897 rows 结论：超过6亿条历史数据导入，用时少于1.5小时，性能非常卓越。 • 全表扫描测试 – DWA测试环境：针对表C（372844366 rows）进行全表扫描，历时少于1.5 分钟。 – 客户投产环境：针对表C的一个子表（记录数约为C表的1/10） 进行全表扫 描，历时超过20分钟。 结论：如果采用DWA替代现有环境，获得超过120倍的性能提升。 • 真实应用测试

开发指南 开发指南 1、连接数据库 2、数据库管理 3、模式管理 4、表格设计 5、加载数据 6、分区表 7、序列 8、索引 9、 ANALYZE/VACUUM 10、常⽤SQL⼤全 12、常⽤SQL命令 13、⽤⼾⾃定义函数 ⽬录 Greenplum数据仓库 UDW Copyright © 2012-2021 UCloud 优刻得 3/206 128 132 132 [VERBOSE] [table] VACUUM [FULL] [FREEZE] [VERBOSE] ANALYZE [table [(column [, ...] )]] 10、常⽤ 、常⽤SQL⼤全 ⼤全 1. psql客⼾端常⽤ \h 获取SQL命令的帮助 \? 获取psql命令的帮助 \q 退出 2. ⼀般选项 \c [数据库名]－[⽤⼾名] 连接到新数据库 \cd [⽬录名] 改变当前的⼯作⽬录 数据仓库这样的分布式数据库系统中，索引的使⽤需要更加谨慎。 索引会增加数据库系统的运⾏开销，它们占⽤存储空间并且在数据更新时，需要额外的维护⼯作。请确保查询集合在使⽤您创建的索引后，性能得到了改善（和全表顺序扫描相⽐）。可以使⽤ EXPLAIN 命令来确认索引是否被使⽤。 创建索引时，需要注意下⾯的问题点： 1. 查询特点：索引对于查询只返回单条记录或者较少的数据集时，性能提升明显。 2. 压缩表：对于压缩的

多种数据分析和机器学习算法。MADlib 提供 SQL 接口进行数据分析，大大降低了数据分 析的门槛；MADlib 内建于数据库内，使用 MPP 的优势，提高了分析的效率；MADlib 可 以在全量数据而不是抽样数据上进行分析，提高了精度。 ● 开放源代码且持续大力投入的平台： 2017 年 Pivotal 在 github 的开源贡献列表中全球排 名第四左右。 采用开源方案，不担心后门 Pivotal 正式把投资超过 10 年的 Greenplum 开源，采用 Apache 2 协议，成为世界 上第一款成熟的开源 MPP 数据库。开源之后，Greenplum 社区发展活跃，短短 2 年左右，在全 球有上百来自美国、中国、俄罗斯、日本、英国、德国、芬兰、瑞士等国家的贡献者，获得社会 各界的广泛关注。其中 Greenplum 中文社区尤为活跃，目前约有半数的贡献来自中国开发者，社 区贡献者

(decrypted) pgcypto pgcypto的问题 改变原有查询逻辑 • 不兼容现有查询语句 • 不兼容ETL工具 性能低 • 不支持索引 • 优化器无法使用，需要全表扫描 局限性高 • 多表关联查询需要先全表解密 • 只能加密表数据 pgcypto的问题 一款开源的HTAP数据库: • MPP架构 • 完整的事务+ACID+标准SQL支持 • 支持上千个节点的部署 •