第七篇了。聊到 MPP 的性能，很多人下意识都会觉得“机器多，所以快”，这个理解恰恰会在调优时把人带偏。我前几个月帮一个朋友看集群，单条 SQL 跑了一个多小时，他第一反应是引擎不行，等我翻出查询计划，发现是两张大表 join 时把数据从网络里整体搬了一轮，问题根本不是计算，而是数据搬运。这类场景在 MPP 环境里非常典型，也正好是这篇要聊的核心：性能、注意事项、工具、编译和 FAQ。适合已经搭好集群、但觉得“没想象中快”的人读，也适合正在做技术选型、想搞清楚 MPP 边界的人参考。
1. 决定MPP跑得快不快的三个底层原则
1.1 计算向数据靠拢，“并行度”不是免费的
MPP 的并行思想和单机多核并行不一样，核心是“分而治之”：数据按分布键切到多个节点上，每个节点只处理自己本地的那一份。理想情况下，一个查询下发后，所有节点同时算，汇总结果，这才是 MPP 该有的状态。但这里有一个特别容易被忽略的点：并行度并不是越高越好，它受数据分片数量、每个节点上 CPU 核数、内存大小共同约束。
我在实际项目里见过有人把大表按某个低基数字段（比如只有两个取值的状态字段）做分布键，结果数据全部倾斜到一个节点，其他节点闲着，查询比单机还慢。这就是典型的“并行度不免费”案例——并行是建立在数据均匀切分的基础上。如果分片不均匀，并行度越高，倾斜节点上的计算压力越大，整体性能反而变差。
1.2 网络是真正的稀缺资源
单机数据库里，数据在内存和磁盘之间搬；MPP 里，数据还会在网络里搬。一旦涉及 join、聚合、排序，节点之间就要交换数据，这个动作在 MPP 里叫 shuffle 或重分布。网络带宽就成了整个集群最稀缺的资源。
很多人在本地测试时觉得“挺快”，一部署到跨机房、跨机架环境就明显变慢，问题基本都是出在网络而不是计算上。我习惯用一个类比：单机查询是在自己家里找东西，MPP 查询是多个仓库同时找，但如果要找的东西分布在别的仓库，就得跑一趟物流，物流成本往往比找东西本身还高。所以性能调优的第一原则是看数据在节点之间到底搬了多少、能不能不搬。
1.3 适合MPP的查询模型与不适合的查询模型
MPP 不是万能的，它适合“大查询、批量分析、低并发”，不适合“小查询、点查、高并发短事务”。这不是性能问题，是设计模型决定的。每次查询都要经过查询计划、分发、汇聚，这个固定开销在小查询上占比非常高，甚至可能比查询本身还慢。
我一般用下面这个表帮团队判断一个场景适不适合上 MPP：
| 特征 | 适合MPP | 不适合MPP |
|---|---|---|
| 查询数据量 | 大表全量扫描、聚合 | 单行/点查 |
| 并发模式 | 少量复杂查询 | 大量短查询 |
| 用户数 | 几十到几百 | 几千到几万 |
| 响应时间要求 | 秒级到分钟级 | 毫秒级 |
| 数据更新模式 | 批量导入、追加 | 高频小事务更新 |
如果一个系统的主要场景是“用户登录查余额”，那就不该用 MPP；如果是“每天跑几十上百个复杂报表”，MPP 才能真正发挥价值。搞清楚这个边界，后面所有调优动作才有意义。
2. 性能调优的实操：分布键、join策略和资源队列
2.1 分布键选错了，数据天天在搬家
分布键是 MPP 里最影响性能的设计，但它往往在建表时就被草率决定了。很多人随便找一个字段做分布键，理由是“反正都能查”，结果跑起来之后 join、group by 全在跨节点搬数据。
选分布键时我一般按优先级考虑：
- 和常用 join 的另一张大表使用相同的分布键，让 join 变成本地 join，不产生跨节点数据交换；
- 分布键的基数要足够高，且取值尽量均匀，避免数据倾斜；
- 如果经常按某个维度做 group by，优先把这个维度作为分布键，让聚合在本地完成；
- 不要选 update 频繁的字段，分布键变更会导致数据跨节点迁移。
判断分布键选得怎么样，最直接的方法是查一下每个分片上的数据量。以某开源 MPP 引擎为例，可以查系统表看数据分布，比如按分片统计表大小，如果某个分片明显比其他分片大很多，就是倾斜。实际经验是，单个分片的数据量偏差超过 20%，就该重新考虑分布键了。
2.2 join策略：小表广播，大表重分布，到底听谁的
MPP 里 join 是性能分水岭。常见的策略有两种：小表广播（broadcast join）和大表重分布（shuffle join）。
广播是小表复制一份发给每个节点，每个节点拿小表和自己本地的大表数据做 join，适合小表和大表 join 的场景，但前提是小表要足够小。重分布是把两边表都按 join key 重新打散到所有节点，再各自做 join，适合两张大表，但代价是双份网络传输。
实际操作中，优化器会自动选，但优化器不知道你的数据倾斜情况。我遇到过广播表没有命中阈值、结果把一张“看着小”实则几百万行的表广播出去，直接把网络打满。后来我习惯在建表初期就明确 join 关系，把频繁 join 的大表按同一个键分布，这样优化器能走本地 join 路径。在某些引擎里还可以用 hint 手工指定 join 策略，但这属于最后手段，优先还是通过分布设计解决问题。
2.3 资源队列与并发度：限制是为了整体更快
MPP 集群很容易出现“一个胖子吃掉所有资源”的情况：某个分析师跑了个大查询，占满所有节点的内存和 CPU，其他人的查询全部排队。解决思路是工作负载管理，也就是给不同用户组分配独立的资源队列，每个队列限制并发数和内存上限。
我见过最典型的生产事故是有人直接跑了一个笛卡尔积 join，把集群内存打爆，所有节点进程重启。从那之后，我对资源队列的态度就是“一定要设，而且要设保守”。下面是一个简化示例，体现队列配置思路：
-- 创建队列，限制并发数为5，总内存使用上限为50% CREATE RESOURCE QUEUE query_cache WITH ( ACTIVE_STATEMENTS = 5, MEMORY_LIMIT = '50%' );这类配置虽然不同引擎语法不同，但思路一致：先给小查询和核心业务分配一个低并发、高优先级队列，再给分析类任务单独一个队列，宁可排队，不能让一个查询拖垮全集群。慢一点没关系，挂掉才是最大的慢。
3. 生产环境里反复踩过的坑
3.1 连接池参数的“两宗罪”
连接池在 MPP 场景里比单机数据库更敏感。常见问题一是 maxActive 设太大，应用一启动就建立几百个连接，把集群的协调节点压垮；二是 maxActive 设太小，业务高峰时大量请求在池子里排队，应用侧超时，运维误判为数据库变慢。
我自己的经验是，MPP 的连接数是昂贵资源，宁可让应用层排队等待连接，也不能让数据库层面同时处理过多查询。曾经某客户上线前把所有应用的连接池都调到了 100，结果集群一启动，协调节点直接连接数打满，正常查询全部失败。后来统一压到每个应用 20 左右，并把排队策略改成了应用侧等待，集群稳定多了。连接池还有一个容易被忽略的点是连接空闲超时，数据库端空闲连接回收时间和应用端连接池检测周期要匹配，否则会出现应用拿到的连接实际已失效，执行第一条 SQL 就报错。
3.2 DDL 与长查询的锁冲突
MPP 并不是所有 DDL 都能在线执行。某些引擎对大表加字段、改类型，会获取元数据锁，如果当时有长查询在跑，DDL 会一直等锁，后续新查询全部堆积，表象就是“集群没挂，但所有查询都在排队”。
我踩过一次很深的坑：白天给一张核心业务大表加字段，等了二十多分钟没完成，结果产生了锁链，一堆查询互相等待，最后只能重启协调节点恢复。现在团队定了一条规矩：结构变更一律走审批，尽量放到低峰期，并且在执行前先看一下当前活动查询里有没有长查询，如果有就先沟通暂停。对于必须在线做的变更，优先用开源在线 DDL 方案，而不是裸跑 ALTER。
3.3 导入风暴与 checkpoint 抖动
很多团队只在查询侧做负载管理，忘了导入也是消耗大户。大量并发导入任务和查询任务同时跑，很容易出现磁盘 IO 被打满、节点 checkpoint 抖动，进而拖慢所有查询。
我遇到的情况是某离线任务在每小时初启动，整点一过，大批导入同时开始，然后监控图里所有节点的 IO 和网络瞬间打满，查询延迟直线上升。解决办法是给导入任务加调度错峰，分批分阶段导入，避免所有任务在同一分钟启动。另外要注意小文件问题，导入时如果每个批次特别小，会产生大量小文件，元数据压力和查询扫描代价都会增加，尽量攒批导入。
3.4 两阶段提交：跨节点的写不是银弹
MPP 天然支持分布式事务，但两阶段提交（2PC）的代价是很大的。每笔跨节点事务都要协调多个节点，网络 round-trip 次数增加，锁持有时间变长。高并发写入场景下，2PC 会成为明显的瓶颈。
所以我在设计写入链路时有个原则：尽量把单条事务的数据落在同一个节点上，比如按分布键路由写入，减少跨节点协调。有些场景甚至可以退一步，在业务侧接受一定延迟，用批量导入替代高频单条写入。能避免的分布式事务尽量避免，这是 MPP 写入调优里成本最低、收益最高的改动。
4. 工具链：从“慢”到“定位到具体节点”的排查路径
4.1 看到这几个指标，基本就定位了
排查 MPP 性能问题，不要一上来就看 SQL，先看集群层指标。我的习惯是先看四个维度：CPU、内存、磁盘 IO、网络。不是平均指标，而是按节点看，看有没有某个节点明显和别的节点不一样，这种“单点异常”往往就是倾斜或者热点。
| 现象 | 可疑指标 | 可能原因 |
|---|---|---|
| 某个节点 CPU 打满，其他空闲 | CPU 使用率分布不均 | 数据倾斜 / 热点查询 |
| 内存持续上涨不回落 | 内存使用率 | 查询并发过高 / 内存泄漏 |
| 查询整体变慢，磁盘 IO 高 | IO util、await | 大量导入 / checkpoint |
| 跑大查询时所有节点都慢 | 网络吞吐 | shuffle 量过大 / 广播过多 |
先看节点级监控，再看查询级 profile，这个顺序能省下大量时间。如果一开始就钻进 SQL 优化里，很容易忽略掉“其实是机房网络故障”这种层面的问题。
4.2 查询Profile：把一条SQL的每个步骤摊开看
查询 profile 是 MPP 排查里最值钱的工具。它会把一条 SQL 切到每个节点、每个算子的耗时，每张表扫描了多少数据、shuffle 了多少数据，都清楚地列出来。拿到 profile，我一般先看三步：
- 各个节点耗时差异大不大，如果某个节点时间特别长，去看它处理的数据量是不是最多，判断是不是倾斜；
- 有没有大量 shuffle 行数或巨大的网络传输量，判断 join 策略是否合理；
- 扫描行数和实际结果行数相差悬殊，判断过滤条件下推是否生效。
一个典型案例：某条 SQL 扫描了十亿行，最终结果只有 1 万行，但所有数据都先在各个节点聚合成中间结果再汇总，导致计算量巨大。通过 profile 看到这一步后，我把过滤条件下推到扫描层，查询从 40 分钟降到两分钟。这就是 profile 的价值。
4.3 运维高频命令和元数据查询
除了监控面板，命令行和元数据表也是日常排查的抓手。下面是几个我常用的操作习惯：
# 看节点进程状态，确认是否有进程挂掉重启 ps -ef | grep 引擎进程名 # 看磁盘空间，分片磁盘满是最常见的隐性故障 df -h # 看实时网络流量，确认是否有大 shuffle iftop -i eth0-- 查集群节点状态和分片数 SELECT hostname, status, role FROM system.nodes; -- 查某张表各个分片的数据量，确认是否倾斜 SELECT node_name, count(*) FROM sample_table GROUP BY 节点列 ORDER BY 2 DESC;这些命令和 SQL 看似基础，但线上 80% 的问题第一眼都是从这里发现端倪的。我遇到过不少“查询突然变慢”的工单，最后追下来要么是某块磁盘写满，要么是某节点进程被 OOM 重启，元数据表里状态都能看到。
5. 从源码编译MPP组件的记录和一些建议
5.1 为什么要自己编译
多数团队用发行版都是直接下载编译好的包，但有些场景必须自己编译：一是需要打一个小补丁修 bug 或加日志；二是要跑在特殊的 CPU 指令集或者操作系统版本上；三是想通过编译参数做性能裁剪。我自己编译主要是为了调试问题，需要能在源码里加打印。
编译 MPP 系统比编译普通应用复杂不少，因为它包含查询引擎、存储引擎、网络通信、客户端等多个组件，依赖树很大。第一次编译耗时普遍较长，中途报错也很正常，关键是把环境和依赖处理好。
5.2 构建环境：内存、依赖与编译参数
编译期的常见配置我在项目文档里看到过，建议按通用实践准备：
- 内存：至少 16GB 可用内存，低于 8GB 时很多编译任务会直接 OOM；
- 磁盘：预留 40GB 以上空间，依赖和中间产物加起来很大；
- 工具链：确保 gcc、cmake、python、JDK 版本和源码要求一致，版本不匹配是最常见报错来源；
- 依赖：先确认网络能访问公共依赖仓库，编译过程中最怕拉依赖到一半失败，整个重来。
如果编译 Java 相关组件，一定要设置构建工具的内存参数，比如：
export MAVEN_OPTS="-Xms2g -Xmx4g"如果是 C++ 组件，并行度要谨慎：
make -j 4不要盲目用高并行，机器内存不够时并行编译会把内存打爆，反而失败。我吃过这个亏，后来老老实实按内存大小计算并行度。
5.3 编译报错的几个高频原因与解决
我把编译过程中反复遇到的坑整理成一张表，基本都是环境问题，不是源码问题：
| 错误现象 | 常见原因 | 解决办法 |
|---|---|---|
| 下载依赖超时或校验失败 | 网络不稳定 / 仓库被墙 | 换镜像源，或先手动下载依赖放入本地仓库 |
| 编到一半进程被杀 | 内存不足 | 降低 -j 并行度，增加内存或关闭其他大进程 |
| 头文件或符号找不到 | 系统库版本不匹配 | 按 README 检查基础依赖版本，缺什么补什么 |
| 编译完成但启动报版本错误 | JDK 版本和字节码目标版本不一致 | 切换 JDK，重新编译 |
对这些问题的态度是：不要急着重编，先看错误日志里第一个报错的位置，往往能定位到具体的依赖缺失或版本问题。盲目重编只会浪费时间。
5.4 部署前的小验证
编译完成只是一个起点，部署前我会做一轮最小验证，避免把编译产物带到生产环境才发现基础功能不对。
- 跑一遍官方自带的 smoke test 或最小功能测试；
- 启动单节点实例，执行建表、插入、查询、删除的完整链路；
- 对比编译版本和官方二进制的行为差异，确认没有因为编译参数导致功能缺失。
这一轮验证不花太多时间，但能省掉后面一大串排查。尤其是当你改了源码，更要确认改动没有引入隐藏问题。
6. FAQ：被问最多的六个问题
6.1 集群突然变慢，重启就能恢复吗
重启可以解决内存泄漏、连接状态错乱、缓存异常这类问题，但它不能解决根因。比如因为数据倾斜导致某个节点长时间满负载，重启后数据还是那样，跑起来还是会倾斜。遇到变慢，先按第 4 部分的路径查节点指标和 profile，定位到具体原因再决定要不要重启。频繁重启本身也会打断长查询，影响更大。
6.2 数据倾斜有没有自动处理的兜底
大部分 MPP 引擎有一定倾斜检测能力，但自动重分布并不是默认行为，代价也不小。兜底方案通常是对倾斜场景手工调整：重新选择分布键、把热点键加随机后缀打散、或者对小表使用广播策略。不要把希望全放在“引擎会自动优化”上，因为引擎不知道你的业务含义，只有你才知道哪个字段值会有大量重复。
6.3 加了节点反而变慢是怎么回事
很多人以为 MPP 加节点线性提速，实际不是。加节点后有两个额外代价：一是数据需要重分布，这个期间集群负载会上升；二是查询计划跨更多节点调度，通信开销增加。如果你的表本来就很小或者查询量不大，性能提升几乎为零，甚至因为调度开销变慢。所以扩容前先看节点数和平均查询规模是否匹配，小集群加节点不如先优化数据分布。
6.4 节点挂了，是否要立即全部重启
不要一看到某个节点挂了就重启所有节点。先判断是进程级故障还是机器级故障，如果是单机网络或磁盘问题，盲目重启其他正常节点反而会导致副本状态不一致。正确做法是先把节点隔离，确认数据副本完整，再从挂掉的那个节点开始拉起。整套操作在流程上要像做手术一样严谨，不要大范围重启。
6.5 小表要不要也设成分布表
如果表很小，设成复制表（每个节点都放一份完整数据）通常比分布表更好。这样任何节点上的 join 都可以直接拿本地副本做广播 join，不需要网络传输。但复制表也有代价，每次写入都要在所有节点上执行，高频更新场景成本反而高。我的经验是：单表数据量在百万行以下且基本只读，优先复制表；数据量大或有高频写入，才用分布表。
6.6 统计信息过期会有哪些“看不见”的影响
统计信息收集对 MPP 优化器非常重要。统计信息过期时，优化器可能把大表判断成小表，选择广播策略，网络被打满；或者估算错误，内存分配不足导致 OOM。最典型的表现是：同一个查询白天很快，晚上很慢，数据量没大变，但统计信息早就过期了。解决办法是建立定期 analyze 或者批量导入后主动收集统计信息。
这六年里我反复体会到一件事：MPP 调优最核心的不是参数，而是对“数据搬运”的敏感度。每次感觉集群慢，先问数据在哪个节点、搬了多少、有没有办法不搬，顺着这个思路往下走，错误基本都能定位到。编译和工具链是辅助，理解分布和网络才是真正拉开差距的地方。希望这篇把我在生产环境里踩过的坑和验证过的方案讲明白了，给正在折腾 MPP 的人节省一点时间。
