Standby 的同步机制就 一直是 WAL 同步，而在 6 版本开始，Primary 和 Mirror 也采用了 WAL 同步，但由 于 Mirror 需要同步的 WAL 日志的量很大，所以，对性能的影响比 Standby 要显著。 会有很多用户问，Master 和 Standby 在绝大多数时间内，资源非常空闲，跟 Instance 主机相比，相当于完全空闲，那么是否可以将 Master 路聚合，这样，在操作系统层面，多个物理网口将聚合并表现为一个 IP 地址，当任何 的网络或者交换机出现故障时，在操作系统级别将不会有任何的连接性异常的感知，只 是网络带宽出现下降，整个数据库集群的 Instance 状态将不会受到任何影响。如果 选择将 Primary 和 Mirror 分布在不同的网段，出现任何的网络故障时，总会有 Instance 的状态发生变化，这对上层应用就不可能做到绝对的无感知。 并行数据装载 - 对于一些尺寸很小的表(叫维表或者参考表)来说，无所谓如何分布，所以，这样 的表完全可以按照 HASH 分布或者使用随机分布，甚至复制分布(只要可以接受其尺寸 放大的影响)，对整体的分析查询性能不会有明显的影响。  复制(Replicated)分布 复制分布，会在每个 Instance 上都存储一份完整的数据拷贝，复制表是在 6 版 本新引入的数据分布策略，这里需要特别指出，复制表，因为需要在每个

MPP 而言， 不是那么紧迫。 Big Date2.indd 16 16-11-22 下午3:38 Greenplum 精粹文集 17 ·节点退服方面 Hadoop 节点宕机退服对系统的影响较小，并且系统会自动将数据 在其它节点扩充到 3 份；MPP 数据库节点宕机时，系统的性能损 耗大于 Hadoop 节点。Pivotal 将 GPDB 的 MPP 技术与 Hadoop 分 布式存储技术结合，推出了 采用了旧环境数据备份、传输、新环境恢复的 方案，停机时间实际只花了不到 4 天。 相比较而言，其他封闭式系统，需要压缩并备份数据，倒腾出整套设 备搬迁到新数据中心，然后再导入新数据，影响或暂停业务几十天。 两种方案从工程复杂度、人力投入、业务影响来说，开放式架构所带 来的便利和优势体现的淋漓尽致。 Big Date2.indd 22 16-11-22 下午3:38 Greenplum 精粹文集 23 是通过以太网络将多台物理机连在一起，也就是网络资源 是大家要共享的，所以在部署 Greenplum 集群的时候，一定要规划好 网络设备的接入，在达到性能最大的同时，也要考虑大流量对现有业 务系统是否造成影响。 Greenplum 建议采用以太网万兆交换机，并通过设定跨设备链路 聚 合 组（MC-LAG Multi-ChassisLink Aggregation Group） 的 方 式将两台交换机连在一起，在服务器上将网卡通过

M20 M21 M23 M24 M22 统计信息收集  对于系统表和用户表需要收集统计信息，GPDB的查询计划是cost base的，统计信息的准确性对查询 计划的优劣有很大影响；  对于字段数较多的表，可关闭gp_autostate_mode (on_no_stats=>none)，仅对必要列执行Analyze， 只在结果中返回的列无需收集统计信息；  对于频 Update/delete操作后，数据库不会自动释放这些空间，这些垃圾空间的回收方 式： 1）Vacuum 2）Vacuum full 3）REORGANIZE • 不进行垃圾空间回收的影响 o 垃圾空间浪费存储空间 o 垃圾空间影响查询性能 注：delete all用truncate代替，truncate无需回收垃圾空间 垃圾空间回收  Vacuum：标记垃圾空间为可再利用 数非常多，将这些目的档重分布到新扩展的节 点时间会很长 – 系统表（pg_class,pg_attribute）太大，影响系统工作效率 – 系统元数据检查pg_checkcat等工具运行时间比较长 物理模型经验分享 物理模型对于系统性能有很大影响，因此需要我们特别关注。 以下来自于在某大型银行的使用经验： 行存储和列存储： • 避免过多使用列存储的原因是防止小档数过多。

加载数据 Ø 业务程序访问 23 Greenplum运维体系 环境创建与部署 • 部署注意点 Ø 资源要充足（ETL，管理节点，数据节点，数据集市） Ø 万兆网络 （网络环境对功能和性能的影响） Ø 节点规划 （数据节点6-10个segment节点） Ø 参数调整 （操作系统参数，greenplum集群参数） 24 Greenplum运维体系 系统状态监控 - gpcc -公司IDC_01机房 sion会话的操作 Ø尽量不创建索引 • 上线与调度规范 Ø上线的程序，必须要经过测试，才可以生产使用 Ø调度程序需考虑每个任务的前后关系，时间富裕 Ø避免因为过于追求并行度，对多个任务造成相互影响 38 Greenplum现状说明 三 Greenplum体系架构 二 数据仓库体系架构 一 Greenplum开发规范 五 Greenplum运维体系 四 Greenplum扩展规划

区、把数据加载到最新的⽉份分区。 把数据分为⼏个均等的部分：通过⼀个分区标准把⼀个⼤表的数据划分为均等的分区，这样可以等倍的提⾼查询性能。 使⽤分区的时候请避免建⽴过多的分区，创建过多的分区可能会影响管理和维护作业，例如： 清理⼯作，节点恢复，集群扩展，查看磁盘使⽤情况等。 开发指南 Greenplum数据仓库 UDW Copyright © 2012-2021 UCloud 优刻得 92/206 TABLE p_store_sales TRUNCATE PARTITION FOR (RANK(1)); 备注：RANK括号⾥⾯的1是分区的rank值、可以通过上述查看分区信息查看，增加或者减少分区都可能影响rank值。 6.7 把⼀个分区分为两个分区 把⼀个分区分为两个分区 使⽤ ALTER TABLE 命令来把⼀个分区分为两个分区 ALTER TABLE p_store_sales SPLIT Copyright © 2012-2021 UCloud 优刻得 135/206 修改分布键可以回收索引的膨胀空间。修改分布键加载的锁与 DDL 锁类似，是排它锁。建议在没有业务的时候执⾏，不要影响业务。 alter table test set with (reorganize=true) distributed randomly; alter table test set with (reorganize=true)

5及之前的版本对表的更新操作是串行的，所以大量小表做expand会在 更新状态表时遇到瓶颈 ▪ Greenplum 6中因为全局死锁检测的引入可以对heap表做并行更新 改进与实现 • 扩容期间对查询的影响 – 新增节点阶段无法修改catalog – 对于正在重分布的表的读写访问均会被阻塞 – 对于分布状态不相同的哈希分布表的Join无法做优化 Q&A Thank you

扩展性—高性能架构 7 • 创建并装载目标表 • 用于实时复制的初始化 • 也可以单独使用 • 可以被定义为任务，定时调度执行 异构平台环境下初始化同步 8 • 非侵入式技术对生产没有影响 • 基于日志捕获技术的实时性非常高 • 支持从过去的某一指定时间开始捕获 • 条件过滤 • 支持触发器捕获技术作为补充 基于数据库事务日志的变化数据捕获 9 • 避免人为错误 • 在迁移结束前校验数据

在Greenplum内部实现了了流程⾃自动 化 X 代码复杂冗余，很多数据类型 转换 ✓ 代码更更精简，更更便便于维护的代码 X 原始模型预测效果不不理理想 ✓ 新模型能够更更精准地预测⽬目标客 户 商业影响 2017.thegiac.com 用户案例例2 基于API日志的⾦金金融产品⽤用户分析 2017.thegiac.com 问题 ● 更更好地理理解不不同种 类的⽤用户 ●

供应商制约。用户可通过不同供应商获得针对 Greenplum 的服务和支持。 • Greenplum Database 在开发时采用的是以社区 / 客户为焦点的开发模式。客户可通过多种开放可用的方法对总 体产品方向产生影响，而这又会加快产品创新。 客户能够在群集中的一组初始服务器上部署 Pivotal Greenplum，并能在数据存储和用户需求增加时扩充配置中的服务器数 量，且无需卸载再重新加载数据。随着越来越多

能够独立于专用 硬件加速提供高性能的纯软件数据平台，无需专用硬件，另外一方面包括核心代码在内的全部开源，社区人员或客户 可最大化自由利用和借鉴 Greenplum 的优秀功能的同时，又可以反哺及影响总体产品研发方向，可以加快产品创新， 基于此 Greenplum 有适用于多种环境的使用及实践，非常契合如今中国本土客户越来越多样化的应用业务基础环境。 以开源创新替代专有分析环境