构建数据工程师能力模型，实战八大企业级项目-完整分享

核心代码，注释必读

// download：3w 52xueit com

vue 2.x 响应式

Object.defineProperty

爱学it学无止境

很多企业用户由于找不到更加低成本、轻改造、易上手的解决方案，业务不得不勉强使用 TP 类型的数据库 MySQL 来承载 AP 业务。

GaiaDB 4.0 新增并行查询能力

大家最早认识云原生数据库 GaiaDB 是作为「MySQL Plus」的替代品，100% 兼容 MySQL，扩展性和性能又远超于开源 MySQL，所以 GaiaDB 在海量数据、高吞吐的场景，可以平滑替代 MySQL。

在 GaiaDB 4.0 之前，GaiaDB 像 MySQL 一样，无法很好支持复杂的分析处理需求，一条复杂的查询通常要处理几十秒甚至更长时间。

为了解决这个问题，GaiaDB  4.0 针对在线实时的分析业务发布了并行查询能力，使得业务在同一套集群上，无需任何改造即可满足复杂分析的需求。

众所周知，软件性能的提升一方面源于 CPU 硬件能力的增强，另一方面也得益于软件设计能够充分利用 CPU 的计算资源。

在 MySQL 的各个版本中，单个查询的执行通常是在一个独立的线程中完成，即对应一个 CPU 核。然而，在多核 CPU 下，仅依赖单个线程来执行查询无法充分利用硬件资源，特别是当涉及到 I/O 密集型操作或复杂查询时。

故 MySQL 在处理复杂查询时会有性能瓶颈，并且无法单纯通过提高资源配置解决这个问题。因此，简单的解决方案是充分利用 CPU 的多核计算资源，让多个核参与到计算任务中，这样才能大幅度提升查询计算的处理能力。

下图是 GaiaDB 利用多核资源并行计算一个表的 count( * ) 过程的例子：表数据进行切块后，分发给多个 CPU 核进行并行计算，每个核计算部分数据得到一个中间 count( * ) 结果，并在最后阶段将所有中间结果进行聚合得到最终结果。相比单线程处理的计算方式，GaiaDB 处理复杂查询任务的性能提升 1 到 2 个量级。

技术实现思路

GaiaDB 并行查询技术的整体实现思想是对能够并行的查询算子（scan、gather等）进行并行化，在执行查询任务时将数据分片并启动若干个工作线程分别计算，最后将结果汇总返回给客户端。同时 GaiaDB 并行执行增加数据交互算子（stream），实现多个工作线程之间的数据交互，确保查询的正确性，完成整体的查询。

如下图，通过对算子进行线程拆分，将完整数据分区下推到不同的 worker 线程上，利用多个线程进行并行计算，并将结果汇总到 leader 线程上，leader 对返回的数据进行汇总处理并返回给用户。

scan 算子并行化

在火山模型中，每个算子除了包括基础的构造函数外，都包含 Init 和  Read 函数，Init 函数做执行前的一些准备工作，Read 函数向下层算子发送命令并返回数据到上层算子。

Init 接口实现：并行扫描算子需要在扫描前将需要扫描的表提前切分成 partition，并放入 Ctx(execution context) 中。

并行扫描算子 Read接口设计：Read 接口中需要实现从 Ctx 中 dequeue 当前的 Ctx，并标记为 m_cur_ctx。根据 m_cur_ctx 中的 scan_ctx，拿到 execution context 信息，返回当前 m_cur_ctx 的第一个 record，并记录下一个 record 的位置，待下一次读取。m_cur_ctx 扫描完成后，从 m_ctxs 中取得下一个 ctx，重复读取以取完所有的数据。

ParallelTblScanIterator 与 TableScanIterator 的区别在于，并行扫描算子 ParallelTblScanIterator 将一个全表扫描任务划分成多个ctx 的子任务，便于多个线程协作，而 TableScanIterator 无法将任务拆分成多个子任务，导致无法并行执行。