1 2 • 中国科学技术大学计算机科学学士 • 上海交通大学MBA • 20年+IT从业经验， 专注于数据库技术领域 • 自2003年始从事数据库实时复制技术的解决方案 • 2013年至2015年在SAP 担任大数据和BI解决方案 资深技术顾问 • 2015年加入HVR中国公司担任技术总监 • 微信号: gu9060 个人介绍 3 HVR moves high volumes Migrations Disaster Recovery 6 扩展性—高性能架构 7 • 创建并装载目标表 • 用于实时复制的初始化 • 也可以单独使用 • 可以被定义为任务，定时调度执行 异构平台环境下初始化同步 8 • 非侵入式技术对生产没有影响 • 基于日志捕获技术的实时性非常高 • 支持从过去的某一指定时间开始捕获 • 条件过滤 • 支持触发器捕获技术作为补充 基于数据库事务日志的变化数据捕获 基于数据库事务日志的变化数据捕获 9 • 避免人为错误 • 在迁移结束前校验数据 • 支持异构 异构平台间数据校验域修复 10 内置监控与报警 • 实时监控HVR进程 • 自动告警 • 与第三方企业监控平台集成 • 丰富的统计报表 LDAP authenticated user; if that’s not configured just OS username Next

趋势分析 4 数据仓库体系架构 业务数据与数据特点 • 现在的数据 —— OLTP Ø实时，在线系统，客户使用 Ø事务小，频率高，并发高 • 过去的数据 —— OLAP Ø非实时（T+1，或小时级），离线系统，分析决策 Ø事务大，频率相对小，并发低 • 未来的数据 —— 趋势分析 Ø非实时，离线+在线流系统，趋势分析 Ø算法分析，持续计算 5 数据仓库体系架构 OLAP场景举例 业务相关场景 Ø用户状态 （注册数，活跃数，并发量，峰值） Ø金币状态 Ø道具/物品状态 Ø对账状态 Ø活动反馈 • 架构相关场景 Ø不同数据量，不同事务特点，不同查询需求 Ø历史数据归档与冷热分离 Ø实时与延时需求的权衡 6 数据仓库体系架构 数据流转过程 • 1 业务数据的产生 —— OLTP • 2 业务数据的中转 —— ETL服务器 • 3 数据的存储和计算 —— OLAP集群 • 4 三大Greenplum集群定位分类 • 公司IDC_01机房Greenplum体系 Ø 公司第一套Greenplum集群，网络环境为千兆网 Ø 数据来源为OLTP库，针对小数据量传输和计算，部分实时交互操作 Ø 以对账业务为主，统计计算为辅 • 公司IDC_02机房Greenplum体系 Ø 针对数据来源主要是kfk产生csv文件的业务，不直接从数据库传数 Ø 以重点业务线、活动数据、非OLTP业务数据的任务计算为主

....................................................................................... - 278 - 时钟同步................................................................................................... ..................................................................................... - 370 - 通过数据同步的方式升级 ...................................................................................... - 372 - Instance 文件有损毁， 将需要全量恢复或者需要选择全量恢复。在 6 之前的版本，GP 的 Primary 和 Mirror 之间采用的是 filerep 的方式进行 block 级别的变化同步的机制，从 6 版本开始， 使用 WAL 复制，这将可以从根本上解决以往的 block 损毁被复制到 Mirror 上的问题， 也不再需要 persistent 系统表了(这个的确是一个让人很头疼的设计)。

源操作系 统平台架构、创新性及核心特点， 同时介绍了 Greenplum 作为一款深受技术爱好者喜爱的、中立的纯开源软件，践行 “Run Everywhere”原则，用全新的HTAP核心设计满足实时处理业务需求。在此也为所有为Greenplum on openEuler 成功测试运行所做努力贡献的人员表示感谢！ 摘要 Greenplum 不受限于基础架构，这意味着它是一种可完全 丰富的 HTAP 特性，具备良好性能、可靠性和稳定性，使得 Greenplum 不仅可以作为全能的分析化平台，也能满足交易型业 务场景，能够处理多种并发混合工作负载，专为满足在多结构数据环境中进行实时分析的需求而设计。 欧拉开源操作系统是一款面向数字基础设施的操作系统，支持服务器、云计算、边缘计算、嵌入式等应用场景，支持多 样性计算，致力于提供安全、稳定、易用的操作系统。 Greenplum 操作系统支持多设备，应用一次开发覆盖全场景。 openEuler 平台架构 openEuler 是覆盖全场景的创新平台，在引领内核创新，夯实云化基座的基础上，面向计算架构互联总线、存储介质 发展新趋势，创新分布式、实时加速引擎和基础服务，结合边缘、嵌入式领域竞争力探索，打造全场景协同的面向数字 基础设施的开源操作系统。 完全兼容欧拉开源操作系统的 HTAP 数据平台 Greenplum

OLTP-OLAP独立部署 OLTP数据库 OLAP数据仓库 ■ 实时性 ■ 数据同步复杂性 ■ 应用复杂性 HTAP HTAP = ? ■ 卓越的OLAP特性 ■ 出色的OLTP特性 ■ 多态存储 ■ 有效的并发和资源管理 OLTP-OLAP独立部署 OLTP数据库 OLAP数据仓库 ■ 实时性 ■ 数据同步复杂性 ■ 应用复杂性 43 Pivotal Confidential–Internal set_schema_quota ('s1', '1 MB'); SELECT diskquota.set_role_quota ('u1', '1 MB'); 客户案例 ■ 通过kafka近实时（500ms~1s） 间隔加载：100万/s ■ 简单查询1000并发：1s内返回 ■ 复杂关联查询：s级返回 数据量 机器数 表个数 索引个数 并发数 插入间隔 平均时延 最长时延 插入速度

避免大范围使用列存储  pg_class对象数如果不进行约束，可能会产生以下问题： – gprecoverseg –F效率低，数据库实例修复如果增量同步失败，我们一般会建议使用gprecoverseg –F进行全量同 步，全量同步是在两个节点之间全量拷贝文件，超过10 0000个对象，在数据目录下地文件数会可能达到上百万 个档，这些文件的拷贝需要花费很长时间 – 使用gpexpan gp_workfile_limit_per_query 本参数为4.2.8以上版本增加，防止临时空间SPILL档数过多导致空间急剧增长 视图gp_workfile_usage_per_query可以实时监控每个query正在使用的临时空间大小 注：在GP4.3中内置了这个view，在GP4.2中需要执行./share/postgresql/contrib/gp_workfile_mgr.sql  常用可选参数  -f：显示standbymaster同步状态  -e:显示Primary和Mirror同步状态 -m：只列出mirror实例的状态和配置信息 -c：primary instance和 mirrorinstance的对应关系  -s：查看详细状态，如在同步，可显示数据同步完成百分比  --version,查看数据库version

故障，我们可以迅速采取相应的修复措施，如果底层 RAID 没有损坏， 在单台机器数据量过大比如接近 10T 的情况下，我们可以直接将磁 盘插入到灾备机，由于 RAID 信息写在磁盘上，对调磁盘后，所有 数据信息仍然保留，这样就能避免数据同步带来的性能损耗，这种 方式要求集群所有机器采用相同规格的 RAID 卡。 以下是我们新一代一体机硬件和机柜配置，大家可以参考： Big Date2.indd 27 16-11-22 提供的工具，编写监控程序，SNMP 协议对接企业监控平台等手段提 升日常巡检和监控的效率。 针对 Greenplum，DBA 需要关注重点： ·Greenplum 的状态：Standby master 的同步状态往往容易被忽略。 通过监控平台或者脚本程序，能够及时告警则最好。 ·系统表：日常系统表维护（vacuum analyze），在系统投产时就 应该配置好每天执行维护。 Big Date2.indd persistenttable 与 pg_class/pg_relation_node/pg_database 等系统 表有着严格的主外键关系。这类系统表也是 primary 实例与 mirror 实例之间实现同步的重要参考数据。 在 Greenplum 集群出现故障时，会有可能导致系统表数据有问题。 系统表出现问题会导致很多种故障产生，如：某些数据库对象不可 用，实例恢复不成功，实例启动不成功等。针对系统表相关的问题，

Interconnect: 数据交换信道 Confidential │ ©2022 VMware, Inc. 8 Greenplum的高可用 Ø 数据存两份，Coordinator有standby Ø 自动同步数据 (WAL replication) Ø 自动灾难恢复 (FTS，主备切换) Confidential │ ©2022 VMware, Inc. 9 分布式优化器：OLAP Ø OLTP系统的SQL语句相对简单（CURD） Languages/Container Confidential │ ©2022 VMware, Inc. 19 GPCC Greenplum Command Center Ø Web UI 监控和管理 Ø 实时性能监控 Ø 可视化计划 Ø 基于规则的任务管理 Ø 向客户推荐性能优化操作 Ø 报警和通知 Confidential │ ©2022 VMware, Inc. 20 Greenplum

Greenplum 介绍 Greenplum 是全球领先的开源大数据平台，是能够提供包含实时处理、弹性扩容、混合负载、云 原生和集成数据分析等强大功能的大数据引擎。 著名分析机构 Gartner 2019 年报告中，在经典数据分析领域 Greenplum 全球排名第三，实时分 析领域全球排名并列第四。Greenplum 是两个领域中排名前十的产品中的唯一一款开源产品。 的弹性和线性扩展能力，并内置 并行存储、并行通讯、并行计算和优化技术。同时，Greenplum 还兼容 SQL 标准，具备强大、 高效、安全的 PB 级结构化、半结构化和非结构化数据存储、处理和实时分析能力，可部署于企 业裸机、容器、私有云和公有云中。值得一提的是，作为 OLAP 型的大数据平台, Greenplum 同 时还能够支持涵盖 OLTP 型业务的混合负载，从而帮助客户真正打通业务-数据-洞见-业务的闭环。

greenplum会变成只读，不能写了。如果模式是 “continue”模式时，一个segment坏了的时候，数据 库仍然可以继续工作。但由于segment的primary与 mirror端的数据不同步了，所以恢复的时候需要花比较 长的时间。对于Greenplum 3.X的版本，恢复时，需要 把好的节点上的所有数据都copy到坏的机器上。而 Greenplum4.0版本增加了功能，当备份节点坏的时 mirror之间是做的逻辑同步，mirror端的数据库实际上 也是可以读写的。而Greenplum4.0版本后，primary与 mirror实际上是物理同步，这时mirror一直处于恢复状 态，不能读也不能写。 高可用之Master Mirroring 对于Greenplum Master的primary与mirror之间的同步 就是使用PostgreSQL的日志同步方案。master的