本期源码解读系列聚焦 TiFlash 计算层，PingCAP 资深研发工程师徐飞同学与大家分享 TiDB + TiFlash 计算层的演进 ，通过本期内容可以对 TiFlash 的计算层的设计原理以及代码实现 有一个概要了解。
资料下载：TiFlash 计算层概览 - 徐飞.pdf (1.1 MB)
B 站回放：源码解读 - TiFlash 计算层 Overview_哔哩哔哩_bilibili
全文回顾：TiFlash 源码阅读（二）计算层概览
Q&A 解答
1. 看 tiflash 必须了解 raft 协议吗？
解答： 这取决于你想了解 tiflash 的什么方面，如果只是看计算的局部实现，或者存储引擎的局部实现，那么 Raft 协议不是挡路石。TiFlash 计算层利用了 Raft 的 learner read 来保证与 TiKV 数据的强一致性、存储层中需要对接 Region 迁移、副本增删等功能。在看这些方面的时候需要对 Raft 协议有一定的了解。
——————————————————————————————
2. dag是什么意思？执行计划下推吗？
解答： DAG 就是有向无环图的意思，在 TiDB 的体系里指的 TiDB 的 plan 里面各个算子之间可以组成一个有向无环图。DAGRequest 就是指 TiDB 将执行计划下推给存储层的时候 plan 等一些执行需要的信息的一个协议层的表示。
——————————————————————————————
3. TiFlash 高并发有计划么？比如100个活跃查询同时进行
解答： TiFlash 在 6.0 中引入了 MinTSOScheduler，就是为了在高并发的时候能过控制相关资源的使用量从而能更好地支持高并发。在接下来的版本中有计划在 MinTSOScheduer 的基础上进一步加强 task 的调度以更好地支持高并发。
——————————————————————————————
4. 如果tiflash查询多资源紧，同步慢，会越来越慢吧？
解答： 之前确实出现过查询多导致写入拿不到资源，目前我们引入了计算线程与存储线程的绑核的功能，能够给存储线程预留 cpu 资源以解决这个问题。
——————————————————————————————
5. tiflash是否支持写流量大的表同步
解答： 支持写流量大的表同步。
在 TiFlash 节点支持的写入速度低于外部写入速度的时候，会触发 write stall （具体在 TiFlash-Summary => Storage Write Stall => Write Stall Duration 面板上频繁显示非零值），导致查询抖动。如果频繁出现，可以考虑扩容 TiFlash 节点来匹配外部写入流量。在具体使用的时候，如果从业务上评估 write stall 出现频率不合理的话，也欢迎通过 asktug 等渠道进行反馈。
——————————————————————————————
6. tipb是什么？做什么用的？
解答： tipb 是一个基于 protobuf 的协议，主要包含查询时的一些数据结构的定义，比如查询计划 DAGRequest，各个算子（Executor）的具体表示，schema 相关的定义等。tipb 主要用于 TiDB 与存储层之间的交互。
——————————————————————————————
7. 需要为tiflash有索引吗？
**解答：**如果这个索引是指 TiDB table 的索引的话，TiFlash 是没有的，不过 TiFlash 存储层自身有一些轻量级的索引（Rough set index）
——————————————————————————————
8. tiflash 为啥不做可抢占的线程池呢
解答： 一个很大的原因是 TiFlash 本身是基于 Clickhouse 的，而 ClickHouse 里面线程就是不可抢占的，要改成可抢占线程池的话，要求对现有架构做比较深入的改造，实际上在改进的过程中我们也曾经尝试过用 fiber 来达到类似可抢占的效果，但是出于兼容性以及用 fiber 的话，调度过程我们无法掌控这两个原因我们最终还是决定先用 DynamicThreadPool + MinTSOScheduer 来作为过度形态，在未来引入更加成熟的调度 + task 切分体系之后，预期会规避掉这个问题从而采用固定大小线程池了。
——————————————————————————————
9. 和clickhouse比，如何，大家有测试过么？
**解答：**目前没有和 Clickhouse 做过直接的对比，因为 TiFlash 实际上是作为 TiDB HTAP 的一个组成部分，面向的是 HTAP 中的实时分析部分，为了支持 HTAP 的部分不可避免地会有额外的开销，比如 TiFlash 的存储需要支持高频的单条更新等，这些都是 Clickhouse 等纯 AP 系统不需要解决的问题。另外 TiFlash 复用了 TiDB 的分片与调度能力，相对 Clickhouse 有更好的分布式支持和扩展性，但这也给 TiFlash 引入了一些架构上的 overhead，所以在纯粹的离线分析场景，TiFlash 性能预期是不如 Clickhouse的。
——————————————————————————————
10. TiFlash可以单独加索引吗？
解答： 目前不行。从 TiDB 整体的角度来看，其实 TiFlash 可以看作是 TiDB 表的一个特殊的索引，也就是说对于一个有 TiFlash 副本的表来说，可以理解这个表的所有列都有一个列存索引了，TiDB 的优化器也可以根据 query 的特点来自动选择是否使用这个索引。
然后从 TiFlash 自身来看，因为 TiFlash 是列存，列存的数据存储以及读取的原理上就和行存有本质的区别，传统意义上用于定位具体某行的“二级索引”很难在列存上实现。不过 TiFlash 的存储层本身会维护 Rough set index，即数据块上的一些统计信息，用来在对数据过滤上进行额外的加速，可以起部分索引的作用。TiFlash 的 Rough set index 不需要手动执行 SQL 命令来添加。
——————————————————————————————
第一期源码解读资料和回顾：【活动回顾 & 资料下载】TiFlash 存储引擎的设计思路
第三期源码解读资料和回顾：【全文回顾】TiFlash DeltaTree 引擎设计及实现解析（写路径）