自2019年起#xff0c;并行执行功能已被许多客户应用于多种场景之中#xff0c;其重要性日益凸显。

然而#xff0c;遗憾的是#xff0c;我们始终未能提供一份详尽的用户使用文档

这是一份姗姗来迟的关于OceanBase并行执行的系统化产品文档。

自2019年起并行执行功能已被许多客户应用于多种场景之中其重要性日益凸显。

然而遗憾的是我们始终未能提供一份详尽的用户使用文档这无疑给业务团队在运用并行执行功能时带来了诸多困扰。

今日我们决心弥补这一缺憾。

关于并行执行的内容我们将通过七篇博客系列进行详尽的解析而本文正是这一系列的第一篇。

CPU

资源的能力。

本文将深入探讨并行执行的工作机制同时阐明如何在OceanBase数据库中对其进行控制、管理与监控。

并行执行概念

查询任务分成多个子任务并允许这些子任务在多个处理器上同时运行以提高整个查询任务的执行效率。

在现代计算机系统中多核处理器、多线程和高速网络连接广泛应用这使得并行执行成为了一种可行的高效率查询技术。

并行执行能够极大降低计算密集型大查询的响应时间被广泛应用在离线数据仓库、实时报表、在线大数据分析等业务场景同时还应用在批量导数快速构建索引表等领域。

大表扫描大表连接大数据量排序聚合大表

操作如修改主键、改变列类型建索引等从已有大数据建表Create

Table

什么场景适用并行执行什么场景不适用并行执行硬件要求并行执行工作原理并行执行工作线程通过均衡负载来优化性能

1.1

并行执行用多个处理器协同并发处理同一任务在这样的系统中会有收益

多处理器系统SMPs、集群IO

如果你的系统不满足上述特征那么并行执行可能不会带来显著收益。

在一些高负载小内存或

并行执行不仅适用于离线数据仓库、实时报表、在线大数据分析等分析型系统而且在

OLTP

串行执行使用单个线程来执行数据库操作在下面这些场景下使用串行执行优于并行执行

Query

执行时间都在毫秒级。

并行查询本身有毫秒级的调度开销对于短查询来说并行执行带来的收益完全会被调度开销所抵消。

系统负载本就很高。

并行执行的设计目标就是去充分利用系统的空余资源如果系统本身已经没有空余资源那么并行执行并不能带来额外收益相反还会影响系统整体性能。

1.3

性能、网络带宽都会影响并行执行性能其中任意一项成为瓶颈都会拖累并行执行性能。

1.4

语句的并行执行生产者消费者流水线模型并行的粒度生产者和消费者之间的数据分发方式生产者和消费者之间的数据传输机制

1.4.1

主线程接收、解析SQL的线程根据计划形态预约并行执行需要的线程资源。

这些线程资源可能来自集群中的多台机器。

SQL

主线程打开并行调度算子PX

COORDINATOR。

并行调度算子解析计划将它们切分成多个操作步骤按照自底向上的顺序调度执行这些操作。

每个操作都会尽可能并行执行。

当所有操作并行执行完成后并行调度算子会接收计算结果并将结果吐给它的上层算子如

Aggregate

并行执行使用生产者-消费者模型来进行流水执行。

并行调度算子解析计划将它们切分成多个操作步骤每个操作步骤称之为一个

DFOData

---------------------------------------------------------------------------------------------------------

Query

---------------------------------------------------------------------------------------------------------

|ID|OPERATOR

-----------------------------------------------------------------

|PX

-------------------------------------

output([INTERNAL_FUNCTION(game.team,

T_FUN_SUM(T_FUN_SUM(game.score)))]),

filter(nil),

output([INTERNAL_FUNCTION(game.team,

T_FUN_SUM(T_FUN_SUM(game.score)))]),

filter(nil),

[T_FUN_SUM(T_FUN_SUM(game.score))]),

filter(nil),

agg_func([T_FUN_SUM(T_FUN_SUM(game.score))])

output([game.team],

agg_func([T_FUN_SUM(game.score)])

output([game.team],

---------------------------------------------------------------------------------------------------------

rows

数据做预聚合第二步后三个线程负责对预聚合的数据做最终聚合第三步最终聚合结果发给并行调度器由它返回给客户端。

game.team

描述的范围是一整个分区扫描任务涉及到多少个分区就会划分出多少个

partition

描述的范围是一个分区中的一段连续数据。

数据扫描场景里一般都是使用

block

在给定并行度的情况下为了确保扫描任务的均衡优化器会自动选择将数据划分成分区粒度Partition

Granule或块粒度Block

既不会太大也不会太小。

太大可能导致数据倾斜让部分线程少干活太小会导致频繁的扫描切换开销。

Scan

扫描算子会一个接一个地处理这些扫描任务处理完一个之后接着处理下一个直到所有任务处理完毕。

1.4.4

数据分发方式指的是数据从一组并行执行工作线程生产者发送给另一组消费者时使用的方法。

优化器会使用一系列的优化策略决策使用哪种数据重分布方式以达到最优的性能。

Hash

时生产者计算出数据行对应的目标表所在分区然后将行数据发给处理这个分区的消费者线程。

Pkey

场景中。

在这种场景下一个分区可以被多个线程并发更新因此需要使用

Pkey

来确保相同值的数据行被同一个线程处理不同值的数据行尽可能均分到多个线程处理。

Broadcast

时生产者将每一个数据行发送消费者端的每一个线程使得消费者端每一个线程都拥有全量的生产者端数据。

Broadcast

时生产者将每一个数据行发送消费者端的每一个节点上使得消费者端每一个节点都拥有全量的生产者端数据。

然后节点里的消费者线程协同处理这份数据。

Broadcast

场景里消费端的每个线程会从共享数据里取一部分数据行作为驱动数据去目标表里做

join

常用于排序场景各个消费者线程只需排序好发给自己的数据数据就能在全局范围内有序。

Random

时生产者将数据随机打散发给消费者线程使得每个消费者线程处理的数据数量几乎一致从而达到均衡负载的目的。

Random

之间会以生产者-消费者的模式连接起来并行执行。

为了方便在生产者和消费者之间传输数据需要创建一个传输网络。

例如生产者

进行收发。

每个工作线程可以对外建立数千个虚拟链接具有高度的可扩展性。

除此之外DTL

DTL

一个并行查询会使用两类线程1个主线程若干个并行工作线程。

其中主线程和普通的

查询使用的线程没有任何区别来自普通工作线程池并行工作线程来自专用线程池。

OceanBase

使用专用线程池模型来分配并行工作线程。

每个租户在其所属的各个节点里都有一个租户专属的并行执行线程池并行查询工作线程都通过这个线程池来分配。

并行调度算子在调度每个

0按需增长没有上限。

为了避免空闲线程数过多线程池引入自动回收机制。

对于任意线程

分钟并且线程池中剩余线程数大于

虽然线程池的大小没有上限但是通过下面两个机制能在绝大多数场景里形成事实上限

Admission

模块预约线程资源预约成功后才能投入执行。

通过这个机制能限制并发查询数量。

Admission

并发控制与排队》一节。

查询每次从线程池申请线程时单次申请的线程数量不会超过

等于租户

px_workers_per_cpu_quota如果超过则最多只分配

DFO

划分任务的时候工作任务会动态地分配到工作线程之间。

这样可以最小化工作负载不均衡问题即一些工作线程的工作量不会明显超过其它工作线程。

SQL

Partition

划分任务时可以通过让任务数是工作线程数的整数倍来优化性能。

这适用于

Partition

16以大约十六分之一的时间完成工作你也可以使用五个工作线程以五分之一的时间完成工作或使用两个线程以一半的时间完成工作。

个线程来处理

个分区。

而其他线程完成工作后它们变为空闲状态。

当每个分区的数据量差不多时这种配置会导致性能不优当每个分区的数据量有所差异时实际性能则会因情况而异。

类似地假设你使用

个分区每个分区的数据量差不多。

在这种情况下每个线程在完成其第一个分区后会处理第二个分区但只有四个线程会处理第三个分区而其他两个线程会保持空闲。

一般来说不能假设在给定数量的分区N和给定数量的工作线程P上执行并行操作所花费的时间等于

P。

这个公式没有考虑到一些线程可能需要等待其他线程完成最后的分区。

但是通过选择适当的