分析查询的并行度设置必须基于集群可用核数动态调整，最佳实践是让单查询并行度不超过总核数的1/3到1/2，同时预留资源给并发任务。 这不是拍脑袋的调参游戏，而是CPU资源分配的艺术，并行度设高了，查询之间互相抢核；设低了，满集群的核在旁边看热闹，今天咱们就掰开揉碎聊聊，怎么让并行度跟集群核数对上号。
分析查询并行度怎么设置？先摸清集群的家底
很多同学一上来就改参数,结果越调越慢，查并行度之前，先回答三个问题：集群总共多少核？可用核数是多少？实际跑查询时能占满多少核？这三个数字对不上，后面全白搭。
数核数别只看总规格
云主机标着64核,那是物理核加超线程的总逻辑核，分析查询吃的是物理核数，超线程对并行计算帮助有限，甚至可能因为争抢L3缓存拖慢速度，行业共识认为，应当用lscpu查看Core(s) per socket乘以socket(s)，得到的物理核总数才是基准。
lscpu | grep -E "Socket|Core|Thread"
如果有多个节点,把每台机器的物理核加起来，但注意，不是所有核都能给查询用系统进程、数据摄入、后台压缩、GC线程都要占资源，业内专家指出，留给分析查询的可用核数通常是物理核总数的60%-80%，具体看集群负载类型。
区分核数与并行度上限
并行度不是越大越好,它决定一个查询能同时跑多少个任务，每个任务占一个线程，假设集群有32个物理核，你把并行度设到64，操作系统会强行时间片轮转，上下文切换开销直接让查询变慢，反过来，并行度设为8，等于让24个核围观两个任务干活。
一条实用经验：单查询并行度上限 = 物理核数 / 并发查询数期望值。 比如你预期同时跑5个查询，物理核32，那么单个查询并行度控制在6-8之间比较稳妥。
并行度与核数不匹配会怎样？真实表现别忽视
调错了不会马上报错,但症状很明显，观察几个典型场景，能帮你快速定位是不是并行度的问题。
CPU使用率像过山车
并行度设太高,查询启动瞬间所有核被打满，接着大量任务排队等待，CPU又突然跌到个位数，监控图上呈现锯齿状抖动，这是因为任务拆分过多，调度器忙不过来，每个任务真正执行的时间很短，大部分时间耗在锁竞争和线程切换上。
查询时间随并发数指数增长
并行度设为核数的2倍,单个查询也许还能跑，但一旦并发从2涨到5，查询时间不是翻倍，而是变成原来的4倍以上，原因很简单：所有查询都在抢同一批核，每个线程都在等别的线程让出CPU。
内存和IO的连带崩溃
并行度太高还会产生大量中间结果分片,把内存缓冲区塞满，触发磁盘溢写，这时候CPU没满，但磁盘IO先炸了，很多老哥只盯着CPU，忘了并行度同时影响内存分配，每个并行任务都要消耗一定内存，核数有限时，任务越多单任务分到的内存越少。
并行度设置多少合适？按查询类型分层决定
没有统一数字,但可以按查询特征给出一套匹配策略。
大聚合查询：并行度往低调
跑那种扫全表、做group by的ETL任务，单个任务本身就要处理大量数据，此时并行度设为物理核数的一半比较合适，比如16核机器，并行度设8，因为聚合操作需要shuffle，任务之间要交换数据，并行度太高会让网络和内存先扛不住。
轻量交互查询：并行度往高调
点查、小范围过滤、返回几十行的查询，单任务很快结束，并行度可以设到物理核数的2倍，甚至更高，这类查询不产生大量中间数据，主要消耗CPU轮询成本，但注意，如果多个用户同时打这种点查，高并行度会挤压大任务配额，所以需要区分负载。
混合工作负载：设置队列配额
集群里既有大查询又有小查询,光调并行度不够，更靠谱的做法是通过资源队列分开管理：
- 大查询队列：并行度设为总核数的1/4，限制同时运行数量
- 小查询队列：并行度设为总核数的1/2，允许更多并发
用YARN或者K8s的ResourceQuota都能实现,这里有个原则并行度上限永远参照同一时间可能运行的最大查询数来动态折算。
匹配核数调并行度的实操路径
别急着改配置文件,按下面四步走，每一步都能验证。
第一步：压测单查询的线性扩展性
在业务低峰期,用一个中等复杂度查询做实验，从并行度=1开始，逐步翻倍：1、2、4、8、16，记录每个档位的查询耗时，你会发现耗时先快速下降，然后趋于平坦，最后反而上升，那个拐点对应的并行度，就是这台机器的甜点值。
并行度: 1 耗时: 120s
并行度: 2 耗时: 65s
并行度: 4 耗时: 35s
并行度: 8 耗时: 20s
并行度: 16 耗时: 18s
并行度: 32 耗时: 21s上表模拟了16核集群的典型表现,拐点在8，即使有32逻辑核，16之后性能不再提升，32反而倒退，以后就把这个查询的并行度锁在8。
第二步：观察实际资源占用
跑压测的时候,用htop或者vmstat盯实时CPU，重点看两个指标：
- 用户态CPU占比：越高越好，说明计算在干正事
- 上下文切换次数：通过
vmstat 1的cs列观察，如果超过50万次/秒，说明并行度确实太高了
如果cs列数值很大，但CPU的有效利用率不到60%，果断降并行度。
第三步：并发场景下再校准
单查询压测结果只能做参考,线上往往同时跑好几个查询，把两个同样的查询并发执行，观察总耗时，如果两个查询并行度都是8，总耗时接近于原来单个查询耗时的2倍，说明资源分配合理，如果超过了2.5倍，说明并行度设置偏高，把两个查询都降到6再试。
第四步：设定动态上限
使用支持动态并发控制的引擎（如Spark的dynamicAllocation、Presto的resource-groups），设置maxRunningQueries和每个查询的maxConcurrent，这里推荐一个简单公式：
单查询最大并行度 = 集群可用物理核数 / 预期最大并发查询数
把预期并发数设在高峰期平均值的1.5倍，留出安全余量。
常见问题：并行度设置和核数匹配的细节坑
并行度等于核数就一定合适吗？
不一定,如果其他资源有瓶颈，比如单表扫描依赖SATA盘IO，即使CPU核数很多，并行度也得跟着IO带宽走，可以先用iostat确认磁盘是否饱和，如果%util
持续接近100%，并行度再翻倍也没用，反而增加IO队列等待。
超线程逻辑核对并行度有影响吗？
影响不大,但别指望超线程带来双倍性能，对于分析查询这种带矢量化计算的负载，逻辑核提供的额外算力通常只有物理核的15%-25%，建议并行度上限设为物理核数，不要为了凑逻辑核数强上。
虚拟化环境怎么算核数？
云主机如果标称8核,实际可能只分到2个物理核（取决于宿主机超卖比例），不用纠结，直接用压测拐点法找真实性能上限，你可以在容器里跑一次stress -c 8，看time测出的CPU时间与实时时间比值，如果比值远小于8，说明没拿到对应核数。
相关问答：并行度匹配核数的几个高频问题
问：我刚接手一个16核集群，跑SQL一直卡，并行度调多少合适？
答：先用lscpu确认物理核数，腾出20%给系统线程，如果只有你一个人跑大查询，并行度先设6-8，然后跑一次压测看拐点，如果查询包含多个join，每层join都会产生并行子任务，实际并行度会翻倍，所以初始化参数建议低一点，从4开始试。
问：并行度设了32但CPU只用了50%，是不是核数不够？
答：先看查询有没有落到单分区，并行度是上限，实际生效的任务数取决于分区数，如果数据按某个字段分桶，但查询没有对分桶键过滤，可能会全表扫描，但并行任务只拆到分区级别，检查查询计划里的Fragment数量，以及每个Fragment对应的任务数，如果任务数远小于并行度，要么改SQL增加并行度触发的条件，要么在引擎配置里关闭dynamic partition pruning的某些限制。
问：同一个查询在20核和40核集群上，并行度需要按比例调吗？
答：不建议直接翻倍，20核集群上并行度8最优，换到40核，并行度可能只需要12而不是16，原因是数据量不变的情况下，单任务处理的数据量缩小后，任务调度的固定开销占比会上升，正确做法是让单任务处理的数据量保持在一个合理范围（比如每个任务扫200MB左右），然后根据这个值反推并行度，数据量小的话，核再多也白搭。