分析型数据库的向量化执行对内存带宽更敏感，因为它在单位时间内从内存搬出成批列数据，CPU算得越快，越容易卡在数据供不上。
分析型数据库向量化执行原理是什么？它把压力从CPU转给了内存带宽
传统行式执行像一个人一次只搬一件货,每搬一件都要重新看一次提货单、确认一次路径，CPU把大量时间花在指令解析、条件分支和单行函数调用上，分析型数据库面对的是几十亿行的大表扫描，这种搬法太慢。
向量化执行改成一批一批搬,它不再一行一行处理，而是从列里取出一段连续数据，比如几百行到几千行，一次性送进CPU的SIMD寄存器，控制指令被摊薄到整批数据上，CPU的算术逻辑单元大部分时间都在干活，而不是等下一行数据进来。
但问题也在这里：CPU算得快了，内存必须跟得上。 你每处理一个批次，都要从内存里把整块列数据搬进高速缓存，如果内存带宽不够，SIMD流水线就会空转，向量化执行把压力从指令延迟转移到了数据供给速度上。
为什么向量化执行更依赖内存带宽
- 批量读取会放大单次内存请求的数据量,列数据越宽，一次要搬的字节越多。
- 压缩数据在解压时也会占用内存带宽,解压后的临时数据需要再次写入缓存。
- CPU每完成一个批次,下一个批次的数据如果还在内存里没到缓存，流水线只能停顿。
- 列式存储把同一列的值连续存放,虽然有利于扫描，但也意味着查询要同时访问多个列时，内存控制器要处理多个连续数据流。
业内专家指出,多数分析工作负载在向量化执行后的瓶颈会从计算侧转向存储与内存带宽侧，这也是为什么有些查询在CPU利用率还没打满时，吞吐就已经上不去了。
向量化执行和行式执行性能对比：带宽敏感度不在一个量级
拿一个具体场景说：分析一
张几十亿行的订单表，计算近一年每个区域的销售额，行式执行会逐行读取订单记录，把区域、金额、时间等字段一条条解析出来，再判断是否在近一年内，向量化执行则按列批量扫描，先读时间列，筛选出符合条件的位置，再按位置去取区域和金额列的数据。
看上去向量化执行要多读几遍列,但每次读的都是连续数据块，CPU能批量处理，问题是单位时间内从内存拉出的有效数据量大了很多。
| 执行方式 | 内存带宽敏感度 | CPU利用率特征 | 典型场景 |
|---|---|---|---|
| 行式执行 | 较低 | 经常等指令，利用率不高 | 点查、小范围更新 |
| 向量化执行 | 较高 | 高但会因数据未到而停顿 | 大表扫描、聚合、连接 |
行业共识认为,列式存储加向量化执行已成为分析型数据库提升扫描性能的标准路径，不过这条路走得越快，对内存带宽的要求就越苛刻。
大数据实时分析场景下内存带宽瓶颈怎么解决？三条实操路径
实时分析场景里的查询往往有时间限制,不能像离线批处理那样慢慢跑，向量化执行让计算变快，但内存带宽一旦成为短板，实时性就无从谈起，下面三条路径可以直接落地。
减少无效数据搬运
最有效的办法是让SQL只读必要的数据。
- 列式存储下避免
select，只投影需要的列，每少读一列，内存带宽压力就小一截。 - 谓词下推要到位,查询条件尽量命中分区键或排序键，让存储引擎在扫描前就跳过无关数据块。
- 聚合查询尽量在数据库内部完成,不要把几亿行明细拉出来到应用层再算。
这些操作不改变硬件,只改变数据流，但往往能省下相当一部分内存带宽。
调整NUMA和内存通道使用方式
多路服务器上,CPU访问本地内存快，访问远端内存慢，如果分析进程跨NUMA节点读数据，内存带宽会被远端访问消耗掉很多。
先查看内存拓扑：
numactl --hardware确认每个NUMA节点有多少内存通道,如果进程跑在节点0，但数据分配在节点1，就要手动绑定：
numactl --cpunodebind=0 --membind=0 ./your_analytics_engine如果内存分配比较平均,但进程只用一个节点，也可以用交错分配：
numactl --interleave=all ./your_analytics_engine再用numastat观察foreign memory比例，如果远端内存访问较多，说明绑定没生效，需要重新调整。
选择高带宽内存规格，不要只看价格
同样CPU核数下,云上分析型数据库实例的内存带宽可能差异明显，北京分析型数据库部署时，尤其需要核对实例规格表里的“内存带宽”或“内存通道数”指标，DDR5相比DDR4带宽提升明显，如果两种规格价格接近，优先选DDR5，如果业务以大规模扫描为主，内存带宽可能比CPU主频更重要。
分析型数据库内存带宽测试方法：先量化再优化
不知道瓶颈在哪,优化就是盲调，下面几个方法可以判断查询是不是卡在内存带宽上。
- 用STREAM基准测内存有效带宽,它能跑出复制、缩放、加法等几种操作的带宽值，是行业常用的参考工具。
- 用Intel MLC测内存延迟和峰值带宽，如果实际带宽长期接近峰值，说明内存控制器已经很忙。
- 用
perf stat -e cycles,instructions,cache-misses,LLC-load-misses观察缓存未命中，LLC未命中频繁说明数据经常要回内存取。 - 用
numastat看本地内存和远端内存比例，远端内存占比高会直接拖慢向量化执行的批次加载。
如果查询吞吐上不去,同时CPU利用率不低，但LLC-load-misses较高，基本可以判断是内存带宽在拖后腿。
从硬件到SQL：降低向量化执行内存带宽压力的落地清单
整理成一份可执行清单,方便按项排查。
- 存储层：优先使用列式存储，开启字典编码和RLE压缩，压缩能减小数据体积，但也要避免解压开销过大。
- 执行层：确认向量化引擎已打开，避免查询计划里出现意外行式回退。
- SQL层：下推聚合和过滤，避免大结果集返回，排序键和分区键的设计要贴合高频查询条件。
- 硬件层：核对内存通道数量，关闭NUMA跨节点访问，考虑开启大页内存，减少TLB miss对内存转换带宽的额外占用。
- 监控层：定期用
numastat和perf stat做基线，版本升级或数据量变化后都要重新评估。
分析型数据库的向量化执行让CPU不再是主要瓶颈,但它把压力推给了内存带宽，选型、SQL优化、硬件配置都要围绕一个目标：让每字节数据少走冤枉路，内存带宽不是越快越好，而是要让有效数据流始终跟得上CPU的批次节奏。
分析型数据库向量化执行对内存带宽更敏感吗？
是的,向量化执行按列批次处理，CPU计算效率提高后，数据供给速度成为主要瓶颈，内存带宽不足时，CPU会空转等待数据。
向量化执行内存带宽不够会有什么表现？
查询吞吐上不去,CPU利用率不低但经常等待内存，大表扫描时延迟抖动明显，perf stat里缓存未命中偏高，numastat可能显示远端内存访问较多。
大数据实时分析场景下测试内存带宽用哪些命令？
用numactl --hardware查看内存拓扑，用numactl --interleave=all或--cpunodebind绑定NUMA节点，用perf stat -e cache-misses,LLC-load-misses观察缓存未命中，再用STREAM基准测有效带宽，带宽瓶颈通常表现为缓存未命中频繁，而CPU指令执行效率并没有明显下降。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/637795.html
