Greenplum（以下简称 GPDB）是一款典型的 Shared-Nothing 分布式数据库系统。GPDB 拥有一个中控节点（ Master ）统筹整个系统，并在整个分布式框架下运行多个数据库实例（ Segment ）。Master 是 GPDB 系统的访问入口，其负责处理客户端的连接及 SQL 命令、协调系统中的其他 Segment 工作，Segment 负责管理和处理用户数据。而每个 Segment 实际上是由多个独立的 PostgreSQL 实例组成，它们分布在不同的物理主机上，协同工作。
GPDB中，数据通过复杂的HASH 算法或随机拆分成无重叠的记录集合，分布到所有 Segment 上。仅 Master 完成与用户和客户端程序的直接交互。因此但对于用户来说，使用 GPDB 系统如同使用一个单机数据库。
Master上存储全局系统表（Global System Catalog ），但不存储任何用户数据，用户数据只存储在 Segment 上。Master 负责客户端认证、处理 SQL 命令入口、在Segment 之间分配工作负、整合 Segment 处理结果、将最终结果呈现给客户端程序。
用户 Table 和相应的 Index 都分布在 GPDB 中各 Segment 上，每个 Segment 只存储其中属于本节点的那部分数据。用户不能够直接跳过 Master 访问 Segment，而只能通过 Master 来访问整个系统。在 GPDB 推荐的硬件配置环境下，每个有效的 CPU 核对应一个 Segment ，比如一台物理主机配备了2个双核的 CPU，那么每个主机配置4个主实例（ Segment Primary ）。
网络链接网络层组件（ Interconnect ）是 GPDB的重要组件。在用户执行查询时，每个 Segment 都需要执行相应的处理，因此物理主机间需要进行控制信息和数据的高效传递。网络层的作用就是实现物理主机之间的通信、数据传递，以及备份。在默认情况下，网络层使用 UDP 协议。GPDB 自己会为 UDP 协议做数据包校验，其可靠性与 TCP 协议一致，但其性能和扩展性远好于TCP协议。
2.查询执行机制系统启动后，用户通过客户端程序（例如 psql ）连接到的 Master 主机并提交查询语句。GP 会创建多个 DB 进程来处理查询。在 Master 上的称为执行分发器（ Query Dispatcher/QD ）。QD 负责创建、分发查询计划，汇总呈现最终结果。在 Segment 上，处理进程被称为查询执行器（ Query executor/QE ）。QE负责完成自身部分的处理工作以及与其他处理进程之间交换中间结果。
查询计划生成与派发查询被 Master 接收处理（ QD身份）。QD 将查询语句依据所定义的词法和语法规则创建原始查询语法树。接着在查询分析阶段，QD 将原始语法树转换为查询树。然后进入查询改写阶段，QD 将查询树依据系统中预先定义的规则对查询树进行转换。QD 最终调用优化器接受改写后的查询树，并依据该查询树完成查询逻辑优化和物理优化。GPDB 是基于成本的优化策略：评估若干个执行计划，找出最有效率的一个。但查询优化器必须全局的考虑整个集群，在每个候选的执行计划中考虑到节点间移动数据的开销。至此 QD 创建一个并行的或者定向的查询计划（根据查询语句决定）。之后Master将查询计划分发到相关的 Segment 去执行，每个 Segment 只负责处理自己本地的那部分数据操作。大部分的操作—比如扫表、关联、聚合、排序都是同时在 Segment 上并行被执行。每个具体部分都独立于其他 Segment 执行（一旦执行计划确定，比如有 join，派发后 join 是在各个节点分别进行的，本机只和本机的数据 join ）。
由于 GPDB 采用 Shared-Nothing 架构，为了最大限度的实现并行化处理，当节点间需要移动数据时，查询计划将被分割，最终一个查询会分为多个切片（ slice ），每个切片都涉及不同处理工作。即：先执行一步分操作，然后执行数据移动，再执行下一步分操作。在查询执行期间，每个 Segment 会根据查询计划上 slice 的划分，创建多个 postgres 工作进程，并行的执行查询。每个 slice 对应的进程只处理属于自己部分的工作，且这些处理工作仅在本 Segment 上执行。slice 之间为树形结构，其整体构成整个查询计划。不同 Segment 之间对应的查询计划上的同一个 slice 处理工作称为一个簇（ gang ）。在当前 gang 上的工作完成后，数据将向上传递，直到查询计划完成。Segment之间的通信涉及到 GPDB 的网络层组件（ Interconnect ）。