这个系列更新到第七篇估计很多朋友已经从架构、部署一路看到这里了。前几篇把 MPP 的并行框架、数据分片、SQL 执行流程讲得比较细这篇换个节奏集中聊几个日常最容易卡住的话题性能怎么评价、运行中有哪些必须注意的坑、排查问题用什么工具以及自己动手编译 MPP 组件时绕不开的细节。如果你正在维护 Greenplum、Doris、StarRocks、ClickHouse 或者 Trino 这类分析型系统接下来这些内容可以直接对照着用。1. MPP 性能到底怎么衡量别只看 QPS1.1 先从并行模型理解它的快与不快MPP 的核心是 Shared-Nothing 架构每个节点独立持有自己的 CPU、内存和磁盘节点之间通过网络交换数据。这个结构的好处是扩展相对直观数据量涨了加节点整体存储和算力一起往上走。但“可以扩展”不等于“所有查询都线性提速”因为分布式执行有两个绕不开的代价数据交换和结果汇聚。举个例子两张表做 Join如果 Join Key 的分布不一致节点 A 上的一部分数据就必须通过网络搬到节点 B。这个搬运过程就叫 Shuffle。Shuffle 的大小取决于参与 Join 的数据量速度取决于网络带宽和接收端的内存/磁盘处理能力。很多 MPP 查询跑得慢不是计算算不过来而是数据在路上耗掉的时间比计算还长。理解了这一点就不会盲目地认为“MPP 集群加节点就能解决所有慢查询”。如果一个 SQL 本身需要全量 Shuffle加节点确实能分掉一部分压力但网络交换的总量可能没减少瓶颈只是从 CPU 转移到了网卡。1.2 分析型场景应该盯哪些性能指标MPP 不适合用 QPS 衡量这种引擎天生是为复杂查询准备的一次查询可能要扫描几百 GB 甚至上 TB 数据拿“每秒处理多少个小请求”去套完全对不上。我一般盯这几个指标查询耗时分布尤其是 P50、P95、P99。P50 代表日常体验P95 和 P99 能暴露出负载波动或数据倾斜。单核吞吐也就是每个 CPU 核心每秒处理多少行数据。这个指标能横向对比不同节点之间的处理能力差异。扫描带宽指从存储层读取数据的速率能反映存储格式、压缩比和磁盘 IO 之间的配合是否正常。内存峰值排序、聚合、Join 都吃内存峰值一旦接近节点上限下一步就是 OOM。还有一个更宏观的指标伸缩比。比如单节点跑一条查询耗时 100 秒4 个节点理论上如果完全线性应该跑 25 秒。但实际能到 30 秒已经算不错因为 Coordinator 节点要承担拆解任务、汇总结果的工作网络和调度也有开销。我通常这样粗算伸缩率 单节点耗时 / (N 节点耗时 × N) × 100%伸缩率能长期保持在 60% 以上说明分区和查询设计基本合格如果节点翻倍后伸缩率反而掉到 40% 以下大概率是查询里有大范围数据倾斜或者某个算子设计得过于集中。1.3 影响 MPP 性能的五个关键位置按我踩过的经验MPP 集群的慢查询通常可以归结到五个地方关键位置主要表现常见起因存储扫描磁盘 IO 居高不下扫描时间长文件格式不合理、压缩比过高、小文件太多网络 Shuffle节点间流量巨大CPU 反而闲着Join Key 分布不一致、Broadcast 小表误用算子计算单节点 CPU 打满其他节点空闲数据倾斜、表达式计算过于复杂内存排序/Join内存溢出、落盘频繁并发度过高、内存参数设置不合理结果返回查询前面很快最后卡住结果集超大、客户端逐行拉取排查时先看瓶颈落在哪个位置再对症下药。比如网络流量异常高优先检查 Join Key 的数据分布磁盘 IO 高但 CPU 使用率低优先查看有没有过度压缩或者大量随机小 IO。2. 排查 MPP 性能问题我常用的那几板斧2.1 从系统层把 CPU、IO、网络拆开看很多 MPP 的问题在 SQL 层看不到得先落到操作系统上。我习惯在问题持续期间用一组命令并行采样top vmstat 1 iostat -x 1 sar -n DEV 1 pidstat -d 1这组命令的用途是分开观察top 看 CPU 和内存整体水位vmstat 看上下文切换和等待队列iostat 看磁盘利用率sar 看网卡吞吐pidstat 看某个具体进程的 IO 情况。举一个我实际遇到过的例子节点 CPU 使用率只有 30%但查询就是跑不快。当时我以为是网络带宽满了结果一看sar -n DEV发现流量很低再查iostat才发现磁盘 await 已经飙到 80ms原来是磁盘 IO 卡住了 CPU。后续排查发现是数据文件刚好和操作系统日志目录放在同一块盘上大量日志写入抢了 IO。这种问题光看 SQL 层永远找不到原因。所以我的习惯是随便什么慢查询先花 30 秒看系统层别一上来就抓执行计划。系统层的数据能帮你快速判断“问题到底在哪个资源上”。2.2 用执行计划定位算子的真实开销系统层确认资源瓶颈后下一步就是看执行计划。MPP 的执行计划比单机数据库复杂因为每个算子都可能并行运行在多个节点上。通用的方法是跑EXPLAIN ANALYZE 你的SQL注意看几个点每个算子的 actual time 和 rows这个能看出估算和实际的偏差。Join 算子的连接方式是 Partitioned Join 还是 Broadcast Join后者如果小表很大会瞬间放大网络开销。有没有落盘操作排序或聚合一旦落到磁盘性能基本就崩了。读取数据量和实际返回数据量的比例如果扫描了几百 GB 只返回几行说明过滤条件或者分区裁剪没生效。不同的 MPP 引擎展示执行计划的方式不太一样。Doris 和 StarRocks 提供 Profile可以通过SHOW PROFILE或 Web UI 看到每个节点每个算子的耗时明细Greenplum 在EXPLAIN ANALYZE里能看到每个 Segment 的行数和时间分布ClickHouse 则有system.query_log和trace_log可以做细致分析。这些工具虽然入口不同但核心思路一致找到执行计划里“时间占比最大”和“行数分布最不均匀”的两个算子问题往往就藏在那里。2.3 监控、压测与慢查询收集工具除了临时抓取执行计划长期监控更重要。我自己维护过一套比较轻量的监控组合Prometheus Grafana 做集群级监控采集节点 CPU、内存、磁盘、网络以及 MPP 引擎暴露的查询耗时和并发指标。引擎自带的 Web UI查节点状态和执行中的查询。慢查询日志统一收集到 Elasticsearch 或直接落到一张表里方便每天做统计。压测工具方面如果是标准的 SQL 接口可以用 JMeter 做并发测试如果只想验证某个典型查询的性能我会把线上一批常见 SQL 集合成一个脚本用 shell 循环跑记录每次耗时。这个做法看似简单但比花哨的压测工具更接近真实负载。因为真实环境的数据量、数据分布、并发模型是任何压测工具都模拟不出来的。用线上实际 SQL 做回归才能暴露数据倾斜和执行计划走偏的问题。3. 经验之谈MPP 使用中必须注意的五个坑3.1 数据分布不均比节点故障更隐蔽节点故障至少会有告警数据倾斜不会。它只会让查询一点点变慢你甚至会以为“数据量涨了正常变慢”。数据倾斜的根源通常是分区键或分布键选得不好。比如一张订单表如果用“省份”做分布键那么广东、江苏这种大省的数据量可能比其他省高出一个数量级单个节点处理的数据量就会严重失衡。查询耗时不取决于总数据量而取决于“最慢的那个节点”。判断倾斜的方式很简单直接跑一条聚合 SQLSELECT region, COUNT(*) FROM orders GROUP BY region ORDER BY COUNT(*) DESC LIMIT 10;如果前几个值的数据量比后面的高出几十倍就需要考虑换分布键或者对数据做二次拆分。另外还有一个更隐蔽的倾斜Join Key 上存在大量空值或默认值比如“unknown”“0”这类公共值会导致所有数据都挤到同一个节点上。这种情况在日志分析里特别常见。3.2 小文件问题会把并行优势吃光MPP 的优势在于并行扫描但如果一个表有几十万个小文件每个文件只有几十 KB扫描调度的开销就会占据主导。一次查询要打开几万个文件光 File Open 和元数据读取就能让磁盘和 CPU 反复空转。这种问题多数源于上游任务产生文件过多特别是 Hive 或者 Spark 写入时没有做合并。正确做法是在数据导入阶段先做一轮文件合并把文件数量控制在和数据量成比例的级别。一个经验值单文件大小最好不要低于 64MB压缩后的文件也尽量别低于 8MB。如果问题已经发生可以通过重建表、INSERT 回写的方式来压缩文件数量。有些 MPP 引擎也支持内部合并操作能在后台把已存在的小文件合并成大文件但这个过程比较耗 IO建议放到业务低峰期执行。3.3 并发、队列和内存配额要一起设计MPP 集群最大的危险之一就是“并发查询一多内存直接被 OOM 打爆”。因为很多算子都是内存优先的排序、Hash Join、聚合都需要预留内存一个大型查询吃 20GB 内存很正常。如果同时跑十个这种查询再大的集群也扛不住。我见过不少团队只看 CPU 核数来定并发度完全不看内存结果一到业务高峰期就疯狂报错。合理的方式是设置两层限制查询队列限制同时运行的查询数量超出的查询进入排队状态。资源组 / 资源标签给不同业务分配 CPU 和内存配额核心业务和临时查询互相隔离。具体参数不要照抄别人要根据自己节点的内存大小和典型查询的内存用量来算。先在低峰期跑一条大查询观察EXPLAIN ANALYZE里的内存峰值再反推单节点能容纳多少个并发。3.4 压缩率不是越高越好列式存储配合压缩算法是 MPP 能快速扫大量数据的底气。但很多人会走进“压缩率越高越好”的误区。高压缩率意味着扫描时 CPU 需要做更多解压工作而磁盘 IO 的压力反而降低了。如果 CPU 已经紧张磁盘带宽还很充裕高压缩率就不划算。一般原则是数据是数值型、重复度高可以使用压缩率更猛的算法数据是字符串、长文本压缩率本来就不低再用高强度算法CPU 开销反而明显增加。我在实际调优中会把 CPU 使用率和磁盘 IO 一起看如果磁盘 IO 低、CPU 高考虑降低压缩级别如果磁盘 IO 高、CPU 还有余量才考虑提高压缩级别。3.5 版本升级不能只看官方 Release NotesMPP 引擎的版本升级比单机数据库风险更大因为涉及元数据、节点间通信协议、存储格式兼容性等多个层面。不少团队吃了“直接从旧版本跳到新版连测都不测”的亏。我建议的升级流程是先搭一套和线上相同数据量的测试环境。跑一遍核心业务 SQL对比升级前后的执行计划和耗时。重点观察元数据升级是否只读兼容。业务低峰期做滚动升级逐个节点重启避免一次性停整个集群。升级前备份元数据和配置文件保留回滚路径。这个问题属于“平时没事出事就是大事”的典型值得提前花时间准备。4. 从源码编译 MPP 的完整经验记录4.1 什么情况下值得自己编译看到编译这个标题可能有人会问直接下载官方软件包不好吗我的回答是大多数情况下官方包够用但下面这几种场景自己编译反而更省事跑在旧版操作系统上官方包依赖的 GLIBC 版本太高装不上。需要启用特定的 CPU 指令集比如 AVX2、AVX-512官方二进制为了兼容性一般不会默认开启。想修改源码加上自己的 Patch 或插件。离线内网环境需要把整个编译产物对应到内部的操作系统版本和内核版本。出于供应链安全考虑想确认二进制确实是从公开源码构建的。如果你只是做产品验证我建议先用官方包跑通别一上来就编译编译这件事很耗费时间而且容易劝退。4.2 编译环境准备重点看三样东西编译 MPP 组件常见的坑都集中在三样东西上编译器、内存、依赖库版本。首先是编译器。C 相关组件建议用 GCC 10 以上或者 Clang 12 以上太老的编译器可能不支持新代码里使用的 C17 特性。Java 相关组件要看项目要求的 JDK 版本有些项目用 JDK8有些用 JDK11乱装会导致编译期报错。其次是内存。编译大型 C 项目特别是需要编译第三方依赖的情况8GB 内存只能勉强跑16GB 会更稳妥。如果内存不够编译时容易触发系统 OOM编译器进程被直接杀掉报错信息往往只有一行 “Killed”特别坑。最后是依赖库版本。MPP 项目依赖的第三方库通常比较固定比如 Protobuf、Thrift、OpenSSL、Readline、Flex、Bison。用系统自带的版本很可能和项目要求的版本不一致导致链接时报一堆 “undefined reference” 错误。优秀的做法是先读项目的编译文档确认依赖版本再决定是用系统包还是让构建脚本自动编译。4.3 一次实际编译的完整过程记录以构建一个常见的 Apache Doris 为例StarRocks 的流程类似典型的流程是这样# 1. 克隆源码 git clone https://github.com/apache/doris.git cd doris # 2. 准备环境变量 export JAVA_HOME/usr/local/jdk-11 export PATH$JAVA_HOME/bin:$PATH # 3. 先检查机器配置 free -g nproc df -h /data # 4. 执行编译脚本 ./build.sh --be --fe --typeRelease执行编译脚本后项目会自动下载和编译第三方依赖这个过程非常耗时可能在 30 分钟到数小时之间。产出目录一般是output/里面会包含 FE 和 BE 的部署包。编译完成后不要急着部署先做两件事# 查看编译产物版本 output/be/bin/start_be.sh --version # 跑一下自带测试 ./run-tests.sh --run这里要特别提醒编译产物的目录路径不要带中文或空格有些脚本对路径处理不仔细用户目录如果带了中文名很容易莫名其妙失败。4.4 编译过程最常见的报错和处理方式我总结了一份编译报错速查表直接对照着处理就行报错关键字常见原因处理方式protoc: command not found缺少 Protobuf 编译工具安装对应版本或确保环境中存在protocundefined reference to google::protobufProtobuf 版本和项目要求不一致清理缓存重新编译依赖库版本统一Killed/internal compiler error内存不足降低并行编译数比如make -j2Unsupported class file major versionJDK 版本过高设置JAVA_HOME到项目要求的 JDKcannot find -lxxx缺少某个 dev 依赖包根据缺失的库名安装对应开发包g: fatal error: Killed signal terminated program cc1plus编译进程内存超限减少-j数或临时加 swap编译这个环节遇到报错千万别只看最后一行一定要往上翻完整日志。真实原因往往藏在更早的输出里。另外编译时把杀毒软件和系统自动更新停掉避免它突然扫描文件系统把编译缓存或临时文件锁住浪费一次全量编译时间。5. MPP 使用中的高频问题 FAQ 速查5.1 为什么同样的 SQL 跑起来一会儿快一会儿慢这种情况最常见的原因是并发和资源竞争。白天业务高峰期其他查询占了 CPU 和内存你的查询排队时间变长数据扫描速度也被拖慢。另一种可能是缓存命中率变化第一次跑要读磁盘第二次跑因为查询缓存在内存里就快很多。排查方式很简单同一个 SQL 在低峰期连续跑三次看耗时波动大不大再回到高峰期跑对比差异。如果高峰期明显变慢优先检查资源队列和并发限制看看是不是大查询把所有内存额度抢走了。5.2 如何提前识别数据倾斜避免等查询跑挂了才发现除了前面提到的GROUP BY统计法还有一个更简单的检测方式在执行计划里看每个节点的输出行数。如果某个节点输出的行数比其他节点高一个数量级基本就坐实了倾斜。预防手段更关键。建表时要认真选分布键尽量选择基数高、分布均匀的字段。复合分区也可以缓解一部分问题但最终决定权还是在分布键。如果数据本身存在天然热点比如头部用户占了 90% 的订单量那就要考虑在 SQL 层面做两阶段聚合先按热点值拆分再汇总。5.3 并发一高就 OOM到底该调参数还是扩容我的判断标准很简单先看内存都被谁吃了。跑top看进程内存再结合SHOW PROFILE或执行计划里的内存预估如果发现单查询内存占用巨大说明参数配置过宽比如一次查询允许使用的内存上限太高需要限制算子内存。如果每个查询的内存用量都在合理范围内但节点整体内存依然不够说明并发或者集群容量确实不足。这时候调参数只是帮倒忙该扩容就扩容该分流就分流。5.4 编译好的 MPP 组件怎么在离线环境部署离线环境的思路很简单在一台能联网的机器上完成编译和打包然后拷贝到内网机器。需要注意三点编译时保持操作系统版本、GLIBC 版本和线上一致否则二进制可能因为动态库版本问题跑不起来。把依赖的动态库一并收集放到程序的lib目录或者使用LD_LIBRARY_PATH指定路径。部署后先跑自带的 smoke test不要直接接生产流量。5.5 大表和小表 Join 为什么永远那么慢大表和小表 Join 有两种策略一种是把小表广播到所有节点另一种是两边都按 Join Key 重新分区。如果优化器选了广播但小表其实有几十 GB网络开销就会很大如果选了分区但 Join Key 分布倾斜个别节点又会成为瓶颈。我的建议是对于明显的小表可以强制指定 Broadcast Join对于大表之间的 Join尽量保证两张表使用相同的分区或分布键减少跨节点 Shuffle。另外Join 之前可以先做一轮过滤把无关数据提前裁掉能省不少数据交换量。6. 最后补两句实战心得从性能排查到源码编译最想分享的一句话是MPP 的问题很少有“单一原因”多数时候是多因素叠加。比如某个查询慢可能是执行计划走偏也可能是数据倾斜更可能是当时系统刚好在做备份任务抢 IO。所以不要只凭一次现象就下结论多看几组数据多对比几个时段结论才可靠。编译这一块我犯过最大的错误是在 8GB 内存的机器上直接make -j8结果编译器连续被杀浪费了大半天才反应过来是内存的问题。后来习惯先free -g看内存再决定并发数编译前还会把不必要的服务停掉。这个习惯看起来简单但真的能帮你避开大部分“编译失败其实是环境问题”的坑。这一篇把性能、注意事项、工具、编译和 FAQ 串下来正好补齐了前面几篇偏概念的内容。如果你在自己的 MPP 集群上也遇到过什么诡异问题欢迎一起交流排查思路。