向量化查询执行

现代数据湖架构将存储与计算分离，使每个层都能独立伸缩。这种灵活性虽然降低了成本，但也带来了延迟。为解决此问题，Trino和Apache Spark等分布式查询引擎在数据从对象存储加载后，必须以极高的效率处理数据。经过分区裁剪和文件跳过，引擎会将剩余数据加载到内存中。在此阶段，瓶颈从网络I/O转变为CPU使用率。

向量 (vector)化查询执行是一种架构方案，用来最大化CPU吞吐量 (throughput)。引擎不是一次处理一行数据，而是处理按列组织的批次值。这种方法使软件执行与现代硬件功能相匹配，特别是CPU缓存层次结构和单指令多数据（SIMD）指令。

Volcano模型与向量 (vector)化比较

为了解向量化 (quantization)的必要性，我们首先要考察传统的查询处理方法，即Volcano模型或迭代器模型。在这种标准实现中，查询计划中的每个操作符（例如筛选、投影或连接）都充当一个迭代器。引擎会重复调用一个函数（通常命名为next()），从子操作符获取单个元组（行），处理它，然后将其传递给父操作符。

尽管Volcano模型易于实现且对面向行的事务处理有效，但它给数据湖中的分析工作负载带来了很大的开销。

1. 指令开销： 对于处理十亿行的查询，引擎会为每个操作符触发至少十亿次虚拟函数调用。CPU将大量周期用于管理函数调用堆栈，而不是执行实际的数据逻辑。
2. 缓存未命中： 在基于行的布局中，不同列的数据在内存中是交错的。如果查询只需要price和tax列，CPU必须将整行加载到缓存行中，用不相关的数据（如customer_description或address）污染L1/L2缓存。

向量化执行则反其道而行之。next()调用不再返回单行，而是返回一批（或一个向量）列式数据，通常一次是1024或4096个值。处理循环会遍历这个紧凑的基本类型数组（整数、浮点数或布尔值）。

执行模型对比。Volcano模型为每个项产生开销，而向量化模型则将开销分摊到一批列值上。

使用SIMD指令

向量 (vector)化执行的主要硬件优势在于它能够使用SIMD指令。现代CPU（带有AVX2/AVX-512的x86或带有NEON的ARM）包含能够同时保存多个数据点的寄存器。

考虑一个简单的聚合查询：SELECT SUM(price) FROM sales。

在标量（非向量化 (quantization)）方法中，CPU将第一个价格加到累加器，然后是第二个，依此类推。每次加法都需要单独的指令周期。

$\text{总和} = P_1 + P_2 + P_3 + P_4$

使用SIMD，CPU将四个（或更多）32位整数加载到一个128位寄存器中。单条CPU指令并行地将这四个值加到累加器寄存器中。

$\text{总和}_{向量} = \begin{bmatrix} P_1 \\ P_2 \\ P_3 \\ P_4 \end{bmatrix} + \text{累加器}$

这种并行处理将所需的CPU周期数量减少了与向量宽度成比例的倍数。对于存储数十亿记录的数据湖，这会使扫描和聚合速度提高一个数量级。

列式格式集成

向量 (vector)化执行与Apache Parquet等列式存储格式配合使用。由于Parquet已经以物理列的形式存储数据，查询引擎可以直接将数据从磁盘读取到内存向量中，只需极少的转换。

如果数据存储为面向行的格式（如Avro或CSV），引擎将需要：

1. 读取行。
2. 解析特定字段。
3. 将数据转换为列式内存向量。

借助Parquet和向量化 (quantization)读取器，引擎可以直接进行内存映射，或将数据从文件缓冲区直接复制到执行向量。Apache Arrow等格式提供了一种标准化的内存中列式格式，允许不同系统之间交换这些向量而无需序列化开销。

代码示例：标量逻辑与向量 (vector)化逻辑

为直观展示实现差异，考虑筛选操作在代码中如何工作。我们想筛选价格大于100的数据。

标量实现 (Python类伪代码):

# 高开销：类型检查和函数调用 
# 在循环中为每个项发生。
results = []
for price in price_column:
    if price > 100:
        results.append(price)

向量化 (quantization)实现:

# 低开销：类型检查只发生一次。 
# 循环以C语言级别的速度运行，通常由编译器展开。
# 现代引擎使用SIMD同时比较'price_array'的数据块和100。
mask = price_array > 100
results = price_array[mask]

在向量化版本中，解释器开销（或查询规划器开销）仅在每批数据中发生一次，而不是每行发生一次。

内存带宽与缓存

向量 (vector)化还解决了内存墙问题，即CPU速度与内存读取速度之间的差异。通过遍历连续的内存块（一个列向量），引擎表现出良好的空间局部性。

当CPU获取向量的第一个值时，内存控制器会将包含后续值的缓存行（通常为64字节）拉入L1缓存。循环的后续迭代会使用L1缓存中已有的数据，避免了因等待主RAM数据而产生的昂贵停顿。

限制与回退

尽管向量 (vector)化是大多数现代数据湖引擎的默认设置，但某些情况会强制引擎回退到逐行处理：

1. 复杂的UDF： 如果查询涉及用不支持向量化 (quantization)的语言编写的用户定义函数（UDF）（例如，Spark中没有Arrow优化的标准Python UDF），引擎必须将向量反序列化为行才能供函数使用。
2. 面向行的操作： 本质上是基于行的操作，例如对非结构化文本进行复杂的正则表达式匹配，或对深度嵌套的JSON结构进行操作，可能无法从向量化中获得明显的好处。

工程师在使用EXPLAIN命令分析查询计划时，应寻找向量化处理的迹象。例如，在Spark SQL中，物理计划可能显示Batched: true或引用VectorizedParquetRecordReader。如果在大型表扫描中缺少这些指示，则表明存在配置问题或不支持的数据类型，从而阻止引擎全速运行。