TiKV 源码解析系列文章(十四)Coprocessor 概览

作者: Shirly

本文将简要介绍 TiKV Coprocessor 的基本原理,面向想要了解 TiKV 数据读取执行过程的同学,同时也面向想对该模块贡献代码的同学。阅读本文前,建议读者对 TiDB 整体架构有所了解,先阅读三篇文章了解 TiDB 技术内幕:说存储、说计算、谈调度。

什么是 Coprocessor

熟悉 TiDB 整体框架 的同学可能记得,TiDB 是无状态的,数据存储在 TiKV 层。当 TiDB 在收到一个来自客户端的查询请求时,会向 TiKV 获取具体的数据信息。那么一个读请求最朴素的处理过程如下:

TiKV 源码解析系列文章(十四)Coprocessor 概览_第1张图片

首先需要肯定的是这种方式固然能解决问题,但是性能如何呢?我们来一起分析一下:

  1. TiKV 将所有数据返回,网络开销太大。
  2. TiDB 需要计算所有数据,CPU 消耗很大,相对的,TiKV 却并没有什么计算,很闲。

看到以上问题后,聪明如你,可能很容易就想到,能不能让 TiKV 把自己负责的那部分数据做一次计算,再返回给 TiDB 呢?

有何不可呢?

TiKV 读取数据并计算的模块,我们定义为 Coprocessor,该概念灵感来自于 HBase,目前在 TiDB 中的实现类似于 HBase 中的 Coprocessor 的 Endpoint 部分,也可类比 MySQL 存储过程。

有了 Coprocessor 后,从宏观看一个读请求是如何下发到 TiKV 的呢?以下面的请求为例:

TiKV 源码解析系列文章(十四)Coprocessor 概览_第2张图片

如图,以上查询语句在 TiDB 中处理如下:

  1. TiDB 收到查询语句,对语句进行分析,计算出物理执行计划,组织称 TiKV 的 Coprocessor 请求。
  2. TiDB 将该 Coprocessor 请求根据数据的分布,分发到所有相关的 TiKV 上。
  3. TiKV 在收到该 Coprocessor 请求后,根据请求算子对数据进行过滤聚合,然后返回给 TiDB。
  4. TiDB 在收到所有数据的返回结果后,进行二次聚合,并将最终结果计算出来,返回给客户端。

主要功能及处理概览

TiKV Coprocessor 处理的读请求目前主要分类三种:

  • DAG:执行物理算子,为 SQL 计算出中间结果,从而减少 TiDB 的计算和网络开销。这个是绝大多数场景下 Coprocessor 执行的任务。
  • Analyze:分析表数据,统计、采样表数据信息,持久化后被 TiDB 的优化器采用。
  • CheckSum:对表数据进行校验,用于导入数据后一致性校验。

那么 TiKV 在收到 Coprocessor 请求后,何时区分这三种请求的呢?

TiKV 源码解析系列文章(十四)Coprocessor 概览_第3张图片

请求到了 TiKV 层,处理过程如下:

  • 由 gRPC server 接收并将请求分发给 Coprocessor Endpoint 进行处理。
  • Endpoint 在收到请求后,根据请求的优先级,将请求分发给对应的线程池。
  • 所有请求会先异步从存储层获取 snapshot,然后开始真正的处理阶段。
  • 根据请求的不同类型,构造不同的 Handler 进行数据的处理。

目前 Coprocessor 支持的三种接口中,后面两种接口相对比较简单,而 DAG 是里面最复杂也是最常用的,所以本文后续将重点介绍 DAG 类请求。

DAG Request 概览

DAG 顾名思义,是由一系列算子组成的有向无环图,算子在代码中称为 Executors。

目前 DAG 请求主要实现了两种计算模型:

  • 火山模型:每个算子按行按需吐出,3.0 之后开始弃用。
  • 向量化计算模型:每个算子批量化处理数据,3.0 之后开始推广。

在目前的 TiKV master 上,处于火山模型向向量化模型的过度阶段,因而两种计算模型同时存在。TiKV 收到请求时,会优先检测是否可走向量化模型,若部分功能在向量化模型中没有实现,则走旧的计算模型,具体处理逻辑流程如下:

TiKV 源码解析系列文章(十四)Coprocessor 概览_第4张图片

相关代码在:src/coprocessor/dag/mod.rs

因为火山模型已在被弃用中,所以下文我们只讲向量化计算模型。

算子概览

在向量化计算模型中,所有算子都实现了 BatchExecutor接口,其主要定义了一个 get_batch 的函数:

pub trait BatchExecutor: Send {
   fn next_batch(&mut self, scan_rows: usize) -> BatchExecuteResult;
}

pub struct BatchExecuteResult {
   pub physical_columns: LazyBatchColumnVec,
   pub logical_rows: Vec,
   pub is_drained: Result,
   ...
}

参数说明:

  • next_batchscan_rows 由上层控制,由于扫的数据过多会慢,因此该数字从 32 倍增到 1024。

  • 返回值 BatchExecuteResult 中,由于返回了一批空数据不代表所有数据都处理完毕了,例如可能只是全被过滤,因而使用单独字段表示所有数据处理完毕。

目前 TiKV 支持的算子主要有以下几类。

TableScan

  • 定义:根据指定主键范围扫表数据,并过滤出一部分列返回。它只会作为最底层算子出现,从底层 KV 获取数据。

  • 源码路径:components/tidb_query/src/batch/executors/table_scan_executor.rs

  • 案例:select col from t

IndexScan

  • 定义:根据指定索引返回扫索引数据,并过滤出一部分索引列返回。它只会作为最底层算子出现,从底层 KV 获取数据。

  • 源码路径:components/tidb_query/src/batch/executors/index_scan_executor.rs

  • 案例:select index from t

Selection

  • 定义:对底层算子的结果按照过滤条件进行过滤,其中这些条件由多个表达式组成。

  • 源码路径:components/tidb_query/src/batch/executors/selection_executor.rs

  • 案例:select col from t where a+b=10

TiKV 源码解析系列文章(十四)Coprocessor 概览_第5张图片

Limit

  • 定义:从底层算子吐出的数据中,限定返回若干行。

  • 源码路径:components/tidb_query/src/batch/executors/limit_executor.rs

  • 案例:select col from t limit 10

TiKV 源码解析系列文章(十四)Coprocessor 概览_第6张图片

TopN

  • 定义:按照给定表达式进行排序后,取出前若干行数据。

  • 源码路径:components/tidb_query/src/batch/executors/top_n_executor.rs

  • 案例:select col from t order by a+1 limit 10

TiKV 源码解析系列文章(十四)Coprocessor 概览_第7张图片

Aggregation

  • 定义:按照给定表达式进行分组、聚合。

  • 源码路径:components/tidb_query/src/batch/executors/*_aggr_executor.rs

  • 案例: select count(1) from t group by score + 1

混合使用各个算子

综上,各个算子之间可以按照以下方式任意组合,如下图所示:

TiKV 源码解析系列文章(十四)Coprocessor 概览_第8张图片

案例:select count(1) from t where age>10

小结

由于篇幅原因,本文只是讲了一些 Coprocessor 的概要,读者对此有个概念即可。后续我们将推出该模块相关的更多更深的源码细节分析,欢迎大家继续阅读并给出建设性的改进意见。

原文阅读:https://pingcap.com/blog-cn/tikv-source-code-reading-14/

TiKV 源码解析系列文章(十四)Coprocessor 概览_第9张图片

你可能感兴趣的:(TiKV 源码解析系列文章(十四)Coprocessor 概览)