Greenplum分布式查询实战：并行扫描与数据分布策略调优方案

Greenplum是基于PostgreSQL的MPP（大规模并行处理）分析型数据库，通过数据分布和并行扫描实现TB级数据的快速查询。理解数据分布策略和并行查询机制是Greenplum性能调优的核心。

Greenplum架构与并行查询原理

Greenplum由Master节点和多个Segment节点组成。Master负责接收SQL、生成执行计划、协调Segment执行并汇总结果。每个Segment是一个独立的PostgreSQL实例，存储部分数据并独立执行查询。数据按分布键的哈希值打散到各Segment，查询时各Segment并行扫描本地数据，最后由Master汇总。

这种架构下，查询性能取决于两个因素：数据分布是否均匀（避免数据倾斜），以及查询能否在各Segment上并行执行（避免数据重分布）。

数据分布策略配置

Greenplum支持两种分布策略：DISTRIBUTED BY（哈希分布）和DISTRIBUTED RANDOMLY（随机分布）。

-- 创建表时指定分布键
CREATE TABLE sales (
    id          bigint,
    sale_date   date,
    product_id  int,
    store_id    int,
    amount      numeric(12,2),
    region      varchar(50)
) DISTRIBUTED BY (store_id);

-- 随机分布（适用于没有合适分布键的表）
CREATE TABLE temp_log (
    id          bigint,
    log_time    timestamp,
    content     text
) DISTRIBUTED RANDOMLY;

-- 查看表的分布策略
SELECT
    schemaname,
    tablename,
    distkey,
    distpolicy
FROM pg_distribution
WHERE tablename = 'sales';

-- 检查各Segment数据量是否均衡
SELECT
    gp_segment_id,
    count(*) AS row_count
FROM sales
GROUP BY gp_segment_id
ORDER BY gp_segment_id;

选择分布键的三个原则：

• 选择高基数列（如ID、UUID），避免低基数列（如性别、状态）导致数据倾斜
• 优先选择JOIN条件中使用的列，使关联表的数据落在同一Segment上，避免重分布
• 避免使用经常更新的列作为分布键，更新分布键值会导致数据迁移

数据倾斜诊断与处理

数据倾斜是Greenplum最常见的问题——某个Segment存储了远超平均值的数据量，导致查询时该Segment成为瓶颈。

-- 诊断1：检查表的各Segment数据量
SELECT
    gp_segment_id,
    count(*) AS rows,
    pg_size_pretty(pg_total_relation_size('sales')) AS table_size
FROM sales
GROUP BY gp_segment_id
ORDER BY rows DESC;

-- 诊断2：检查各Segment总存储量
SELECT
    gp_segment_id,
    pg_size_pretty(sum(pg_relation_size(tableoid))) AS seg_size
FROM gp_dist_random('pg_class')
GROUP BY gp_segment_id
ORDER BY seg_size DESC;

-- 诊断3：识别倾斜键值
SELECT
    store_id,
    count(*) AS cnt,
    count(*) * 100.0 / (SELECT count(*) FROM sales) AS pct
FROM sales
GROUP BY store_id
ORDER BY cnt DESC
LIMIT 20;

如果某键值占比较高（如超过5%），处理方案：

-- 方案1：使用复合分布键
ALTER TABLE sales SET DISTRIBUTED BY (store_id, sale_date);

-- 方案2：对大表分区+随机分布
CREATE TABLE sales_partitioned (
    id bigint,
    sale_date date,
    store_id int,
    amount numeric(12,2)
) DISTRIBUTED RANDOMLY
PARTITION BY RANGE (sale_date)
(
    START (date '2026-01-01') END (date '2026-04-01'),
    START (date '2026-04-01') END (date '2026-07-01'),
    START (date '2026-07-01') END (date '2026-10-01'),
    START (date '2026-10-01') END (date '2027-01-01')
);

-- 方案3：膨胀系数高的列拆分后再分布
-- 当某个值天然重复很多时（如status='active'），
-- 可以concat一个随机后缀

执行计划分析与重分布优化

查询执行中如果涉及跨Segment的数据关联，Greenplum会触发数据重分布（Motion操作）。重分布是Greenplum中开销最大的操作之一。

-- 查看执行计划
EXPLAIN ANALYZE
SELECT s.store_id, p.product_name, sum(s.amount) AS total
FROM sales s
JOIN products p ON s.product_id = p.product_id
WHERE s.sale_date >= '2026-01-01'
GROUP BY s.store_id, p.product_name;

-- 执行计划中的关键Motion节点：
-- Redistribute Motion  -- 数据按新的分布键重新分布
-- Broadcast Motion     -- 小表广播到所有Segment
-- Gather Motion        -- Segment结果汇总到Master

常见的重分布场景和优化方法：

分区表与并行扫描优化

分区表让Greenplum的查询裁剪不相关的分区，减少扫描数据量。分区与分布是正交的两个维度——分布决定数据在Segment间如何切片，分区决定每个Segment上数据如何组织。

-- 创建按月分区的大表
CREATE TABLE order_fact (
    order_id    bigint,
    order_date  date,
    customer_id int,
    product_id  int,
    quantity    int,
    unit_price  numeric(10,2),
    total_price numeric(12,2)
) DISTRIBUTED BY (order_id)
PARTITION BY RANGE (order_date)
(
    PARTITION p_202601 START (date '2026-01-01') END (date '2026-02-01'),
    PARTITION p_202602 START (date '2026-02-01') END (date '2026-03-01'),
    PARTITION p_202603 START (date '2026-03-01') END (date '2026-04-01'),
    -- ... 其他月份
    DEFAULT PARTITION p_default
);

-- 验证分区裁剪是否生效
EXPLAIN SELECT * FROM order_fact
WHERE order_date >= '2026-02-01' AND order_date < '2026-03-01';
-- 执行计划应只扫描p_202602分区，不扫描其他分区

-- 查看各分区大小
SELECT
    partitiontablename,
    partitionlevel,
    partitionrank,
    pg_size_pretty(pg_total_relation_size(partitiontablename))
FROM pg_partitions
WHERE tablename = 'order_fact'
ORDER BY partitionrank;

VACUUM与统计信息维护

Greenplum继承了PostgreSQL的MVCC机制大量删除和更新后会产生死元组，影响扫描效率。定期VACUUM ANALYZE确保执行计划基于最新的统计信息。

-- 分析表（更新统计信息）
ANALYZE sales;

-- 指定列分析
ANALYZE sales (store_id, amount);

-- VACUUM回收死元组
VACUUM sales;

-- VACUUM FULL重建表（需要锁表，在维护窗口执行）
VACUUM FULL sales;

-- 使用gpupdate统计信息
SET gp_analyze_relative_error=0.01;  -- 提高统计精度
ANALYZE sales;

-- 自动VACUUM配置
-- 在postgresql.conf中
-- gp_autostats_mode = on_change
-- gp_autostats_on_change_threshold = 100000000
-- 当表变更行数超过1亿时自动触发ANALYZE

统计信息的准确性直接影响执行计划质量。对于数据倾斜严重的列，可以手动提高统计目标：ALTER TABLE sales ALTER COLUMN store_id SET STATISTICS 1000;，然后重新ANALYZE该列。