当业务数据从 GB 涨到 TB、PB，单机 PostgreSQL 的 OLAP 查询会越来越吃力。Greenplum 是 Pivotal 开源的 MPP（大规模并行处理）数据仓库，它复用 PostgreSQL 引擎，把数据按分布键打散到多个 Segment 节点并行计算。本文带你从零跑通一个 Greenplum 集群，并讲清分布键、外部表加载与资源队列调优。
一、Greenplum 是什么：MPP 与 PostgreSQL 血缘
Greenplum 本质是”一堆 PostgreSQL 实例 + 一个协调节点（Coordinator）”。Coordinator 接收 SQL、生成分布式执行计划，把算子下推到各个 Segment 并行执行，最后汇总结果返回客户端。它兼容绝大多数 PostgreSQL 协议与 SQL，所以你既可以用 psql、JDBC 连接，也能照常写窗口函数、CTE。区别在于：单表数据被水平切片到所有 Segment，聚合、关联在节点间并行完成——这正是它能扛 PB 级分析的根因。关于 PostgreSQL 本身的查询优化思路，可参考本站 PG 慢查询优化。
二、快速起步：用 Docker 拉起单节点集群
开发验证最省事的方式是容器。下面用 docker-compose 拉起一个单节点 Greenplum（镜像标签以官方仓库为准，部署前请用 docker pull greenplum/greenplum:<tag> 确认可用版本）：
version: "3"
services:
gp:
image: greenplum/greenplum:7
container_name: greenplum
hostname: gp
environment:
- GP_PASSWORD=changeme123
ports:
- "5432:5432"
volumes:
- gpdata:/data
volumes:
gpdata: {}
容器起来后，进入容器初始化系统并启动：
# 进入容器
docker exec -it greenplum bash
# 切到 gpadmin 用户
su - gpadmin
# 单节点初始化（greenplum 自带一键脚本）
gpdeletesystem -d /data/gpdata # 如需清理重来
gpinitsystem -c /home/gpadmin/gpconfigs/gpinitsystem_config
# 启动 / 停止
gpstart -a
gpstop -a
初始化完成后用 psql -d postgres 即可连上。生产环境通常是多节点集群，靠 gpinitsystem 的配置文件声明 Segment 主机列表，原理相同。
三、核心概念：分布键、分区与存储
Greenplum 的表有两层”切分”：一是分布（Distribution），决定一行数据落到哪个 Segment；二是分区（Partition），是单 Segment 内部的逻辑拆分，便于 pruning。两者叠加才构成完整的物理布局。如果你还不熟悉 Docker Compose 一键编排，建议先补一下容器基础。
| 维度 | 作用 | 常见策略 |
| 分布键 DISTRIBUTED BY | 把行打散到各 Segment，实现并行 | 高基数列做哈希；无关表用 RANDOMLY |
| 分区 PARTITION BY | 单 Segment 内按范围/列表裁剪 | 按时间 RANGE，按地区 LIST |
| 存储类型 | 行存 vs 列存 | 频繁更新的小表用堆表；大宽表分选用 AO 列存 |
四、建表实战：分布键怎么选
分布键选错，会出现”数据倾斜”——大部分行集中到一两个 Segment，并行度名存实亡。经验法则：选高基数、且常出现在 JOIN/WHERE 上的列，让数据均匀散开。
-- 订单表：用 user_id 做分布键（高基数、常做关联）
CREATE TABLE orders (
order_id BIGINT,
user_id BIGINT,
amount NUMERIC(12,2),
status VARCHAR(20),
created_at DATE
)
DISTRIBUTED BY (user_id);
-- 维度小表：分布均匀无所谓，随机分布反而省规划开销
CREATE TABLE dim_region (
region_id INT,
region_name VARCHAR(50)
)
DISTRIBUTED RANDOMLY;
-- 查看分布是否均匀
SELECT gp_segment_id, count(*)
FROM orders
GROUP BY gp_segment_id
ORDER BY gp_segment_id;
如果上面各 Segment 的计数差异巨大，就要重新评估分布键。可用 执行计划解读 的方式观察是否出现 “Broadcast Motion”（小表广播）或 “Redistribute Motion”（重分布）。
验证分布质量还有一个实用技巧：用 SELECT gp_segment_id, count(*) FROM 表名 GROUP BY 1 看各节点行数，再简单判断离散度。若最大 Segment 的行数是最小的 3 倍以上，基本可以确定存在倾斜，需要回表调整分布键。这一步应在数据首次入库后立即做，而不是等查询变慢才排查——越早纠正，重分布成本越低。
五、数据加载：COPY 与 gpfdist 外部表
小批量用 COPY 即可；大批量、多文件并行加载要用 gpfdist 外部表，才能吃满所有 Segment 的带宽。
-- 1) 单节点直接 COPY
COPY orders FROM '/data/orders.csv' WITH (FORMAT csv, HEADER);
-- 2) 启动 gpfdist 服务（在每个数据节点上）
gpfdist -d /data -p 8080 &
-- 3) 建外部表指向 gpfdist
CREATE EXTERNAL TABLE ext_orders (
order_id BIGINT, user_id BIGINT, amount NUMERIC(12,2),
status VARCHAR(20), created_at DATE
)
LOCATION ('gpfdist://gp:8080/orders*.csv')
FORMAT 'CSV' (HEADER);
-- 4) 把外部表数据搬进正式表（并行入库）
INSERT INTO orders SELECT * FROM ext_orders;
外部表本身不落库，适合做 ETL 的”暂存层”。用 gpload 还能把 YAML 描述的加载任务固化成可重复脚本，配合 CI 使用。
六、性能调优：执行计划与资源队列
排错第一步永远是 EXPLAIN ANALYZE。重点看是否有倾斜的 “Redistribute Motion”、是否走了不合理的广播，以及各 Segment 的执行时间是否均衡。
EXPLAIN ANALYZE
SELECT user_id, sum(amount)
FROM orders
WHERE created_at >= '2026-01-01'
GROUP BY user_id
ORDER BY sum(amount) DESC
LIMIT 100;
Greenplum 用资源队列（Resource Queue）做多租户限速，避免一条大查询吃光内存拖垮全集群：
-- 给 ETL 角色单独限流
CREATE RESOURCE QUEUE etl_q WITH (ACTIVE_STATEMENTS=5, MEMORY_LIMIT='4GB');
ALTER ROLE etl_user RESOURCE QUEUE etl_q;
-- 查看队列占用
SELECT * FROM gp_toolkit.gp_resqueue_status;
七、备份恢复与高可用
官方推荐 gpbackup/gprestore 做并行备份，它会按 Segment 并发写出，速度快且支持增量：
# 全量备份
gpbackup --dbname analytics --backup-dir /backup/gp
# 恢复
gprestore --timestamp 20261019020000 --backup-dir /backup/gp
# 给 Coordinator 配一个Standby，提升可用性
gpinitstandby -s gp-standby
八、Greenplum 适合谁：选型对照表
| 方案 | 定位 | 写入 | 查询特点 | 适用场景 |
| Greenplum | MPP OLAP | 批量大 | 复杂 SQL / 多表关联 | PB 级交互式分析 |
| ClickHouse | 列存 OLAP | 实时 append | 单表聚合极快 | 日志 / 指标宽表 |
| Hive / SparkSQL | 离线数仓 | 批 | 超大规模 ETL | TB~EB 离线 |
| PostgreSQL | OLTP | 行级 | 事务 / 点查 | 业务库 |
九、常见坑与排障清单
| 现象 | 根因 | 处理 |
| 查询倾斜慢 | 分布键选择不当，数据集中到个别 Segment | 改用高基数列做分布键，重分布数据 |
| 加载慢 | 单文件串行 COPY | 用 gpfdist 多文件并行外部表 |
| 内存不足报错 | 资源队列内存受限 | 调大 MEMORY_LIMIT 或分批提交 |
| 节点宕机 | Segment 故障 | gpstate -e 看状态，gpinitstandby 备节点 |
十、分区表与 JOIN 共线实战
分区和分布是两个独立维度。分布决定跨节点打散，分区决定单节点内按时间或地域裁剪。最典型的用法是”按时间 RANGE 分区 + 高基数列分布”，让最近数据的查询只扫描少数分区，既加速又省 IO。
CREATE TABLE orders (
order_id BIGINT, user_id BIGINT, amount NUMERIC(12,2),
status VARCHAR(20), created_at DATE
)
DISTRIBUTED BY (user_id)
PARTITION BY RANGE (created_at)
(
START ('2026-01-01') END ('2027-01-01') EVERY ('1 month')
);
当两张大表使用同一个分布键关联时，Greenplum 可以做”共线 JOIN（Colocated Join）”，直接在各自 Segment 本地完成关联，无需跨节点重分布数据，性能提升非常明显。建表时让事实表与明细表共用分布键即可：
-- order_items 与 orders 都用 user_id 分布，关联无需重分布
CREATE TABLE order_items (
item_id BIGINT, order_id BIGINT, user_id BIGINT,
sku VARCHAR(30), qty INT
)
DISTRIBUTED BY (user_id);
EXPLAIN ANALYZE
SELECT o.order_id, sum(i.qty)
FROM orders o
JOIN order_items i
ON i.user_id = o.user_id AND i.order_id = o.order_id
GROUP BY o.order_id;
-- 计划里应看到 "Hash Join"，而不该出现 "Redistribute Motion"
如果发现计划里仍有 Redistribute Motion，说明两张表的分布键不一致，要么调整建表，要么接受一次性的重分布代价。把热关联表的分布键对齐，是 Greenplum 调优里性价比最高的一招。
十一、小结
Greenplum 把 PostgreSQL 的易用性和 MPP 的并行能力结合得很好：会用 psql 就能上手，难点在于分布键设计与资源队列治理。记住三条铁律——分布键要高基数、大加载走 gpfdist、重查询进资源队列。把它当成 PB 级交互式分析的底座，配合列式存储与分区，性能与可维护性都会很稳。写 SQL 时顺手用 VS Code 的数据库插件 连上去调试，效率更高。
