未记录事实核验 · 状态：维护中

记录仅说明核验时间与维护状态，不保证适用于所有环境；使用前请留意正文中的版本、适用条件与风险提示。

warning 适用范围与待维护事项

本文是Greenplum面试复盘题库，不是已验证的生产操作手册。原稿混用了不同版本的优化器、分区、资源管理和监控行为，未提供测试环境或官方依据；ORCA、Interconnect、加载吞吐与故障切换数字均不可作为性能承诺。执行DDL、分布键重写、内存调整或历史数据删除前，须按目标版本在测试环境验证并评估锁、磁盘与并发影响。Q32还缺少暂存表定义、代理键生成、事务与幂等设计，不能直接作为完整拉链表ETL上线。

warning 关联材料边界

以下原引用目标缺失或无法唯一确认，已取消跳转并保留提及：10-性能调优实战。相关素材/延伸说明暂不可用，不能据此声称已经提供配套材料。

Greenplum高频面试题 - 40道含答案

abstract 学习目标

系统梳理Greenplum面试的4大核心考察方向
理解每道题背后的技术原理，建立可回答追问的知识体系
掌握Greenplum与其他MPP系统的对比分析能力

quote 核心洞察

Greenplum面试的本质是考察你对MPP分布式数据库的理解深度。面试官最想听到的回答，是你能把理论（MPP架构、分布键原理）和实践（生产遇到的倾斜问题、调优经历）结合起来讲。没有生产经验的候选人，至少要能清晰解释"为什么这样设计"，而不只是"怎么操作"。

第一类：架构原理（10题）

Q1. Greenplum的MPP架构与传统数据库（如MySQL、Oracle）的本质区别是什么？

以单机部署的MySQL、Oracle为例，数据库通常利用共享内存的多处理器资源，纵向扩展（Scale Up）有硬件上限；这些产品也有其他部署架构，不能一概归为单机SMP。原稿“单节点数据量超过几TB时性能下降明显”未提供测试依据，不能作为统一容量阈值。Greenplum采用Shared Nothing MPP架构，每个Segment节点拥有独立的CPU、内存和磁盘，一个查询被分割为多个子任务在所有节点并行执行，然后汇总结果。横向扩展（Scale Out）可增加处理资源，但原稿“节点数量翻倍，处理能力翻倍”仅是未核实的理想化示例，实际扩展效率受数据倾斜、网络、存储及查询并行度限制。核心代价是节点间需要通过网络传输数据（Motion），设计时需要最小化Motion开销。

Q2. Greenplum的Master节点和Segment节点各负责什么？

Master节点：接收客户端SQL连接，进行查询解析和语法检查，调用ORCA优化器生成分布式执行计划，将执行计划分发给所有Segment节点，汇总各Segment的结果并返回给客户端；存储系统目录（pg_catalog）和表的元数据；不存储业务数据。Segment节点：存储实际数据（按分布键哈希分配），执行Master分发的子计划，在本地执行过滤、聚合、排序等操作，通过Interconnect与其他Segment交换数据（Motion），将结果返回给Master。通常一台物理机上运行多个Segment进程（每CPU核对应1-2个Segment）。

Q3. 什么是Motion？Greenplum有哪几种Motion类型？

Motion是Greenplum执行查询时不同Segment之间的数据传输操作，是MPP系统中代价最高的操作之一，通过Interconnect（通常是UDP/TCP网络）完成。三种类型：Redistribute Motion（重分布）将数据按指定列的哈希值重新分配到不同Segment，用于GROUP BY、JOIN等操作中需要将相关数据聚集到同一Segment时；Broadcast Motion（广播）将一个Segment的数据全量发送到所有Segment，适合小表（通常优化器自动选择，当表很小时广播比重分布代价低）；Gather Motion（汇聚）将多个执行进程的结果汇集到一个接收进程，向客户端返回分布式查询结果时常汇集到Master节点；它并非每条语句都必需的最后一步。减少Motion是Greenplum性能优化的核心目标。

Q4. 什么是Collocated Join（本地关联）？如何实现？

Collocated Join指两张表在兼容的分布策略下，关联条件覆盖相应分布键，相关数据已位于同一Segment，JOIN输入无需为关联进行重分布或广播；查询的其他阶段仍可能存在Motion。实现方法：创建两张经常JOIN的表时，使用相同的分布键列，且列的数据类型必须完全一致（类型不同会触发隐式转换，破坏Collocated）。例如，orders表和order_items表都按order_id分布，JOIN ON orders.order_id = order_items.order_id就是Collocated Join。通过EXPLAIN命令验证是否实现了Collocated Join：检查JOIN两侧输入路径是否为关联引入Redistribute或Broadcast Motion，并结合分布键与关联条件判断；JOIN上方的Gather Motion可能只是结果汇聚，不能据此判断是否为Collocated Join。

Q5. Greenplum如何实现高可用？Primary和Mirror的关系是什么？

Greenplum通过Primary/Mirror机制实现Segment层的高可用。每个Primary Segment都有一个对应的Mirror Segment，两者存储完全相同的数据（通过流复制同步）。Primary和Mirror不允许在同一台物理机上（通过mirror grouping策略保证）。当Primary Segment发生故障时，Coordinator（Master）检测到后自动将对应的Mirror提升为新Primary，原稿给出的“1-3分钟”是未核实的切换耗时示例，不是故障恢复承诺；实际时间取决于版本、故障检测与集群状态，受影响的查询可能失败并需要重试。Master节点本身通过Standby Master实现高可用，Standby Master实时同步Master的系统目录数据，Master故障时可手动切换（不自动）。

Q6. Greenplum的分布式事务是如何工作的？

Greenplum使用两阶段提交（2PC）协议保证分布式事务的ACID特性。第一阶段（准备阶段）：Master向所有相关Segment发送PREPARE命令，各Segment将变更写入磁盘（redo log）并进入预提交状态；第二阶段（提交阶段）：所有Segment都回复PREPARED后，Master发送COMMIT命令，各Segment确认提交；若任何Segment在准备阶段失败，Master发送ROLLBACK，所有Segment回滚。代价：分布式事务比单机事务有更高的延迟（需要多次网络往返）和更复杂的故障恢复逻辑。这也是为什么Greenplum的写入性能不如单机OLTP数据库。

Q7. Greenplum与PostgreSQL的主要差异是什么？

Greenplum基于PostgreSQL构建，继承了大部分PostgreSQL特性，但有以下关键差异：1）支持满足分布策略限制的主键和唯一约束，通常要求约束列覆盖全部分布键；外键约束不提供与单机PostgreSQL相同的强制检查，具体限制需按版本确认；2）不能把序列（SEQUENCE）概括为各Segment独立的本地序列，序列取值由协调机制管理，正常调用可用于生成不同键值，但缓存、回滚等会产生间隙，不保证连续；3）VACUUM机制不同（没有autovacuum，需要手动执行或配置）；4）索引使用频率低（MPP全表扫描+分区裁剪通常比索引更高效）；5）增加了分布式执行特有的语法（DISTRIBUTED BY、EXCHANGE PARTITION等）；6）不支持某些PostgreSQL特性（如规则Rule的某些用法）。SQL方言兼容PostgreSQL，已有PostgreSQL技能可以直接转移。

Q8. ORCA优化器相比传统Planner有什么优势？

ORCA（Pivotal Query Optimizer）是Greenplum 4.x引入的新一代查询优化器，针对分布式场景专门设计。优势：1）更好的JOIN Reorder：能处理更多表的最优JOIN顺序（传统Planner对表数量有限制）；2）更精确的统计信息利用：能更好地利用列统计信息做代价估算；3）更好的分区裁剪：特别是动态分区裁剪（Greenplum 6+）；4）CTE优化：能更好地处理公用表表达式（决定是否内联还是物化）；5）子查询优化：更好地将子查询提升为JOIN。原稿称“在TPCH等标准测试集上，ORCA比传统Planner快30-50%”，但未提供测试版本、数据规模、查询集、配置或来源；该数字仅保留为未核实示例，不代表通用性能结论，应在目标负载上对比执行计划与耗时。

Q9. 什么是Greenplum的Dispatch机制？

Dispatch是Master将查询计划分发给所有Segment的过程。Master生成完整的分布式执行计划后，将计划序列化并通过分发连接发送给参与执行的Segment的QE（Query Executor）进程；Interconnect主要用于执行期间的数据交换，不应与计划分发混为一谈；每个Segment并行接收计划并开始执行；各Segment的QE进程之间通过Interconnect相互通信（Motion）；所有Segment执行完毕后，结果通过Gather Motion汇聚到Master。Dispatch的效率影响查询启动延迟，对于大量小查询（高并发短查询）场景，Dispatch开销占比较大，这是Greenplum不适合OLTP高并发点查的原因之一。

Q10. Greenplum的Interconnect是什么？UDP和TCP模式有什么区别？

Interconnect是Greenplum Segment之间进行数据交换（Motion）的网络通信层。默认使用UDP模式（UDPIFC），在应用层实现了可靠传输（流量控制、丢包重传、乱序重组），原稿“性能比TCP模式高约20-30%”缺少测试条件和来源，仅保留为未核实示例；不能仅凭TCP三次握手与拥塞控制推断整体查询性能差异。TCP模式通过gp_interconnect_type选择，是否更适合目标网络需结合版本支持、网络配置和实测结果判断；不能将TCP一概视为更稳定，也不能无条件要求生产优先使用UDP模式。相关参数：gp_interconnect_type控制模式；gp_interconnect_queue_depth控制每个连接的缓冲深度；网络带宽是Interconnect的物理瓶颈，建议Segment节点之间使用万兆网络（10Gb+）。

第二类：分布键设计（10题）

Q11. 分布键的选择为什么是Greenplum最重要的设计决策？

分布键决定了数据在各Segment上的物理分布，一旦确定后修改代价极高（需要重写全表数据）。分布键选择的好坏直接影响：1）数据均匀性（避免倾斜，确保各Segment工作量均衡）；2）JOIN是否需要Motion（分布键对齐的两表JOIN可在本地完成，无网络开销）；3）GROUP BY是否需要重分布（按分布键分组可在本地完成）。原稿“90%的查询无需Motion”和“性能是差分布键方案的数倍到数十倍”缺少查询集与测试依据，仅作为未核实示例保留；合理分布键主要减少不必要的重分布或广播，并不消除结果汇聚等所有Motion。这是MPP数据库区别于其他数据库的核心设计挑战。

Q12. 如何判断分布键是否合理？给出一个诊断倾斜的完整流程。

诊断步骤：1）首先查看各Segment数据量分布：SELECT gp_segment_id, COUNT(*) FROM table_name GROUP BY 1 ORDER BY 2 DESC，理想状态各Segment行数差距<10%；2）使用GP内置工具计算变异系数：SELECT * FROM gp_toolkit.gp_skew_coefficients WHERE skcrelname='table_name'，skewcoeff表示行数分布的变异系数百分比，不能把>1.0直接判定为严重倾斜，应结合Segment数量、行数分布与工作负载判断；3）查看扫描因倾斜产生的空闲比例：SELECT * FROM gp_toolkit.gp_skew_idle_fractions WHERE sifrelname='table_name'，该视图不是磁盘占用指标，物理存储倾斜需另查各Segment的表文件大小；4）EXPLAIN ANALYZE目标查询，观察各Segment实际处理时间是否均衡。解决方案：更换高基数分布键（ALTER TABLE...SET DISTRIBUTED BY），或使用复合分布键，或改为DISTRIBUTED RANDOMLY（牺牲Collocated Join能力换取均匀分布）。

Q13. 以下哪些列不适合作为分布键？为什么？

不适合的列：1）低基数列，如status（只有0/1/2），会导致大量行哈希到少数Segment，严重倾斜；2）NULL值多的列，NULL值通常映射到同一Segment，产生倾斜；3）频繁更新的列，分布键列更新时需要将行移动到新的Segment（实际是删除+插入），代价极高；4）TEXT/VARCHAR超长列，可能增加哈希计算及数据处理开销；高基数本身不是倾斜原因，应评估值频率分布、常用JOIN条件与实际处理成本；5）外键指向低基数维度的列（如category_id只有100个类别）。好的分布键特征：高基数（唯一值多）、均匀分布、与最常用JOIN键对齐、稳定不常更新。

Q14. DISTRIBUTED RANDOMLY和DISTRIBUTED BY有什么区别？各适合什么场景？

DISTRIBUTED BY（哈希分布）：按指定列的哈希值分配数据到Segment，相同值的行总是在同一Segment，支持Collocated Join，但可能因数据分布不均导致倾斜。DISTRIBUTED RANDOMLY（随机分布/Round Robin）：数据按轮询方式分配到各Segment，通常有助于均衡存储行数，但多次小批量写入和后续计算仍可能产生倾斜；它不保证相同键值共置，JOIN可能需要重分布或广播，也可能利用另一侧的复制表本地执行，并非每次都需要Redistribute Motion。适用场景：RANDOMLY适合：无法找到合适分布键的临时表/中间结果表、ETL staging表、不参与JOIN的独立查询；DISTRIBUTED BY适合：所有长期存在的事实表和维度表（选好分布键）。

Q15. 什么是DISTRIBUTED REPLICATED？适合什么场景？

DISTRIBUTED REPLICATED（Greenplum 6.x引入）：每个Segment都存储表的完整副本，相当于每个Segment都是全量数据。优点：与事实表进行适合本地执行的JOIN时，可避免为该关联重分布或广播输入数据；结果汇聚及查询其他阶段仍可能存在Motion。缺点：存储开销是哈希分布的N倍（N=Segment数量）；写入时需要向所有Segment写，写入代价高；通常不适合大表，因为每个Segment都需保存完整的磁盘副本，并增加写入与扫描成本；表不必整体装入内存，但应评估每个Segment的磁盘容量、工作集和查询内存。适用场景：小维度表（日期表/城市表/商品类别表等，通常<100万行）；系统配置表；跨Segment共享的参数表。

Q16. 如何处理分布键倾斜导致的查询性能问题（已上线，无法修改分布键）？

紧急处理方案：1）分批查询，对倾斜数据单独处理：将大量集中在某几个值的热点数据单独查询，与其他数据UNION ALL合并；2）增加guc参数：SET gp_workfile_limit_per_segment增大溢出文件限制，避免内存溢出报错；3）资源队列降级：给这类查询分配更多内存配额（SET statement_mem）；根本解决方案：在维护窗口执行ALTER TABLE...SET DISTRIBUTED BY (new_key)重写数据；或者建立采用新分布策略的独立中间表，重分布热点数据后再查询；不能假定同一分区表的各分区可任意采用不同分布键，分区与父表的分布策略兼容要求需按版本确认。事后建立监控，在数据量还小的时候及时发现倾斜。

Q17. 复合分布键与单列分布键如何选择？

单列分布键：简单，便于维护，JOIN时只需单列匹配即可实现Collocated。优先选择单列分布键。复合分布键的适用场景：单列基数不足以均匀分布时（如user_id只有1000个用户，按user_id分布到32个Segment时，应结合用户数据量差异与实际哈希分布判断是否均匀，不能仅凭这两个数量断定倾斜）；业务上最常用的JOIN条件是多列的（如按user_id + date_key联合分布，与经常按这两列JOIN的表对齐）。注意：使用复合分布键时，通常需要JOIN等值条件覆盖双方兼容分布策略中的全部分布键列，才能保证Collocated Join；缺少其中一列时不能保证数据共置，优化器可能选择Redistribute或Broadcast Motion，应检查执行计划。

Q18. 如何用SQL验证两张表的JOIN是否触发了Motion？

-- 方法：EXPLAIN命令，查看JOIN两侧输入路径是否为关联引入Redistribute或Broadcast Motion
EXPLAIN SELECT a.col1, b.col2
FROM table_a a
JOIN table_b b ON a.join_key = b.join_key;

-- Collocated Join的执行计划特征（无Motion）：
-- Hash Join
--   Hash Cond: (a.join_key = b.join_key)
--   -> Seq Scan on table_a
--   -> Hash
--        -> Seq Scan on table_b

-- 有Motion的执行计划（非Collocated）：
-- Hash Join
--   Hash Cond: (a.join_key = b.join_key)
--   -> Redistribute Motion 8:8  (Hash Key: a.join_key)
--        -> Seq Scan on table_a
--   -> Hash
--        -> Redistribute Motion 8:8  (Hash Key: b.join_key)
--             -> Seq Scan on table_b

Q19. 什么情况下Greenplum优化器会选择Broadcast Motion而非Redistribute Motion？

当优化器估算一张表的数据量远小于另一张表时，会选择将小表Broadcast（广播）到所有Segment，而非重分布大表。代价比较：Broadcast代价 = 小表大小 × Segment数量；Redistribute代价 = 大表大小 × 网络传输代价。当小表非常小（例如几千行），Broadcast代价低于重分布大表的代价，优化器选择Broadcast。问题：如果统计信息不准确，优化器可能错误估算表大小，选错Motion类型（例如把一张实际很大的表当小表广播，造成网络风暴）。解决：定期ANALYZE更新统计信息，确保优化器估算准确。

Q20. 在Greenplum中，NULL值对分布键有什么影响？

对于单列哈希分布键，相同NULL值会映射到同一Segment，具体编号不能统一假定为Segment 0或低编号Segment；大量NULL可能导致倾斜。复合分布键还需结合其他键列判断。解决方案：1）按业务语义治理缺失值；仅用同一个默认值（如-1、'UNKNOWN'）替代NULL仍会集中到同一Segment，不能解决倾斜；2）若无法避免NULL，更换其他列作为分布键；3）使用DISTRIBUTED RANDOMLY（放弃Collocated Join换取均匀分布）；4）对NULL值多的情况，在ETL时做数据清洗。

第三类：性能调优（10题）

Q21. 如何读懂Greenplum的EXPLAIN ANALYZE输出？关键指标有哪些？

关键指标：1）算子执行时间（actual time=X..Y）：注意是每个Segment上的时间，若某Segment时间远高于其他，说明倾斜；2）实际行数（actual rows）vs 估算行数（rows）：差距超过10倍需要ANALYZE更新统计信息；3）Motion算子及其数据量：Redistribute/Broadcast Motion的数据量过大是主要性能瓶颈；4）Sort算子：若出现"Sort Method: external merge on disk"说明内存不足、数据溢出到磁盘，需要增加statement_mem；5）Seq Scan大表：若无法通过分区裁剪减少扫描量，考虑是否需要增加分区。读懂的关键：从内层算子向外层读，理解数据流动路径，找出耗时最长或数据量最大的节点。

Q22. ANALYZE在Greenplum中有多重要？何时需要执行？

ANALYZE是Greenplum最重要的维护操作之一。Greenplum不能照搬PostgreSQL的autovacuum维护方式；但缺少autovacuum不等于统计信息绝不会自动更新，部分数据操作可按gp_autostats_mode等配置触发自动ANALYZE，具体行为需按版本核实。统计信息过时会导致：优化器错误估算行数→选错JOIN算法→不必要的Redistribute Motion→选错是否广播小表。必须执行ANALYZE的场景：1）大批量数据加载完成后；2）分区表添加新分区并加载数据后；3）查询计划明显异常（估算行数与实际行数差距大）；4）新建表首次加载数据后。建议在ETL Pipeline的最后一步自动执行ANALYZE，并监控last_analyze时间（超过7天告警）。

Q23. Greenplum的数据倾斜（Skew）有哪几种类型？如何分别处理？

三种类型：1）数据倾斜（Data Skew）：各Segment上的行数不均匀，由分布键选择不当引起。诊断：SELECT gp_segment_id, COUNT(*) FROM t GROUP BY 1。处理：更换高基数分布键；2）计算倾斜（Processing Skew）：即使数据均匀，GROUP BY/JOIN操作后，某Segment需要处理的数据量远多于其他。诊断：EXPLAIN ANALYZE中各Segment实际行数差异大。处理：使用两阶段聚合、更换分布键；3）I/O倾斜：某Segment所在磁盘I/O负载过高。诊断：OS级别的iostat监控。处理：检查是否有热点分区、考虑均衡磁盘分布。

Q24. Greenplum中的分区裁剪什么时候会失效？

分区裁剪失效的常见场景：1）WHERE条件中对分区键使用了函数：WHERE YEAR(sale_date) = 2024→失效，改为WHERE sale_date >= '2024-01-01' AND sale_date < '2025-01-01'，使用半开区间以兼容日期或时间戳字段；2）分区键类型与WHERE条件类型不匹配（隐式类型转换）；3）动态WHERE条件（变量值在执行期才确定），Greenplum 5.x的静态分区裁剪无法处理，6.x支持动态分区裁剪；4）分区键被表达式包裹：WHERE TO_CHAR(sale_date, 'YYYYMM') = '202401'→失效。验证方式：EXPLAIN查看执行计划，若只扫描了目标分区的子表，说明裁剪生效。

Q25. 什么是workfile？何时会产生？如何减少？

Workfile（工作文件）是当查询的内存使用超过statement_mem限制时，溢出到磁盘的临时文件。产生场景：1）大规模Hash Join（Hash table装不进内存）；2）Sort操作（排序数据超过内存）；3）大规模Hash Aggregate（GROUP BY的中间结果超过内存）。影响：溢出到磁盘通常会增加查询耗时；原稿“磁盘I/O比内存操作慢100-1000倍”缺少设备、访问模式及测试依据，仅保留为未核实示例，不能直接推算查询耗时。减少方法：增加statement_mem：SET statement_mem = '2GB'；增加gp_workfile_compression（压缩workfile，减少磁盘I/O）；优化查询，减少需要排序/哈希的数据量（过滤条件下推、减少JOIN表数量）；升级内存配置（根本解决）。

Q26. Greenplum的资源队列如何配置才能合理控制多用户并发？

基本原则：按用户类型/查询类型分组，分配不同的并发数和内存限制。推荐配置：1）BI报表队列：ACTIVE_STATEMENTS=5-10（允许较多并发），MEMORY_LIMIT适中（单查询不需要太多内存），PRIORITY=MEDIUM；2）ETL批处理队列：ACTIVE_STATEMENTS=1-2（串行执行，每个任务要充分利用资源），MEMORY_LIMIT大，PRIORITY=LOW（不抢BI用户资源）；3）管理员队列：不设限制，用于紧急操作；4）默认队列（pg_default）：设置合理限制，防止未分配队列的用户消耗过多资源。建议配合MAX_COST限制防止意外的全表扫描大查询进入BI队列。

Q27. 大表JOIN时，小表应该如何选择分布策略？

有三个选项：1）DISTRIBUTED REPLICATED：每个Segment都有全量数据，可避免适用关联中的输入重分布或广播，但查询其他阶段仍可能有Motion；是否最优还需评估表大小、写入成本及关联类型，<100万行仅作为小维度表的经验示例；2）DISTRIBUTED BY（与大表相同的分布键）：Collocated Join，无Motion；适合中等维度表（百万到千万行），且JOIN条件与分布键一致；3）DISTRIBUTED RANDOMLY（随机分布）：JOIN时可能重分布一侧或两侧，也可能广播小表，不能断言大表必定需要Redistribute Motion；应结合表大小、关联条件与执行计划评估，仅当无法确定合适分布键时考虑使用。决策顺序：先看表大小，能用REPLICATED就用；否则让小表的分布键与最常JOIN的大表对齐。

Q28. 如何优化一个包含多次GROUP BY的复杂SQL？

步骤：1）EXPLAIN ANALYZE找出最耗时的算子；2）检查每个GROUP BY是否触发了不必要的Redistribute Motion（若GROUP BY key是分布键，可在本地完成）；3）将多个GROUP BY用CTE（WITH子句）分步执行，让优化器可以单独优化每步；4）检查是否有重复计算（相同子查询执行多次），可在支持相应语法的版本中评估物化CTE（MATERIALIZED）；旧版本不能直接套用该语法，且物化是否减少重复计算需通过执行计划验证；5）考虑是否可以预聚合（提前生成中间汇总表）；6）对于超复杂查询，考虑拆分为多个步骤，将中间结果写入临时表，分步执行。

Q29. Greenplum中如何有效地监控集群的性能状态？

关键监控查询：

-- 1. 当前活跃查询
SELECT * FROM pg_stat_activity WHERE state = 'active' ORDER BY query_start;

-- 2. 长时间运行的查询（超过5分钟）
SELECT pid, usename, EXTRACT(EPOCH FROM (NOW()-query_start)) AS secs, LEFT(query,100)
FROM pg_stat_activity WHERE state='active'
  AND EXTRACT(EPOCH FROM (NOW()-query_start)) > 300;

-- 3. 资源队列等待情况
SELECT * FROM gp_toolkit.gp_resqueue_status;

-- 4. 磁盘溢出文件（workfile）
SELECT * FROM gp_toolkit.gp_workfile_entries;

-- 5. Segment健康状态
SELECT * FROM gp_segment_configuration WHERE status = 'd';

-- 6. 数据库膨胀（需要VACUUM的表）
SELECT * FROM gp_toolkit.gp_bloat_diag WHERE bdidiag != 'no bloat detected';

Q30. 为什么Greenplum不推荐大量使用B-Tree索引？

在MPP架构中，查询通常会扫描大量数据（全表或大分区），B-Tree索引在以下方面表现不如分区裁剪：1）索引是Segment本地的，无法跨Segment使用，对于分布式表，即使有索引也需要所有Segment都扫描各自的索引；2）随机I/O代价高，大范围查询时全表扫描（顺序I/O）反而比索引（随机I/O）快；3）索引维护代价：INSERT/UPDATE需要维护受影响Segment上的本地索引，可能降低批量写入性能，并非每次操作都维护所有Segment上的索引；4）Greenplum的优化是通过分区裁剪减少数据扫描量，通过列存储减少I/O，效果往往优于索引。索引的适用场景：非常高选择性的点查（唯一索引）、与CLUSTER命令配合物理排序数据。

第四类：数仓建模实践（10题）

Q31. 在Greenplum中实现星型模型时，事实表和维度表各应该用什么分布策略？

事实表：DISTRIBUTED BY（选择高基数的外键列，与最常JOIN的维度表分布键一致），使用列存AO表，按日期分区。维度表策略按大小分类：小维度表（<100万行，如日期维度、城市维度）可评估DISTRIBUTED REPLICATED，每个Segment有全量数据，适用的事实表关联可避免输入重分布或广播，但查询其他阶段仍可能有Motion；中等维度表（百万到千万行，如用户维度）用DISTRIBUTED BY（与事实表的对应外键分布键一致，实现Collocated Join）；大维度表（>千万行，如商品维度）同样DISTRIBUTED BY与事实表对齐。核心原则：让最频繁的JOIN发生在同一Segment，消除Redistribute Motion。

Q32. 如何在Greenplum中实现拉链表（SCD Type 2）？给出建表和更新SQL示例。

-- 建表（含有效期字段）
CREATE TABLE dim_user (
    user_key   INT,
    user_id    BIGINT,
    name       VARCHAR(50),
    city       VARCHAR(50),
    level      SMALLINT,
    start_date DATE,
    end_date   DATE    -- '9999-12-31' 表示当前有效
)
WITH (appendoptimized=true)
DISTRIBUTED BY (user_key);

-- 每日更新拉链表的ETL逻辑（示例）
-- Step1：关闭变更记录的旧有效期
UPDATE dim_user
SET end_date = CURRENT_DATE - 1
WHERE user_id IN (SELECT user_id FROM staging_user_changes)
  AND end_date = '9999-12-31';

-- Step2：插入新版本记录
INSERT INTO dim_user
SELECT next_user_key, user_id, name, city, level,
       CURRENT_DATE, '9999-12-31'
FROM staging_user_changes;

-- 查询某日期的历史状态
SELECT * FROM dim_user
WHERE user_id = 12345
  AND start_date <= '2024-06-01'
  AND end_date   >= '2024-06-01';

Q33. Greenplum的分区表有哪几种分区类型？各适合什么场景？

三种分区类型：1）范围分区（RANGE PARTITION）：按列值的范围分区，最常用，适合日期/时间列（如每天/每月一个分区）；2）列表分区（LIST PARTITION）：按列的枚举值分区，适合地区/状态等枚举类型（如按省份分区）；3）多级分区（SUBPARTITION）：先按一个维度分区，再按另一个维度子分区（如先按年分区，再按月子分区）。最常用：日期范围分区，因为几乎所有数据分析查询都有日期过滤条件，分区裁剪效果显著。建议：单级分区通常够用，多级分区会增加元数据量和管理复杂度，谨慎使用。

Q34. COPY命令和gpfdist加载数据各有什么优缺点？如何选择？

COPY命令：数据从Master节点流入，所有数据需经过Master再分发到各Segment，吞吐量受Master带宽限制；操作简单，无需部署额外服务。适合：小数据量加载（<1GB），ETL过程中的临时数据注入，不需要高吞吐。gpfdist（/gpload）：各Segment直接从gpfdist服务拉取数据，并行加载，原稿“吞吐量是COPY的N倍（N=Segment数量）”仅是未核实的理想化示例；实际提升取决于文件服务并发、网络、存储与数据转换成本，不能按Segment数量直接计算；需要部署gpfdist服务，配置略复杂。适合：大数据量批量加载（>1GB），日常ETL批量入库，性能要求高的场景。选择原则：日常ETL入库优先使用gpfdist；小表/临时场景使用COPY；Flink/Spark实时写入使用JDBC（INSERT语句）。

Q35. 如何高效地删除Greenplum中大表的历史数据？

通常优先考虑分区删除（原稿“毫秒级”未提供测试依据，实际耗时受锁等待、元数据和文件清理等因素影响）：ALTER TABLE fact_orders DROP PARTITION FOR (20200101)，直接删除分区目录，无需扫描数据。次选：分区TRUNCATE（清空分区但保留分区结构）：ALTER TABLE fact_orders TRUNCATE PARTITION FOR (20200101)。避免：直接DELETE：DELETE FROM fact_orders WHERE order_date_key < 20200101会产生大量"死行"，需要根据存储类型与空间回收目标安排VACUUM或维护窗口内的重写；并非必须使用VACUUM FULL，扫描范围也取决于分区裁剪和执行计划，写入及WAL开销需按实际负载评估。最佳实践：建表时就设计好分区策略，确保历史数据可以通过删除分区方式清理；按目标版本配置gp_autostats_mode等自动统计选项，并在加载流程中安排必要的ANALYZE；gp_autostats不是可直接定期执行的SQL维护命令，空间回收还需单独安排VACUUM。

Q36. 如何处理Greenplum中表的膨胀（Bloat）问题？

膨胀成因：DELETE和UPDATE操作会留下"死行"（dead rows），Greenplum不会自动清理。检测：SELECT * FROM gp_toolkit.gp_bloat_diag，关注bloat ratio（实际大小/预期大小）。处理方法：1）对堆表执行VACUUM：VACUUM table_name（清理死行，不减小文件大小）；2）VACUUM FULL（重建表，减小文件大小，但需要排他锁，会阻塞查询，只在维护窗口执行）；3）对AO表执行VACUUM：自动清理被标记删除的行；4）根本解决：对于频繁DELETE/UPDATE的场景，考虑改用分区删除/插入方式替代直接DELETE/UPDATE。

Q37. Greenplum与BI工具（如Tableau、Superset）对接时有哪些注意事项？

注意事项：1）连接并发：BI工具可能创建大量连接（多用户同时查询），需要设置适当的max_connections和连接池（使用PgBouncer等连接池代理）；2）资源队列：为BI用户创建专用资源队列，防止复杂分析查询消耗全部集群资源，也防止BI查询被ETL任务拖慢；3）查询超时：在BI工具中设置合理的查询超时时间，防止慢查询无限等待；4）预聚合表：高频BI查询应提前在数仓中预聚合，避免每次都扫描原始事实表；5）视图封装：为BI工具提供语义清晰的视图，隐藏复杂的维度JOIN，降低BI工具使用门槛；6）Mirror用于故障接管，不能作为供BI查询直接读取的常规只读副本；若需要隔离BI负载，应使用资源管理、预聚合或独立查询集群等方案，而不是把连接负载均衡到Mirror节点。

Q38. Greenplum支持哪些外部数据源接入方式？

主要接入方式：1）PXF（Platform Extension Framework）：支持Hadoop HDFS、S3、Azure Blob、GCS、Hive、HBase等；创建EXTERNAL TABLE后通过标准SQL查询外部数据；支持Parquet、ORC、CSV、Avro等格式；2）gpfdist外部表：读取文本文件（CSV/TSV），支持压缩文件（gzip、bz2）；适合从文件系统批量加载；3）Web外部表：通过HTTP接口获取数据，可用于读取实时API数据；4）自定义数据访问协议：通过C/Java编写自定义外部表扩展，支持任意数据源。生产中最常用：PXF（连接数据湖）和gpfdist（批量数据加载）。

Q39. 如何设计Greenplum集群的容量规划？

规划维度：1）数据量：评估原始数据大小 ÷ 压缩倍数 × 副本系数（Primary+Mirror = 2倍）× 增长预留系数，并另计索引、元数据、膨胀、workfile和重写所需临时空间；原稿“压缩通常3-8倍”和“未来1-2年”仅作为未核实的规划示例保留，压缩倍数应使用样本实测值；2）计算能力：根据数据量和查询复杂度确定Segment数量（原稿未核实经验示例：每TB数据1-2个Segment，不能替代查询负载、CPU、磁盘和并发测试），每个物理节点建议8-16个Segment（每核1个）；3）内存：每个Segment分配4-8GB内存，Node内存 = 每Segment内存 × 本节点Segment数 + OS开销；4）网络：Segment间通信需要高带宽，建议万兆（10GbE）以上；5）典型配置（中型集群）：16个物理节点，每节点16个Segment，每节点256GB内存，10TB SSD，= 256个Segment；这是原稿未核实的配置示例，“适合十TB到百TB数据规模”未给出负载、压缩与容量余量依据，不能作为采购或性能保证。

Q40. 如果让你从零开始设计一个Greenplum数仓，最重要的3个决策是什么？

第一，分布键策略设计：在建模阶段就确定所有表的分布键，而不是等建表时临时决定。将事实表与核心维度表的分布键对齐（Collocated），避免核心查询路径上的Motion。为此需要提前了解最高频的查询模式。第二，分区策略：几乎所有事实表都应该按日期分区（通常按天），分区大小控制在适中范围（单分区数据量100MB-10GB之间，太小元数据开销大，太大无法有效裁剪）。第三，存储格式选择：事实表可优先评估列存AO表，并在目标版本支持时测试zstd压缩；它常适合分析扫描，但是否最优取决于读取列数、压缩率、CPU成本与更新模式；维度表根据大小选择堆表（小表）或列存AO（中大表）；确保ETL Pipeline在每次加载后自动执行ANALYZE，保证统计信息最新。

备考建议

tip 面试准备建议

Greenplum的面试通常会深度追问以下3个方向：

分布键的选择和倾斜处理：需要能给出具体诊断命令和解决思路
EXPLAIN ANALYZE的解读：需要能从执行计划中找到性能瓶颈
数仓建模与ETL实践：需要有具体的设计案例（分区策略、维度表更新等）

如果你有Greenplum生产经验，重点准备：遇到过什么问题、如何诊断、如何解决、优化后的效果。这比背答案更有说服力。

关联知识

09-架构原理与核心特性深度解析 - 架构类题目参考
10-性能调优实战（原引用“10-性能调优实战”未能确定有效目标，暂不可跳转） - 性能调优类题目参考
11-数仓建模实践 - 建模实践类题目参考
12-生态与云化演进 - 生态与选型类题目参考