作者: Shirly
本文将简要介绍 TiKV Coprocessor 的基本原理,面向想要了解 TiKV 数据读取执行过程的同学,同时也面向想对该模块贡献代码的同学。阅读本文前,建议读者对 TiDB 整体架构有所了解,先阅读三篇文章了解 TiDB 技术内幕:说存储、说计算、谈调度。
什么是 Coprocessor
熟悉 TiDB 整体框架 的同学可能记得,TiDB 是无状态的,数据存储在 TiKV 层。当 TiDB 在收到一个来自客户端的查询请求时,会向 TiKV 获取具体的数据信息。那么一个读请求最朴素的处理过程如下:
首先需要肯定的是这种方式固然能解决问题,但是性能如何呢?我们来一起分析一下:
- TiKV 将所有数据返回,网络开销太大。
- TiDB 需要计算所有数据,CPU 消耗很大,相对的,TiKV 却并没有什么计算,很闲。
看到以上问题后,聪明如你,可能很容易就想到,能不能让 TiKV 把自己负责的那部分数据做一次计算,再返回给 TiDB 呢?
有何不可呢?
TiKV 读取数据并计算的模块,我们定义为 Coprocessor,该概念灵感来自于 HBase,目前在 TiDB 中的实现类似于 HBase 中的 Coprocessor 的 Endpoint 部分,也可类比 MySQL 存储过程。
有了 Coprocessor 后,从宏观看一个读请求是如何下发到 TiKV 的呢?以下面的请求为例:
如图,以上查询语句在 TiDB 中处理如下:
- TiDB 收到查询语句,对语句进行分析,计算出物理执行计划,组织称 TiKV 的 Coprocessor 请求。
- TiDB 将该 Coprocessor 请求根据数据的分布,分发到所有相关的 TiKV 上。
- TiKV 在收到该 Coprocessor 请求后,根据请求算子对数据进行过滤聚合,然后返回给 TiDB。
- TiDB 在收到所有数据的返回结果后,进行二次聚合,并将最终结果计算出来,返回给客户端。
主要功能及处理概览
TiKV Coprocessor 处理的读请求目前主要分类三种:
- DAG:执行物理算子,为 SQL 计算出中间结果,从而减少 TiDB 的计算和网络开销。这个是绝大多数场景下 Coprocessor 执行的任务。
- Analyze:分析表数据,统计、采样表数据信息,持久化后被 TiDB 的优化器采用。
- CheckSum:对表数据进行校验,用于导入数据后一致性校验。
那么 TiKV 在收到 Coprocessor 请求后,何时区分这三种请求的呢?
请求到了 TiKV 层,处理过程如下:
- 由 gRPC server 接收并将请求分发给 Coprocessor Endpoint 进行处理。
- Endpoint 在收到请求后,根据请求的优先级,将请求分发给对应的线程池。
- 所有请求会先异步从存储层获取 snapshot,然后开始真正的处理阶段。
- 根据请求的不同类型,构造不同的 Handler 进行数据的处理。
目前 Coprocessor 支持的三种接口中,后面两种接口相对比较简单,而 DAG 是里面最复杂也是最常用的,所以本文后续将重点介绍 DAG 类请求。
DAG Request 概览
DAG 顾名思义,是由一系列算子组成的有向无环图,算子在代码中称为 Executors。
目前 DAG 请求主要实现了两种计算模型:
- 火山模型:每个算子按行按需吐出,3.0 之后开始弃用。
- 向量化计算模型:每个算子批量化处理数据,3.0 之后开始推广。
在目前的 TiKV master 上,处于火山模型向向量化模型的过度阶段,因而两种计算模型同时存在。TiKV 收到请求时,会优先检测是否可走向量化模型,若部分功能在向量化模型中没有实现,则走旧的计算模型,具体处理逻辑流程如下:
相关代码在: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<usize>,
pub is_drained: Result<bool, Error>,
...
}
参数说明:
next_batch
中scan_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
Limit
定义:从底层算子吐出的数据中,限定返回若干行。
源码路径:
components/tidb_query/src/batch/executors/limit_executor.rs
案例:
select col from t limit 10
TopN
定义:按照给定表达式进行排序后,取出前若干行数据。
源码路径:
components/tidb_query/src/batch/executors/top_n_executor.rs
案例:
select col from t order by a+1 limit 10
Aggregation
定义:按照给定表达式进行分组、聚合。
源码路径:
components/tidb_query/src/batch/executors/*_aggr_executor.rs
案例:
select count(1) from t group by score + 1
混合使用各个算子
综上,各个算子之间可以按照以下方式任意组合,如下图所示:
案例:select count(1) from t where age>10
小结
由于篇幅原因,本文只是讲了一些 Coprocessor 的概要,读者对此有个概念即可。后续我们将推出该模块相关的更多更深的源码细节分析,欢迎大家继续阅读并给出建设性的改进意见。
原文阅读:https://pingcap.com/blog-cn/tikv-source-code-reading-14/