spark 写tidb_tidb 系列三：有了sparkjdbc为什么还要tispark

概述

因为有spark的基础，所以接手了tispark，刚好有同事问我，tispark执行方式是sql，而tidb又是兼容mysql协议，为什么不直接使用spark on jdbc，而要另外创建tispark？

“tispark做了额外的优化”，这是官方的回答。但我自己都不知道做了哪些优化，怀着极大的兴趣，花费几天的时间通读了tispark的源码，受益匪浅，于此分享解惑。

理解本文需要有分布式计算和sql解析基础

导读

tispark做了什么

tispark是怎么做的

为什么tidb sql不这样优化

tispark做了什么

所有的额外优化，都是基于底层数据的特征，tidb数据库的特征和对应优化如下：

1.数据分布式存储

谓词下推：分布式处理必做优化，从底层过滤数据，减少IO，减少spark内存占用。

聚合下推：将可以分布聚合，如count，sum进行底层下推，然后tispark汇总；不可以分布聚合的，转化为可替代的分布聚合操作，如 avg->sum/count

2.tidb region为逻辑有序区间，且区间范围已知

Range数据过滤：limit，top操作，可以根据region区间范围，过滤掉不在limit范围内的region数据扫描

3.key全局有序

order by优化：基于主键的 order by，top操作，由于tikv数据天然有序，直接在map端就可以完成，不需要做shuffle

tispark是怎么做的

spark sql的执行流程可以借鉴：olapsql 解析

tispark扩展了SparkSessionExtensions，其中Parser，Analysis，Optimize模块几乎采用spark sql默认的规则，而从Optimized Logical Plan 转换为Physical Plans的Strategies则做了定制优化。具体sql理解可以参照：olapsql 解析

优化流程简单理解为：遍历Logical Plan，遇到可优化操作，则修改底层tikv client数据逻辑

为什么tidb sql不这样优化

问题其实可以等同为：为什么不直接使用spark on tidb

tidb sql是为了做OLTP，而tispark是做OLAP。说到底，其实就是OLAP与OLTP的区别，OLAP对应的数据量和时间比较大，可以把优化做的比较重和复杂，比如底层还需要与PD进行交互，CBO统计等等，这些开销和代价在OLAP场景下几乎可以忽略不计，但对于需要快速响应的OLTP请求就不适合了。

所以TiDB做了额外的tispark，希望通过两套不同的计算引擎，满足不同场景下的需求。

总结

本文主要讲解tispark与普通的spark做了哪些定制优化和如何实现这些优化的

最后基于tispark与tidb sql阐述了OLTP与OLAP两种不同计算场景的优化区别