以对账业务为主，统计计算为辅 • 公司IDC_02机房Greenplum体系 Ø 针对数据来源主要是kfk产生csv文件的业务，不直接从数据库传数 Ø 以重点业务线、活动数据、非OLTP业务数据的任务计算为主 • 公司IDC_03机房Greenplum体系 Ø 数据来源来源为OTLP库库，针对大数据量传输和计算，采用T+1方式 Ø 以核心业务的数据计算、统计为主 18 Greenplum现状说明 Greenplum运维体系 数据库数据传输与同步-db_sync 31 Greenplum运维体系 Greenplum任务调度 • greenplum内部存储过程调度 Ø大批量任务采用 kettle调度 Ø单个存储过程，可以在shell中 select func_name() 的方式调度 • 外部任务调度 Ø将整个过程封装成shell脚本，或 Python脚本 Ø用crontab在操作系统调用脚本 Ø用 Greenplum任务调度-opencron 33 Greenplum现状说明 三 Greenplum体系架构 二 数据仓库体系架构 一 Greenplum开发规范 五 Greenplum运维体系 四 Greenplum扩展规划 六 34 Greenplum开发规范 不规范容易出现的问题 • GP架构易出现问题 Ø 资源不足 Ø 连接、语句执行失败 Ø 多任务冲突 • 库表使用易出现问题

实例的高效协同和并行计算，Interconnect 承载了并行 查询计划生产和 Dispatch 分发（QD）、协调节点上 QE 执行器的并 行工作、负责数据分布、Pipeline 计算、镜像复制、健康探测等等诸 多任务。 在 Greenplum 开源以前，据说一些厂商也有开发 MPP 数据库的打算， 其中最难的部分就是在 Interconnect 上遇到了障碍，可见这项技术的 关键性。 Greenplum 集群架构 CPU CORE 的计算能力，对 X86 的 CPU 超线程有很好的支持，提供更好的请求响应速度。在 PoC 中接触 到其它一些国内外基于开放平台的 MPP 软件，大都是建立在节点级的 并行，单个或少量的任务时无法充分利用资源，导致系统加载和 SQL 执行性能不高。 记忆较深的一次 PoC 公开测试中，有厂商要求在测试中关闭 CPU 超 线程，估计和这个原因有关（因为没有办法利用到多个 CPU core 有 问 题，Greenplum 采 用 Master-slave 架 构， Master 是否会成为瓶颈？完全不用担心，Greenplum 所有的并行任务 都是在 Segment 数据节点上完成后，Master 只负责生成和优化查询 计划、派发任务、协调数据节点进行并行计算。 按照我们在用户现场观察到的，Master 上的资源消耗很少有超过 20% 情况发生，因为 Segment 才是计算和加载发生的场所（当然，

公司商业运营，在 2020 年，Pivotal 被兄弟公司 VMWare 收购，由 VMWare 继续运营。近年来，Greenplum 在国内建立了一个较大规模的研发团队，越来越多的承担更重要的研发任务，包括 PostgreSQL 的版本合并等，从而，可以为国内商业用户提供更专业和更优质的本地 化服务，用户遇到问题，反馈给专业技术支持人员，或者专业售后服务团队，他们会同 用户一起排查和解决问题，如 脚本的形式实现了 Master 和 Standby 的自动 FailOver 效果，编者也实现了自动 切换命令，当 Master 出现无法正常工作的故障时，自动激活 Standby 来接管 Master 的任务。下面的流程图，是编者实现的 Master 和 Standby 自动切换的逻辑流程图， 可以供读者参考，不过，编者不方便公开实现的代码。 Greenplum Database 管理员指南 V6.2 Primary，这个数字的选择需要由富有经验的专业技术支持人员进行评估， 每个 Instance 所在主机配置的 Primary 越多，响应并发的能力越弱，但单个任务的 处理能力越强(这也不是绝对的，当 Primary 数量多到，即便运行单个任务时都会出 现资源争抢，可能运行的效率就会下降)。实际上，每个计算主机的 Primary 个数， 还与其他资源有关，如，磁盘性能，网络性能，内存容量。

IO是否繁忙，Wait是否较高 – 是单一服务器繁忙还是所有服务器繁忙  检查数据库狀态 – gpstate检查是否有实例down机 – 检查pg_log是否有OOM錯誤  检查当前SQL任务 – 确定当前系統是否有SQL能执行成功（checkpoint、select用户表），还是整個系统挂起 – 确定是否有锁等待或资源队列排队导致SQL长时间不能完成 – 确定是否整体性能慢 检查文件系统是否有异常（到相应实例对应的数据目录下，执行ls；echo“test‖ > mytest.txt看看是否有错误） 问题定位方法 现象-某个SQL任务执行时间太长  检查SQL是否在资源队列中排队（select * from pg_stat_activity），是否已经dispatch（cat pg_log/gpdb-yyyy-mm-dd_xxxxxxx 按照模式、表清单备份、可排除部分表、可排除全部外部表的Error表  有详细日志、自劢生成成功失败清单、可断点续跑[到表级]  可指定条件筛选数据进行备份  单个失败不影响整个备份任务  可增量备份-识别AO的方式与gpcrondump一致，同时支持heap表的增备(是否发生过变化)  可指定并发数(同时多张表备份)，可指定编码Encoding  乐观锁设计——单表尝试加锁失败即认为该表本次备份失败

商用硬件集群 分析 数据 市场 企业数 据仓库 企业数据集合：主要的优势 • 实体整合 • 提高服务器使用率 • 降低总硬件成本 • 降低能量成本 • 可以预估的服务等级 • 确保关键任务的可靠性 • 最出色的性能 • 高度灵活性 • 逐步扩展计算能力 • 动态措施 • 数据访问： • 在一个系统中协调所有企业数据的位置 • 可以通过任何语言（SQL、M/R等）进行分析 14 描，历时超过20分钟。 结论：如果采用DWA替代现有环境，获得超过120倍的性能提升。 • 真实应用测试 – DWA测试结果：完成应用的全过程仅耗时48分钟。 – 客户投产环境：客户11月份月度处理时，完成本项任务需要65小时。 结论：如果采用DWA替代现有环境，获得超过80倍的性能提升。 案例分享：阿里巴巴 • 业务用例 • 通过分析用户的网络点击日志，进行产品关联分析，让客户可以 快速的找到相近产品

查询计划包含2个slices，所以每个 segment 会启动 2 个 QE（Query Executor），一个 QE 负责 执行一个 slice 对应的任务。 同一个 slice 在每个 segment 的 QE形成一个 Gang，它们在不同的segment上执行相同的任务。 HashJoin 需要相同关联键的所有数据都在一个 segment 上，因而如果关联键不是分布键，则需 要数据移动。在这个例子中classes

NFS, Cinder, VsphereVolume ● PersistentVolumeClaim ○ 申请存储资源 Kubernetes 计算资源 Pod ● Pod ○ 计算任务 → 容器 → Pod ○ 资源分配：CPU，内存，磁盘 ○ 资源调度：Pod → Node ● Pod管理 ○ 无状态计算资源组：Deployment ○ 有状态计算资源组：StatefulSet

Confidential │ ©2022 VMware, Inc. 19 GPCC Greenplum Command Center Ø Web UI 监控和管理 Ø 实时性能监控 Ø 可视化计划 Ø 基于规则的任务管理 Ø 向客户推荐性能优化操作 Ø 报警和通知 Confidential │ ©2022 VMware, Inc. 20 Greenplum Streaming Server Ø ETL工具

连续数据集成技术 Migrations Disaster Recovery 6 扩展性—高性能架构 7 • 创建并装载目标表 • 用于实时复制的初始化 • 也可以单独使用 • 可以被定义为任务，定时调度执行 异构平台环境下初始化同步 8 • 非侵入式技术对生产没有影响 • 基于日志捕获技术的实时性非常高 • 支持从过去的某一指定时间开始捕获 • 条件过滤 • 支持触发器捕获技术作为补充

多态存储系统 客户端访问 ODBC, JDBC, OLEDB, etc. 核心MPP 架构 并行数据流引擎 高速软数据交换机制 MPP Scatter/Gather 流处理 在线系统扩展 任务管理 服务 加载 & 数据联邦 高速数据加载 近实时数据加载 任意系统数据访问 存储 & 数据访问 混合存储引擎（行存&列存） 多种压缩，多级分区表 索引（B树，位图，GiST） 安全性