协议进行转换，之前遇到某 客户因为驱动和服务器硬件兼容问题，压力一大，服务器自就会自 动重启，最后又将网络设备改回万兆交换机。 ·网卡绑定采用 mode=4 (802.3ad)，流量传输 hash 策略选用 xmit_hash_policy=layer3+4【((sourceport XOR dest port) XOR ((source IP XOR dest IP) AND 0xffff) modulo 合 考虑服务器配置、生产环境的运行负载压力、跑批用户和前段查询用 户并发需求等各个方面。大多数场景下，4 或 6 个为宜。 同样，作为整体架构设计的重要 组成部分，ETL 服务器、监控管 理，备份策略如何规划，如何高 效组网都得在前期考虑好。在我 们的成功案例中，同一个企业级 数据平台中 Greenplum 集群和 Hadoop 集群配合运作的案例越 来越多。在中国移动的大数据架 构规范中，云化 硬件的状况，及时发现及时处理。硬盘状态、阵列卡状态、硬件告警、 操作系统告警、空间使用率等都是应关注的重点。这些都可通过厂商 提供的工具，编写监控程序，SNMP 协议对接企业监控平台等手段提 升日常巡检和监控的效率。 针对 Greenplum，DBA 需要关注重点： ·Greenplum 的状态：Standby master 的同步状态往往容易被忽略。 通过监控平台或者脚本程序，能够及时告警则最好。 ·系统表：日常系统表维护（vacuum

GPDB中关闭了Autovacuum（GPDB 4.2.6 UPPER）  Age的监控：  xid_warn_limit:500000000（5亿）,AGE大于5亿自动告警  xid_stop_limit: 1000000000， AGE大于10亿停止工作，等待vacuum执行 数据库对象数上限的最佳实践  GPDB内部的对象：所有的表（包括分区表）、索引、视图等都称为对象 art排序，检查时间最长的SQL)  检查硬件和OS状态 – 查看command Centre中系统监控情況 – MegaCli检查磁片和Raid卡状态 – 检查OS是否有硬件错误告警 – gpcheckperf检查网络和磁片性能 问题定位方法 现象-数据库不能访问 对于此类问题，相对来说比较容易定位。  gpstate检查系統状态，此时很可能不会有任何输出

支持触发器捕获技术作为补充 基于数据库事务日志的变化数据捕获 9 • 避免人为错误 • 在迁移结束前校验数据 • 支持异构 异构平台间数据校验域修复 10 内置监控与报警 • 实时监控HVR进程 • 自动告警 • 与第三方企业监控平台集成 • 丰富的统计报表 LDAP authenticated user; if that’s not configured just OS username

.................................................................................. - 21 - 解读 GP 分布策略 .................................................................................................. ..................................................................................... - 125 - 验证分区策略 .................................................................................................. ............................................................................... - 343 - 规划 Mirror 策略 ................................................................................................. -

容器资源分配 ○ CPU ○ 内存 ○ 磁盘 ● 容器间网络互联 ○ 本机网络 ○ 跨机网络 ● 容器化Greenplum部署策略 ○ Master部署策略 ○ Primary Segment部署策略 ○ Mirror Segment部署策略 ● 容器化Greenplum运维管理 ○ 故障检测及恢复 ○ 升级扩容 ● 容器化Greenplum存储管理 ○ 容器本地存储易失性 容器资源分配 ○ CPU ○ 内存 ○ 磁盘 ● 容器间网络互联 ○ 本机网络 ○ 跨机网络 ● 容器化Greenplum部署策略 ○ Master部署策略 ○ Primary Segment部署策略 ○ Mirror Segment部署策略 ● 容器化Greenplum运维管理 ○ 故障检测及恢复 ○ 升级扩容 ● 容器化Greenplum存储管理 ○ 容器本地存储易失性 容器资源分配 ○ CPU ○ 内存 ○ 磁盘 ● 容器间网络互联 ○ 本机网络 ○ 跨机网络 ● 容器化Greenplum部署策略 ○ Master部署策略 ○ Primary Segment部署策略 ○ Mirror Segment部署策略 ● 容器化Greenplum运维管理 ○ 故障检测及恢复 ○ 升级扩容 ● 容器化Greenplum存储管理 ○ 容器本地存储易失性

4、表格设计 、表格设计 udw 的表格创建类似于 postgresql，由于 udw 采⽤ mpp 数据，创建表格的时候可以选择不同的数据分布策略，不同的存储⽅式等等。创建表格的时候可以定义下⾯信息： 数据类型 表约束 数据分布策略 表存储模型 分区策略 外部表：udwfile、udwhdfs 下⾯分别根据上⾯的可选信息对表格设计进⾏分析。 4.1 数据类型 数据类型 开发指南 Greenplum数据仓库 4.2 表约束 表约束 udw 表格⽀持 postgresql 的表格约束，拥有 primary、unique 、check、not null、foreign 等约束，主键约束必须使⽤ hash 策略来分布表数据存储，不能在同⼀个表同时使⽤主键和唯 ⼀约束，并且指定了primary 和 unique 的列必须全部或者部分包含在分布键中。 创建表检查约束 CREATE TABLE products( Hash 分布策略，并且约束列必须和表的分布键对应的列⼀致（或者是超集） CREATE TABLE products( product_no integer UNIQUE, name text, price numeric ) DISTRIBUTED BY (product_no); 主键约束：主键约束是唯⼀约束和⾮空约束的组合。要使⽤主键约束，表必须使⽤ Hash 分布策略，并且约束列

种分布 策略、多级分区以及多态存储。 分布式数据存储 Confidential │ ©2021 VMware, Inc. 9 Greenplum 6 提供了以下 3 种数据分布策略: l 哈希分布 (Hash Distribution) l 随机分布 (Randomly Distribution) l 复制分布 (Replicated Distribution) 数据分布策略 Confidential 哈希分布是分布式数据库最为常用的数据分布方式。根据用户自定义的分布键计算哈希值，然后将 哈希结果映射到某个 Segment 上。在 Greenplum 6 中，默认采用一致性哈希(Jump Consistent Hash)分布策略。 哈希分布 当增加一个新的节点时，需要对原有数据进行重新映射。一致性哈希则保证了在重新映射的过程追 中，tuple 要么保留在原有节点中，要么迁移至新的节点中，从而实现最小数据迁移。 Confidential 将会根据分布键以及分布策略将数据分布到不同的节点中去。那 么在查询时，就需要各个节点将数据处理完毕后发送至 Coordinator 节点并返回给客户端用户。 分布式查询优化器 l 对于普通查询，只需要将 Segment 上的数据汇总即可，如果有 filter， 则在 segment 上执行条件过滤 l 对于 JOIN，我们需要考虑两张表的分布键以及分 布策略。若分布键和分布策略不同，就需要对数据

Pool里未提交事务所修改的脏页刷回到持久存储 No-steal: 不允许Buffer Pool里未提交事务所修改的脏页刷到持久存储中 缓冲区管理策略Buffer Management Policy 13 ■ Force策略的问题 对持久存储器进行频繁的随机写操作，性能下降。 ■ No-Steal策略的问题 不允许未提交事务的脏页换出，系统的并发量不高。 ▪ No-Force / Steal 有更好的性能，但是怎么保证事务的原子性和持久 事务提交，所修改的数据页没有刷回至持久存储，如果发生断电 或者系统崩溃。 ❏ Steal: Buffer Pool中未提交的事务所修改的脏页刷回到持久存储，如果发生 断电或者系统崩溃。 缓冲区管理策略 14 ■ No-Force → Redo Log 事务提交时，数据页不需要刷回持久存储，为了保证持久性，先把Redo Log写 入日志文件。Redo log记录修改数据对象的新值(After 存储，为了保证原子性， 先把Undo Log写入日志文件。Undo Log记录修改数据对象的旧值(Before Image, BFIM) Solution: Logging 15 缓冲区管理策略和事务恢复的关系 Force No-Force Steal Undo / No-Redo Undo + Redo (performance: fastest recovery:

⽤用户案例例 1 Greenplum + MADlib 助⼒力力邮件营销 2017.thegiac.com 问题 ● 邮件⼴广告点击预测 模型不不够精准，需 要更更好的邮件营销 策略略 ● 现有数据分析流程 繁琐，速度慢，有 很多⼿手动步骤，易易 出错 客户 数据科学解决⽅方案 ● 某⼤大型跨国多元 化传媒和娱乐公 司 ● 简化Data 流程 ● 数据 集进⾏行行了了更更充分的分析 X 没有良好的⽤用户分类体系 ✓ 建⽴立了了两套模型对典型⽤用户进⾏行行 聚类分析，对⽤用户群体和⽤用户习惯 有了了更更深⼊入的了了解，制定相应的营 销策略略 X 不不能⾼高效监测可疑Session ✓ 建立了可疑Session实时评分体系 X 考虑转换到Teradata ✓ 决定增加Greenplum Cluster数量 案例例优化总结

2）调整work_mem、max_connections参数； 2018年PostgreSQL中国技术大会 微信号：laohouzi999 3）使用更严格的内存提交策略overcommit_memory： 内核参数overcommit_memory ，指定内存分配策略 可选值：0、1、2。 0， 表示内核将检查是否有足够的可用内存供应用进程使用； 如果有足够的可用内存，内存申请允许；否则，内存申请 失败，并把错误返回给应用进程。