大规模并行处理的基本原理

对称多处理（SMP）架构中，多个处理器共享一个操作系统和内存总线，这必然会达到收益递减点。随着在单一服务器中增加CPU，内存访问的总线争用会增加，最终会阻塞吞吐量 (throughput)，不论计算能力如何。为了在可接受的延迟时间内处理PB级数据集，我们必须放弃共享资源，转而采用大规模并行处理（MPP）。

MPP系统采用“无共享”架构。在这种模式下，数据库被划分到多个节点上，每个节点都有独立的CPU、内存和本地连接的存储（或到远程对象存储的专用路径）。一个中心领导节点管理整个集群，但数据过滤、连接和聚合的繁重工作在工作节点上完成。

MPP的架构优点在于它能够进行水平扩展。节点数量加倍，理论上计算能力和内存容量也会加倍，前提是工作负载均匀分布。

无共享拓扑结构

在无共享集群中，系统物理上分割数据。当查询到达时，领导节点解析SQL，创建执行计划，并将该计划的片段推送给工作节点。工作节点对它们的本地数据切片执行这些片段，并仅将结果（或中间数据）返回给领导节点或其他工作节点。

这减少了原始数据在网络上的移动。通过将计算推送到数据所在地，而不是将数据拉取到计算节点，MPP系统最大限度地减少I/O开销，这通常是分析处理中的主要瓶颈。

标准无共享MPP系统架构，说明了协调与分布式执行的分离。

确定性数据分布

为了让领导节点高效地分配工作，它必须确切知道特定行存储在哪里，而无需扫描每个节点。这通过确定性分布实现，通常采用哈希算法。

当你在表上定义一个分布键（或集群键）时，系统会对该列的值应用一个哈希函数。结果决定了目标节点（或微分区）。

$H(k) \mod n = \text{节点ID}$

其中 $H$ 是哈希函数，$k$ 是分布键值，$n$ 是节点数量。

如果用户在同一个键上连接两个表，并且两个表都按该键分布，连接操作可以在每个节点上本地完成，无需网络流量。这通常称为共置连接。如果表以不同方式分布，系统必须执行“混洗”操作，在网络上重新分布行以对齐 (alignment)键，然后才能进行连接。

倾斜问题

MPP的理论线性扩展能力依赖于数据（以及随之而来的工作）均匀分布的假设。在生产环境中，数据很少是均匀的。某些值（例如 NULL 或特定的“未知”类别）可能出现频率过高。

如果节点1收到1000万行，而节点2到节点10每个只收到100万行，节点1就会成为“慢节点”。在MPP系统中，查询的速度取决于最慢的工作节点。

总执行时间 $T_{job}$ 由任何单个节点花费的最大时间确定：

$T_{job} = \max(T_{node_1}, T_{node_2}, ..., T_{node_n}) + T_{coordination}$

倾斜会产生“热点”，从而浪费了空闲节点等待慢节点完成的资源。检测倾斜需要分析表的存储情况，这是我们将在本模块后面练习的一种方法。

阿姆达尔定律与网络开销

增加节点虽然提升了原始计算能力，但也引入了通信开销。互连层，即连接节点的网络结构，带宽是有限的。随着集群规模的扩大，协调事务和混洗数据的难度增加。

这一限制由阿姆达尔定律描述，该定律指出，任务的潜在加速受限于任务中无法并行化的部分（串行部分）。在数据仓库中，串行部分包括查询解析、领导节点的最终结果聚合以及网络延迟。

理想线性扩展与实际性能之间的偏差，源于网络开销和串行处理的限制。

弹性与云原生MPP

传统的本地MPP设备（如早期的Netezza或Teradata设备）存储与计算紧密耦合。如果磁盘空间不足，就必须购买更多节点，为不需要的计算能力付费。

现代云平台（Snowflake, BigQuery, Redshift RA3）已经演化了MPP架构，通过将计算与存储分离。在这些系统中：

1. 存储被卸载到远程对象存储（S3, GCS, Azure Blob）。这一层可以无限且廉价地扩展。
2. 计算由无状态集群（虚拟仓库）组成，可以在几秒钟内启动或关闭。

这种分离引入了一个新的架构考量：数据本地性。由于计算节点不永久存储数据，它们必须通过网络从远程对象存储中获取数据。为了减轻远程获取的延迟惩罚，现代引擎大量依赖激进的本地SSD缓存和列式存储格式，我们将在下一节中查看。