分布式执行与资源隔离

• 部分聚合（partial）与最终聚合（final）两阶段
• 聚合下推到各节点
• 可分解聚合与不可分解聚合

分布式聚合采用两阶段：第一阶段（partial aggregation）在各节点本地对本地数据做部分聚合，大幅减少上传到上游的数据量；第二阶段（final aggregation）在汇总节点（或协调器）对收到的部分结果做最终聚合。聚合下推的关键是"聚合函数可分性"：可分解的聚合（如 COUNT、SUM、AVG、MIN、MAX）可以先在本地算部分值再合并，AVG 可分解为 SUM/COUNT 组合；不可分解或需要全局信息的聚合（如 COUNT DISTINCT、取中位数、任意一个值）无法简单两阶段合并，需要保留每组的完整集合或使用特殊结构（如 HyperLogLog 做近似去重）。两阶段聚合能显著减少网络传输，是分布式聚合性能的核心。

两阶段聚合的本质是"本地先算、再汇总"，利用可分解函数把计算下推到数据所在节点，减少 Exchange 数据量。对不可分解聚合，需保留中间状态或接受近似。这决定了分布式聚合是否高效。

• Broadcast Join 的适用场景
• Shuffle Hash Join 的适用场景
• 选型依据（表大小、数据量）

分布式 Join 中，Broadcast Join 把一个较小的表广播（复制）到所有节点，每个节点用本地的小表与本地大表做 Hash Join，只产生一次网络传输（小表全量广播），适合"小表 join 大表"且小表很小（能放入单节点内存）。Shuffle Hash Join 把两个表都按 join key 哈希重分布到所有节点，使相同 key 落在同一节点，再本地做 Hash Join，适合"两个大表 join"或 join key 分布无法用广播的场景，但网络开销大。选型依据：优化器根据表大小（小表是否够小）、join 类型、数据倾斜评估，小表广播、大表 shuffle，或小表大表组合用广播避免大表重分布。

选型核心是"权衡网络传输"。广播只传小表，shuffle 传两表。小表时广播更省；大表时只能 shuffle。优化器还会考虑倾斜，对倾斜键做特殊处理。理解选型标准是优化分布式 join 的关键。

• 分布式排序的局部+全局排序
• 数据倾斜对排序的影响
• 倾斜缓解

分布式排序（Sort/Merge）通常分两阶段：先按排序列哈希/range 分区，把数据重分布到各节点，各节点本地排序；再在协调器做全局归并（merge）或按全局有序分区读取。为得到全局有序，可对排序列做 range partition（按值域分桶），保证各节点区间有序。数据倾斜时：若某节点的数据量远超其他，会成为排序瓶颈；且哈希分区下相同 key 大量聚集导致倾斜。缓解：对倾斜键做 range 分桶而非哈希、或加盐打散后再局部排序、或动态调整分区边界。分布式排序的内存超出时还会 spill 到磁盘。

分布式排序 = 分区 + 局部排序 + 全局归并。倾斜使某节点成为瓶颈，需用 range 分区或加盐打散。理解排序的分区策略与倾斜影响，是优化分布式排序与 Merge join 的基础。

• 窗口函数的分区（PARTITION BY）下推
• 排序（ORDER BY）的需求
• 跨分区数据的处理

分布式窗口函数（如 ROW_NUMBER、RANK、SUM OVER）需要按 PARTITION BY 的键把数据重分布到各节点，使同一分区内的数据落在同一节点，再在每个节点内按 ORDER BY 排序并计算窗口函数。若窗口函数的分区键与表的分布键一致，则可以避免重分布（分区下推）；否则需要按分区键做一次重分布（shuffle）。部分窗口函数（如 RANK 需要全局排名）还需在全局协调。处理的关键是"分区内数据本地化 + 节点内排序"；对跨分区或有全局语义的窗口（如累加）、需额外协调。乐观下推能减少重分布开销。

窗口函数下推 = 按分区键重分布 + 节点内排序 + 本地计算。若分区键等于分布键则零重分布。理解分区下推，才能优化分布式窗口函数的性能。

• Exchange 的网络开销来源
• 减少重分布的优化手段
• 压缩与批量传输

数据重分布（Exchange/Shuffle）的网络开销主要来自跨节点传输数据量。优化手段：一是避免不必要的重分布，如利用数据分布键（分布键与 join/分组键一致时无需 shuffle）、用广播小表替代两表 shuffle；二是减少传输量，如两阶段聚合、predicate 下推、列裁剪、部分算子本地化；三是压缩传输数据（网络压缩）与批量发送（合并小包成大块传输）；四是合理选择分区策略（哈希 vs range）。优化目标是"让数据尽量留在本地计算，减少跨节点搬运"。

Exchange 是 MPP 最贵的操作。优化方向是"少搬、搬小、搬快"：少搬（分布键对齐、广播）、搬小（压缩、裁剪、下推）、搬快（批量、流水线）。理解这些是 MPP 性能调优的核心。

• 热点 Key 导致的负载不均
• 对聚合与 Join 的影响
• 性能损失的表现

数据倾斜（热点 Key）指某个或某几个 key 的数据量远大于其他 key，导致重分布后这些 key 的全部数据集中在少数节点，这些节点负载远超其他节点，成为瓶颈。对聚合：热点组在单个节点上要处理海量数据，内存/CPU 吃紧甚至 spill；对 Join：热点 key 的 join 集中在单节点，其余节点闲置，出现"木桶效应"。危害表现：整体查询被拖慢到最慢节点，内存溢出、spill、网络不均，甚至失败。倾斜是分布式查询性能最典型的杀手。

分布式系统的性能受"最慢节点"限制。热点 key 让所有数据砸向个别节点，破坏并行负载均衡。识别热点（统计 key 分布、观察节点处理时间）并加盐/skew join 缓解，是优化分布式查询的关键。

• skew join 的识别
• 倾斜侧拆分与单独处理
• 与普通 join 的差异

skew join 是专门针对倾斜 Join 的优化：先识别出高频（倾斜）的 join key，把倾斜 key 的数据从整体 join 中拆出来单独处理。处理方式：对倾斜侧的 key 做加盐拆分（按盐值复制并分发给多个节点），对非倾斜侧匹配该 key 的数据也做对应复制（复制到每个盐值节点），使原本压在单节点上的倾斜 join 分摊到多个节点并行，再合并结果。非倾斜部分仍走普通 join。这样避免倾斜 key 把单节点打爆。skew join 的代价是倾斜侧数据被复制、增加网络与计算，需按阈值判断是否启用。

skew join 的核心是"把最大热点拆开打散"：倾斜 key 加盐复制到多节点，非倾斜侧对应复制，让 join 并行化。它是有针对性的倾斜缓解，需权衡复制开销。理解它才能解决"个别 key 打爆节点"的问题。

• Resource Queue 的资源限制
• 并发控制与排队
• 资源隔离与优先级

MPP 的资源队列（Resource Queue，如 Greenplum）用于限制不同用户/角色的资源使用与并发：可为队列设置并发查询数上限、内存/CPU 配额、优先级等。当查询数量超过队列并发上限时，新查询进入队列等待，避免过多并发耗尽资源。资源队列实现资源隔离与并发控制，防止某些查询拖垮整个集群。现代 MPP 还提供资源组（Resource Group）做更细的 CPU/内存隔离。设计上，需按业务为不同组分配配额，平衡并发与吞吐。

资源队列是"并发闸门 + 资源配额"。它控制"同时跑多少查询、每个查询能用多少资源"，防止资源被耗尽。理解资源队列与优先级，才能保障多租户下查询的公平与稳定。

• 局部 TopN 与全局 TopN
• 两阶段合并
• 减少传输量

分布式 Limit/TopN 采用两阶段：先在每个节点本地计算 TopN（局部 TopN，只需各节点保留前 N 条），再把各节点的前 N 条上传到协调器，做全局 TopN 合并，最终取前 N 条。这样在早期就丢弃大量不需要的数据，大幅减少网络传输。若还有 ORDER BY，需注意排序语义；若 Limit 无 ORDER BY，则局部取任意 N 条再全局合并即可。两阶段 TopN 是分布式查询减少传输量的经典优化。

TopN 的局部+全局合并利用"每节点只需保留前 N"的性质，把大数据量在源头削减。这体现了"聚合下推 + 减少 Exchange"思想。理解它可以在 LIMIT 场景显著优化性能。

• Union 与 Union All 的区别
• 去重（DISTINCT）的分布式执行
• 子查询的下推

Union All 只是合并各子查询结果，无需去重，可各节点直接并行执行后拼接。Union（去重）需要做全局去重：各节点先本地去重，再按去重键重分布（相同 key 到同一节点），在目标节点再次去重，保证全局唯一。子查询（Subquery）执行时，可把可下推的子查询（如过滤、投影）下推到各节点执行，减少上传数据；相关子查询（correlated）则需特殊处理。分布式去重与聚合类似，利用"重分布 + 本地去重"保证全局唯一。

Union 去重需全局唯一，靠"重分布到同 key 节点 + 本地去重"实现；Union All 无需去重天然并行。子查询下推减少 Exchange。理解去重与下推是分布式 SQL 执行的基础。

• 加盐的原理
• 倾斜 key 打散的过程
• 与正确性的关系

加盐（salt）是打散倾斜 key 的常用技巧：对于倾斜的 key，在聚合/join 前给该 key 拼接一个随机盐值（salt，如 0~N 的随机数），使原本集中在一个 key 的数据被分散到 N 个不同的"盐值 key"，从而重分布到 N 个节点并行处理。处理后，同组数据虽然被暂时打散，但通过部分聚合（各盐值组先本地聚合）再按原始 key 汇总（最终聚合）还原正确结果。对 join，倾斜 key 加盐后，非倾斜侧对应数据也要复制 N 份以匹配各盐值。加盐要求聚合函数可分解、且最终要按原 key 合并，否则需特殊处理。

加盐把"一个热点 key"变成"N 个非热点 key"，利用并行度消化热点。代价是 join 侧需复制、聚合需多阶段。它是缓解倾斜的重点手段，但必须保证最终合并正确。

• 广播与 shuffle 的开销比较
• 阈值判断依据
• 优化器决策

广播小表避免 Shuffle 的关键是判断"小表是否足够小"。广播一个表到所有节点的开销是"表大小 × 节点数"，而 shuffle 的开销是"两表数据量（按 key 重分布）"。因此当小表很小（如小于某阈值，如默认几十 MB 到几 GB，取决于配置）时，广播比 shuffle 便宜。优化器常用：若小表大小 × 节点数（或小表大小）小于大表重分布 cost，则选择 broadcast；否则用 shuffle。还会考虑小表是否小于"广播阈值"（broadcast threshold，如内存/网络预算）。阈值判断从统计数据（表大小、行数）估算，防止广播过大导致内存爆炸。

广播 vs shuffle 本质是"小表复制 vs 大表重分布"的成本比较。广播阈值是优化器的启发式，防止小表大到广播后内存溢出。理解阈值判断，才能手工干预（hint 强制广播）优化 join。

• 动态分区裁剪的原理
• 与静态裁剪的差异
• 适用场景

动态分区裁剪（Dynamic Partition Pruning）是指在查询执行过程中，根据运行时才知道的条件（如 join 的过滤结果、子查询结果）动态裁剪不需要扫描的分区。它常用于 join 场景：先处理小表，得到满足条件的 join key 集合，再据此在扫描大表时只读取包含这些 key 的分区，跳过无关分区。与静态分区裁剪（基于常量的 WHERE 条件）不同，动态裁剪依赖运行时数据，能显著减少扫描量。适用场景：大表按某列分区、join 的过滤条件由另一张表决定。实现上可能通过 broadcast 小表结果、动态重建分区过滤谓词。

动态分区裁剪把"运行时才知道的 key 集合"变成扫描时的过滤谓词，减少 IO。它把"join 下推"与"分区裁剪"结合，是星型/事实表查询的常见优化。理解它可优化大表 join 的扫描成本。

• Resource Group 的资源池划分
• CPU/内存/并发的隔离
• 多租户隔离与公平

多租户资源池（Resource Group）按 CPU、内存、并发度等维度为不同租户/用户组划分隔离的资源池，每个池有独立的配额与上限。系统通过资源池调度保证：一个租户的查询不会耗尽另一个租户的资源（隔离），各租户按配额公平竞争（公平）。Resource Group 比 Resource Queue 提供更细粒度的 CPU/内存隔离（如 cgroup 类似机制），支持权重、优先级、硬限制。场景：多业务线共享一个集群，需保障各业务资源与稳定性。设计上按租户业务重要性分配资源权重，并监控用量。

资源池隔离的核心是"配额 + 隔离 + 公平"。物理隔离保证互不干扰，权重/优先级实现按需分配。多租户共享集群时，资源池是保障稳定与公平的关键。

• 并行度的来源（节点数、分片数）
• 算子的并行实现
• 调度与资源分配

分布式执行的算子并行度由集群节点数、数据分片数、以及查询的并行参数决定。每个算子（scan、join、aggregate）在多个节点上并行运行，并行度 = 参与节点数 × 节点内并行度（并发度）。调度器负责把算子任务分配到各节点执行，并管理资源（内存、CPU）与流水线。优化器会为不同算子选择合适并行度，过高则资源浪费、过低则并行不足。调度还涉及动态调整（如 adaptive 并行度）。合理设置并行度与调度策略，才能充分利用集群资源而不过度竞争。

并行度 = 节点并行 × 节点内并行。调度决定"谁在哪个节点跑、用多少资源"。并行度与调度直接决定资源利用率和查询性能，需平衡"并行充分"与"不抢占资源"。

• 运行时统计的采集
• 自适应决策（重分布、并行度）
• 与静态优化对比

自适应重分布（adaptive）指在查询执行过程中，根据运行时采集到的统计信息（如各节点实际数据量、倾斜情况、执行速度）动态调整执行决策，如改变重分布策略、调整并行度、切换 join 方式、处理倾斜。相比静态优化（基于统计信息预先生成计划），自适应能应对"统计不准、数据偏斜、运行时变化"。实现上，执行器在 stage 完成后反馈实际数据特征，调度器据此调整后续 stage 的分布/并行。例如发现某节点数据量过大（倾斜），自动加盐或改广播。自适应提升了查询对数据变化的鲁棒性。

自适应重分布用"运行时真值"修正"静态预估误差"。它把执行变成反馈闭环，能应对倾斜与统计失真。是 MPP 引擎走向智能优化的方向。

• 执行计划可视化的内容
• 各算子耗时与数据量
• 瓶颈定位方法

分布式执行计划可视化通常展示查询的算子树（Stage/DAG），标注每个算子的耗时、处理行数、输入/输出数据量、所在节点、是否重分布等。通过可视化，可定位瓶颈：某算子耗时占比高（如重分布 shuffle）、某节点数据量/耗时远超其他（数据倾斜）、spill 到磁盘、网络传输量大等。定位方法：观察各 stage 的耗时分布、节点间负载不均、Exchange 传输量、spill 事件。常见的瓶颈包括：重分布网络、单节点热点、spill、广播过大。借助可视化工具（如 EXPLAIN、查询 profile）可针对性优化。

执行计划可视化是"性能剖析的仪表盘"。它把抽象的分布式执行变成可读的算子树与耗时分布，帮定位"卡在哪个算子、哪个节点"。是分布式查询优化的前提。

• 网络传输的压缩
• 批量发送（批处理）
• 减少网络开销

重分布网络的压缩与批量发送用于降低跨节点传输开销。压缩：在跨节点发送前对数据块做压缩（如列压缩、字典压缩），减少传输字节数，网络是瓶颈时收益显著；批量发送：把多条记录合并成大数据块（batch）一次性发送，减少发包次数与网络往返开销，提高吞吐。两者配合让重分布更高效。代价是压缩/批量需要 CPU 与缓冲内存，需权衡 CPU 与网络。实现上，MPP 引擎在 Exchange 层对传输批做压缩与批量组装。

压缩减字节、批量减发包，都是从"传输效率"角度优化重分布。网络是 MPP 瓶颈时，压缩与批量收益大。理解它们能解释为何重分布也能高效。

• 查询级资源配额
• CPU/内存的隔离与限制
• 防止单查询拖垮系统

查询级的 CPU/内存配额指对单个查询可使用的 CPU 与内存加以限制，防止个别查询耗尽资源拖垮整个系统。实现上，MPP 引擎为每个查询分配内存限额（超过则 spill 到磁盘或报错），通过资源池/队列限制 CPU 份额与并发，甚至用 cgroup 类机制做 CPU 隔离。这样即使用户提交了超大查询，也只能用其配额内的资源，不抢占其他查询。查询级配额与资源池配合，实现"细粒度隔离"：单查询有内存上限、整体有资源池上限。

查询级配额是"防失控"机制：限制单查询资源 + 隔离。它防止"一个查询吃光内存导致 OOM 或拖垮并发"。理解查询级配额与资源池，是保障多租户稳定性的关键。

• 大查询排队机制
• 优先级调度
• 防止长查询拖垮并发

防止大/长查询拖垮并发，需设计排队与优先级调度：在大查询进入执行前，先评估资源需求，若资源不足则排队等待（而非立即挤占），通过资源池/队列并发上限控制同时执行的大查询数量。优先级调度：按业务重要程度分配优先级，高优先级查询优先执行，低优先级在资源紧张时排队或降级。此外可设置查询超时、内存/CPU 上限、限制单查询并发度，防止长查询独占资源。目标是"短查询响应快、长查询不饿死、并发不被拖垮"。设计上结合并发限制 + 优先级 + 资源配额 + 超时。

核心是"让大查询排队而非插队"。通过并发上限、优先级、资源配额、超时，把资源公平分配给不同查询，防止长查询长期占用资源。这是数据库并发治理的关键。

• 客户端超时到数据库的传播
• statement_timeout 与锁等待超时
• 取消对长事务的影响

查询超时与取消的传播：客户端设置超时（如 JDBC queryTimeout）发送取消信号，DBC/驱动向数据库发送取消（cancel）请求，数据库中止对应查询执行（如 PG 的 statement_timeout 或 SELECT 的 cancel）。statement_timeout 是数据库侧语句级超时，超过即中止该语句；锁等待超时（lock_timeout）控制等待锁的最长时间，超时则放弃获取锁。两者协同：statement_timeout 限制整体执行时间，lock_timeout 单独限制锁等待，避免互相阻塞。取消的影响：对已提交事务无影响；对未提交长事务，取消（回滚）会释放其持有的锁，但如果没有回滚，取消只中止当前语句、事务仍可继续；长事务回滚可能耗时并占用大量 undo 空间。因此取消后需关注事务状态与锁释放。

超时传播是"客户端-驱动-数据库-执行器"的信号链。statement_timeout 管整体、lock_timeout 管锁等待。取消对长事务的影响取决于事务是否已提交、是否回滚，需结合事务边界设计。理解超时协同才能避免死锁与资源占用。

• 水平扩展（加节点）
• 数据再平衡的必要性
• 扩展的影响

MPP 的水平扩展指通过增加节点（segment）提升集群的存储与计算能力。由于 Share-Nothing 架构下数据按分区分布在各节点，新增节点后需要做数据再平衡（redistribution），把原有数据按新节点数重新分布，使各节点数据均衡，否则新节点无数据、旧节点负载过高。数据再平衡（如 gpexpand）是重操作，需在低峰期分批、限速执行，并监控影响。水平扩展的收益在于吞吐与存储随节点线性增长，但代价是再平衡的迁移窗口与复杂度。

水平扩展 = 加节点 + 数据再平衡。再平衡是让新节点"有活干"的必要步骤，也是扩展的主要成本。理解"扩展为什么需要再平衡"是 MPP 弹性扩缩容的核心。

• 不同 MPP 的弹性能力
• 扩缩容的粒度与速度
• 弹性与再平衡的关系

不同 MPP 数据库的弹性能力差异明显：传统 MPP（如 Greenplum、早期 ClickHouse）扩容通常需要数据再平衡，涉及数据迁移、停机或低峰期窗口，弹性较"重"；云原生 MPP（如 Snowflake、Redshift RA3、云上 ClickHouse）支持更灵活的按需扩缩，如按计算集群独立伸缩、存储与计算分离、秒级加节点，无需重分布（存储共享）。弹性差异体现在：加节点是否要再平衡、扩缩容速度、粒度（是否支持计算/存储分离）、是否影响在线。云原生 MPP 通过存算分离实现更平滑的弹性。

弹性能力差异源于架构：传统 MPP 扩缩容需重平衡，云原生 MPP 存算分离可直接加计算节点。理解差异，才能按"弹性需求"与"在线要求"选型 MPP。

• 向量化执行（SIMD）原理
• 批处理（batch）数据模型
• 性能优势

MPP 的向量化执行指一次处理一批（batch）数据（如 1024 行）而非逐行，配合 SIMD 指令（单指令多数据）对列式数据做批量运算，减少函数调用与解释开销，提升 CPU 利用率。批处理数据模型是列式存储的配合：按列连续存储，向量化算子按列批量处理。相比逐行迭代器（Volcano 模型）的虚函数开销，向量化显著降低每行成本。MPP 中向量化与列式存储结合，是 ClickHouse 等引擎极高扫描性能的来源。向量化 + 批处理带来更高的吞吐与更低的 CPU 开销。

向量化执行 = 按批处理 + SIMD 批量运算，把"逐行"变成"批计算"，配合列式存储消除虚函数开销。它是 MPP 性能的核心技术之一。理解它才能明白为何列式 MPP 扫描快。