的表格创建类似于 postgresql，由于 udw 采⽤ mpp 数据，创建表格的时候可以选择不同的数据分布策略，不同的存储⽅式等等。创建表格的时候可以定义下⾯信息： 数据类型 表约束 数据分布策略 表存储模型 分区策略 外部表：udwfile、udwhdfs 下⾯分别根据上⾯的可选信息对表格设计进⾏分析。 4.1 数据类型 数据类型 开发指南 Greenplum数据仓库 UDW Copyright 2012-2021 UCloud 优刻得 85/206 备注：更多关于分区策略的的使⽤可以通过命令⾏执⾏\h create table 或者 \h alter table 查看 4.4 表存储模型（ 表存储模型（heap表和 表和appendonly表） 表） UDW ⽀持两种类型的表：堆表（heap table）和追加表（Appendonly table）。默认创建的是堆表。 堆表（heap CREATE TABLE heapTable( a int, b text ) DISTRIBUTED BY (a); 创建⼀个追加表（CREATE TABLE 命令的 WITH ⼦句来指定表存储模型）： CREATE TABLE aoTable( a int, b text ) WITH (appendonly=true) DISTRIBUTED BY (a); 4.5 表存储⽅式（⾏存储、列存储）

致读者 如果您在阅读和参考本书的过程中发现有任何不妥之处，或者有任何的建议和意见， 欢迎联系编者，本书主要针对 GP 数据库的爱好者进行编写，包括产品的安装和使用说 明，以及最佳实践等内容。本书的发布更新情况与编者的时间有关，不做承诺。 编写： 陈淼 电邮： miaochen@mail.ustc.edu.cn Greenplum Database 管理员指南 V6.2.1 版权所有：Esena(陈淼 ....................................................................................... - 373 - 数据模型 .................................................................................................. 之间存储数据的，可以参考下图所示的简单 逻辑关系，主键(Primary Key)被使用黑体标记，外键(Foreign Key)关系通过连 线标明。 用数据仓库的术语来说，这种数据模型称为星型模型。在这种数据库模型下，Order 表通常被称为事实表(Fact Table)，其他表(Customer、Vendor、Product)被称 为维表(Dimension Table)。不管是哪张表，虽然对于用户来说，看起来就是一张

部表机制 • 完善的标准支持：SQL、JDBC、ODBC • 集成数据平台：BI/DW、文本、GIS、图、图像、机器学习 • 开放源代码，持续大力投入 • 敏捷方法学：快速迭代、持续发布、质量内建 • 企业级稳定性，成熟生态系统 2017.thegiac.com Greenplum: 机器学习工具集 2017.thegiac.com • PL/X：各种语言实现自定义函数（存储过程） generate_series(1,30:: bigint) AS ID) foo DISTRIBUTED BY (id); 2017.thegiac.com 2017.thegiac.com • 适合模型应用于数据子集的场景，并行执行效率非常高 • 如果节点间数据通讯，使用 适⽤用场景 2017.thegiac.com MADlib 2017.thegiac.com 强⼤大的分析能⼒力力 强⼤大的分析能⼒力力 ● 机器器学习 ● 图形分析 ● 统计分析 MPP系统上的可扩展应⽤用 Apache上的开源项⽬目 ● 发布了了 6 个版本 ● Apache 顶级项⽬目 Pivotal Greenplum PostgreSQL 基于SQL的数据库内置的机器器学习库 2017.thegiac.com

Greenplum 不受限于基础架构，这意味着它是一种可完全移植的分析数据库软件解决方案，可部署在不同操作系统、 不同芯片的环境，适合本地部署、多云环境（公有云和私有云）中。Greenplum 6 及未来发布的 Greenplum 7 丰富的 HTAP 特性，具备良好性能、可靠性和稳定性，使得 Greenplum 不仅可以作为全能的分析化平台，也能满足交易型业 务场景，能够处理多种并发混合工作负载， openEuler 作为一个操作系统发行版平台，每两年推出一个 LTS 版本。该版本为企业级用户提供一个安全稳定可靠的 操作系统。 openEuler 也是一个技术孵化器。通过每半年发布一次的创新版，快速集成 openEuler 以及其他社区的最新技术成 果，将社区验证成熟的特性逐步回合到发行版中。这些新特性以单个开源项目的方式存在于社区，方便开发者获得源代 码，也方便其他开源社区使用。 openEuler 社区面向场景化的 SIG 不断组建，推动 openEuler 应用边界从最初的服务器场景，逐步拓展到云计算、边 缘计算、嵌入式等更多场景。openEuler 正成为覆盖全场景的操作系统，将发布面向边缘计算的版本 openEuler 21.09 Edge、面向嵌入式的版本 openEuler 21.09 Embedded。 openEuler 希望与广大生态伙伴、用户、开发者

第一个支持互联网级分析技术（由Google普及）的产品 • 采用新的编程模型，在商用硬件上并行处理和执行 • 可以使客户洞察力和数据货币化程度达到前所未有的高度 MapReduce Greenplum MapReduce的优势 • 处理在任何地点存储的任何类型的数 据 • 将SQL的普遍性与MapReduce的灵 活编程模式结合起来 • 针对业务关键分析功能提供企业级集 成、支持和发布 • 为新一代分析处理技术开启了大门–

开源。由此产生的最积极结果是 Greenplum Database 社区规模迅速扩大。该社区的成员为核心组件的开发贡献了力量，并且已经受益于 Pivotal 长久以来 在市场上取得的成功。从 2017 年初开始，他们每个月发布一次 Greenplum 更新，使其保有快速而可靠的创新力。 此次推 出的 Greenplum 5 是一个功能齐全、动态的、创新型分析数据平台，其产品路线图规划健全且充满活力，无论是短期内还 是未来长期时间里，都能满足客户的需求。 集成分析：改进后的全新分析接口 一直以来，客户都能在 Pivotal Greenplum 中做高级分析，无论是提供将应用逻辑向下推送至数据所在位置的方法，执行 分析功能，还是以大规模并行方式构建数据模型，都可以实现。Greenplum 5 支持适用于数据挖掘和数据科学工作的最全面、 最先进的分析程序包和扩展。 Greenplum 5 还针对最受欢迎的 Python 和 R 语言算法库提供简单易用的安装程序。

写日志 日志落盘 写日志 记录日志 日志落盘 记录日志 日志落盘 协调者 参与者 发送prepare消息 ready 发送commit/abort消息 ack 阶段2 阶段1 25 2PC同样可以应用在单机系统上 协调者 资源管理器1 资源管理器2 资源管理器3 日志1 日志2 日志3 PREPARE / g_twophase目录下的文件并进行相关操 作，为该事务重新获取锁。 3. 恢复成功后，删掉pg_twophase目录下的文件 《数据库系统概念》19.4.1.3节，参与者在响应prepare消息之前记录 32 Greenplum实现分布式事务与并发控制 • 分布式事务管理 • 分布式事务的创建、状态迁移等 • QD向QE发起两阶段提交 • 分布式快照 •

采用开源方案，不担心后门问题，不担心被锁定。开源还可以构建更好的 生态。 ● 采用敏捷软件开发方法开发的平台：Greenplum 采用敏捷方法开发，实现了快速迭代、持 续发布和质量内建。2017 年 Greenplum 发布了 10 个版本，以前发布一个版本需要 1 个 月左右，现在只需要十几个小时。 ● 具备企业级稳定性的平台：Greenplum 经过十多年发展，有大量活跃客户，大量数百节点 集群为全球 强企业生产系统提供服务，稳定性非常高。 ● 具备成熟生态系统的平台：Greenplum 生态非常完善，有大量的合作伙伴。 发展历程 Greenplum 公司成立于 2003 年，2008 年发布 Greenplum 数据库产品。2010 年 Greenplum 被 高端存储领域巨头 EMC 收购，同年 Greenplum 借助 EMC 中国卓越研发集团进入中国，并创建 Greenplum 议、 回顾会议、结对编程、持续集成、测试驱动、单周迭代等敏捷方法建立了高效的快速反馈系统， 大大提高了产品的质量和客户的满意度。Greenplum 5.0 是开源之后发布的第一个稳定版本，大 约保持 1 个半月一个版本的发布速度。Greenplum 主干分支（master）开发非常活跃，众多社区 期待的特性稳健推进中，包括内核升级、新课题，处于业界领先地位。 Greenplum 社区邀请

Confidential │ ©2021 VMware, Inc. Greenplum 分布式执行器 QD/QE/火山模型/Gang Confidential │ ©2021 VMware, Inc. 25 Greenplum，或者说 PostgreSQL 是进程模型，而不是类似于 MySQL 的线程模型。 主进程 postmaster 是整个数据库实例的总控进程，负责启动和关闭数据库实例。当客户端和 Coordinator 发来的计划树，对每一个节点按照拉模型 (火山模型) 进行执行。 QD && QE Confidential │ ©2021 VMware, Inc. 26 QD && QE Confidential │ ©2021 VMware, Inc. 27 火山模型，或者说拉模型，是指从最顶层的输出节点开始，不断从下层节点拉取数据，一种自顶向 下的执行方式。最常见的拉模型是 Tuple-At-A-Ti Greenplum、PostgreSQL、MySQL 以及 Oracle 等主流数据库均采用拉模型。 拉模型的每个算子都实现了从下层节点获取一条元组的 GetNext 函数，每次调用该函数都会从下 层节点返回一条元组或者 EOF 的 NULL 指针。上层节点不断地调用 GetNext 函数从下层节点获 取数据，直至数据全部获取完毕。 火山模型 postgres=# explain select * from t order

和 Master- Slave 有何区别? 在 Master-Slave 模型下，Master 和 Slave 拥有相同的数据，并且 Master 是存储和处理数据的唯⼀⼊⼝，Slave 仅复制 Master 的 数据。⽐如 MySQL 的主从模型、Redis 的主从模型 在 Master-Segment 模型下，⾸先 Master 节点不存储数据，其次就是数据将会以分⽚的⽅式存储在多个 Segment 节点中。这⾥可以 类⽐ Redis Cluster，只不过 Redis Cluster 是去中⼼化的。在 Master-Segment 模型中通常也会包含 Master-Slave 模型，也就是增 加数据副本，以实现⾼可⽤ 简单地来说，Master-Slave 主要进⾏数据复制（冗余），⽽ Master-Segment 则会同时进⾏数据分区（⽔平扩展）和复制（冗余） 分区与分⽚ 基于⾏的存储⽅式，也可以选择基于列的存储⽅式，并且⽀持诸如 S3、HDFS 等外部存储 GP 基本查询流程 PostgreSQL 进程模型 PostgreSQL（以下简称 PG）采⽤的是经典的 C/S 模型，即 Client-Server 模型，同时使⽤多进程的⽅式⽀持并发查询与写⼊。也就是说， 每当有⼀个客户端连接⾄ PG 时，就会有⼀个⼦进程被创建出来。postmaster 进程和