从 2018 到 2022: 一个大数据工程师眼中的 TiDB

作者： angryart 原文来源：https://tidb.net/blog/5ab9e4ac

前言

岁月是一把杀猪刀，我把近几年对 TiDB 的回忆、思考、理解、定义写成一段真实的故事，做为国产数据库人气一哥成长的见证者，我看着他一路成长，希望 TiDB 后面的路可以越走越顺。

2018 年

初识 TIDB, 那是 2018 年 8 月份，当时基于国产数据分析产品调研的背景，我在网上东寻西找，搜查奇珍异宝，然后 TiDB 跃入眼前。2017 易观 OLAP 算法大赛，TiDB 居然获得冠军，这个比赛我有关注过，没有想到是 TiDB 拿了冠军，TiDB 是谁？它做了一些什么？ 第二名是我们耳熟能详的 Clickhouse，居然比 Clickhouse 还快，相信工程师都好奇了。回顾 2017 易观 OLAP 算法大赛题目，这是一道用户分析业务场景，漏斗分析题目，我们在购买商品的过程中，需要触发的事件包括 “启动”，“登陆”，“搜索商品”，“查看商品”，“生成订单”并在系统后台生成相关数据。业务需求如下

（1）计算 2017 年 1 月份中，依次有序触发“搜索商品”、“查看商品”、“生成订单”的用户转化情况，且时间窗口为 1 天。

（2）计算 2017 年 1 月和 2 月份中，依次有序触发“登陆”、“搜索商品”、“查看商品”、“生成订单”、“订单付款”的用户转化情况，且时间窗口为 7 天，“搜索商品”事件的 content 属性为 Apple，“浏览商品”事件的 price 属性大于 5000。

根据官方的介绍，市面上现有的解决方案在数据量较大的情况下，计算效率较低，为了更好的提升用户体验，如何更好的解决问题。官方给出 60 分合格的解决方案，1 底层存储用 HDFS，2 建立 Hive 表，并以应用标识、日期、事件名称为分区，3 查询用 presto，并自定义 UDAF，或者利用 Spark core 自定义相同逻辑。

即使基于内存的 presto 的解决方案，也是刚及格而已，我的对 TiDB 的描写，记录在 2018 年我的《XXX 报告》里面，如下

之前我们介绍的另外一个数据服务公司易尚国际，它举办了数据大赛，由PINGCAP获得了冠军， PingCap的产品叫做TIDB。准确来说TIDB不是一个数据查询引擎，它是一个数据库，性质属于 NEWSQL,它是立于谷歌spaner/F1的论文思想。TiDB 的设计目标是 100% 的 OLTP 场景和 80% 的 OLAP 场景 ,一脚踏两船，在OLTP和OLAP两个领域提供一站式的解决方案。

我对 TIDB 的第一印象是此物一心两用，主业是 OLTP，副业是 OLAP，一脚踏两船，但是我始终没有搞明白它是怎么做到一脚踏两船。当时我印象中它已经 GITHUB 开源，但是文档社区没有那么成熟，所以笔者没有展开安装测试摸底。下图是当初调研的数据库，当时没有 gauss，没有 OceanBase。

2019 年

2019 年，TiDB 的市场推广非常成功，周边的小伙伴都知道 TiDB，但是我始终不了解 TiDB 的技术细节，只知道它是大一号的 MySQL,MySQL 能做的它都能做，MySQL 不能做的它也能做。终于一天，我下定决心，在自己的虚拟机上，通过 ansible 安装了 3 个节点阵容，每个节点是 4C 和 4G，基于 tpc-h 做了基准测试，并把理论认识付诸实践，做了相关的实验验证，对 TiDB 有了宏观的了解。

我始终好奇 2017 年的 TiDB 是怎么拿下比赛的冠军？那是一场 OLAP 比赛， 当时 TiDB 还没有 Tiflash 引擎，主要分为三大块，分别是 TiDB、TiKV、PD, TiDB 本身是无状态的计算引擎，估计当时做了特别设置使热数据都活跃在 TiDB 里面，如果是冷数据再往 TiKV 查找。在数据写入硬盘的底层方面，TiDB 选用了 RocksDB，RocksDB 兼容 LevelDB 原有的 API，并且对 LevelDB 进行了一系列的优化，包括对 SSD 硬盘的优化，针对多 CPU、多核环境进行优化，增加了 LevelDB 不具务的功能，例如数据合并、多种压缩算法、按范围查询等数据存储管理的能力，RocksDB 就是 TiDB 的性能天花板。2017 年的易观大赛，当时没有 Tiiflash 的状况，TiDB 基于此等条件获得了冠军。

TiDB 后面的创新，将 OLTP 存储与 OLAP 存储解耦，OLTP 的性能天花板是 RocksDB, 而 OLTP 写数据的时候，会有一份数据写入 TiFlash，OLTP 存储与 OLAP 存储物理分离，对外却是统一的逻辑管理系统，TiDB 提供 SQL 访问访问入口，让传统的 DBA 可以像使用 MySQL 那样使用 TiDB。

2020 年

TiDB 十分注重用户的感受和产品的质量，2020 年 TiDB 做了两个事让我记忆犹新，一个是 TiUP，TiUP 是对一个 TiDB 集群的生命周期管理维护的项目。发起这个项目的原因，当时 TiDB 做了调研，即使大厂的研发工程师安装一个低配的 TiDB 集群至少也要花费三个小时，所以有了 TiUP 项目，通过 TiUP 很快就部署了一个 TiDB 环境。第二个是产品抓虫的大赛，每一个产品都有 BUG，TiDB 开诚布公，悬赏找虫，不分地界，引起国外工程师的关注，其中苏黎世理工大学的 Dr. Manuel Rigger 通过引用最新技术 NoREC 找出最多的 BUG。开源无国界，TiDB 致力于开源技术布道，同时也在寻找市场上商业机会，推出的 TiDB Cloud 也得到人们一定的认可，TiDB Cloud 立足于 TiDB 技术内核实现云计算的弹性敏捷可用性，让广大开发者更方便使用 TiDB。

2021 年

2021 年 TiDB 推出 5.0 版本，在原有 HTAP 引擎 TiFlash 的基础上引入 MPP 架构，提供与存储匹配的分布式计算引擎，进一步提升海量数据下的并行计算与分析能力。通过与 TiDB-Server 共享 SQL 前端，实现解析器（Parser）和优化器的共享，TiDB 向业务提供一体化的入口，能够自动选择单机执行或 MPP 模式，并且将事务型和分析型的负载隔离，使得双方在高并发量压力下互不干扰。这个时候我非常好奇 TiDB 模块的优化器的工作细节，现在的 5.0 版本，它要识别单读还是批量操作，还要考虑 Tiflash 的数据分布和持续的数据管理，数据是从 OLTP 还是从 OLAP 找，TiDB 承载的智能调度工作量比以前大了，它需要比以前更多与 TIKV 和 PD 协作才能高质量完成工作。

TiDB Hackathon 2021 大赛，He3 团队就选择了冷热数据分层存储，设计中将热数据存放在 TiKV 上，将查询和分析几率比较少的冷数据存放到便宜通用的云存储 S3，同时使 S3 存储引擎支持 TiDB 部分算子下推，实现 TiDB 基于 S3 冷数据的分析查询。其实这就是业界追求的智能数据集成系统应用场景，集成系统能够识别广大的数据源，包括 RDBMS、NOSQL、分布式系统、文件系统等等，能够对进行识别并进行连接，采集数据到最近的存储系统里面，这样第二次第三次直接去最近的存储系统。关键核心技术挑战是智能调度识别最近的存储系统与数据源的一致性， 同理 TiDB 在这里要识别 TiKV 和 S3 的一致性，对 TiDB 提出更高的要求。

我定义了 TiDB 模块的概念范围，TiDB 模块是一个实现分布式【包括单机计算能和批量计算】、无状态、实现 SQL、客户端输入连接会话管理的计算引擎。开源界有一个 Presto, 但是 Presto 是完全局限于内存的处理能力，但是 Presto 没有存储引擎成为不了数据库，TiDB 与 PD 和 TIKV 联合在一起成为数据库， 独立 TiDB 的模块可以嵌入集成到其它系统上，例如冷热数据分层存储，整个数据集成数据链路中，TiDB 作为智能调度处理组件，承担上下游数据的管理传输。

从 TPC-H 和 TPC-DS 认识 TiDB

小白出身农民，立志改变命运，终于开了五金的电子商务零售网站，天下还有很多像小白一样的人们，他们都想趁着互联网浪潮，趁势而下，大赚一笔，但是他们未必是五金生意，有可能是外卖，有可能是玩具，有可能是生活用品。不管销售什么，至少有供应商、用户、商品等独立基础实体， 依赖基础实体之上有商品采购入货和商品外售的记录，如果我们往细节追究，还有商品评价、商品收藏、商品营销方面的考量，这里我们忽略它。8 个表包括 suplier 表供应商信息、nation 表国家信息、region 表地区信息、customer 表用户表、part 表商品表、partsupp 表商品供应表、orders 表零售订单表、lineitem 订单明细表构成最基本元素的电子商务框架，可以视为最通用的数据库设计，基于范式设计的结构如下，一个电子商务应用网站上线了。

一个可靠稳定的电商平台不但可以承担成千上万的流量，而且安全无误的执行每个行为。举个例子，商品上线一万个商品，有十万个客户上来争相哄抢。底层背后，相同一个数据对象被多个人浏览阅读，放入购物蓝、生成订单、交易结帐后客户的钱包扣钱，而商家帐户正确流入客户资金 ，同时商品数目正确扣减。保障客户、商家、商品数目的一致性，即使服务器宕掉、网络延迟、自然灾害导致的地震海啸或者人为主观的恶意性的原因，三者依然保持一致性，不会发生客户扣钱了但是商家没有收到了，或者商家入帐了而客户那边还没有扣钱，商品数目与交易数量对不上出现超买超卖的情况。

更加不可能发生停止对外提供服务的可能性，交易窗口 24 小时对外开放，不休不眠，对于互联网来说，每一秒都是金钱。基础设施稳定可靠、服务平台稳定可靠、系统服务稳定可靠，业务工作的过程中一直被审计，不管出现什么问题都要可追溯、可跟踪。

对于业务不断递增的电商平台，传统的单机解决方案要存在 IO 瓶颈，无法应付高流量，而 NOSQL 解决方案完全否决关系范式建模，只能用文档建模或者键值健模对原生业务应用侵入大，给传统应用开发工程师加大了工作量。中间件解决方案固然解放了应用开发工程师的生产力，却给后台的 DBA 带来更多的运维工作。1. 减压问题，其中一个节点压力过大，如何保障业务正常的前提下把压力转移到其它节点上面。2. 扩容 加入新的节点，如何让新节点正好划分合适的数据。

当这个电子商务网站沉淀了大量的数据，需要做数据分析去理解用户的偏好和市场的需求。基于 8 个表的结构，我们构建了 22 个模型，这个就是 tpc-h 基准测试了。每个模型都少了多表关联，最长的有 4 个表关联或者 5 个表关联，关联后做聚合、过滤、分组、归并、排序等等。

为了深入理解用户的偏好和市场的需求，数据维度越来越多，需要加入评价、收藏、浏览、点藏维度，而且数据的不断增长，与数据计算能力呈正比，添加更多的服务器固然可以提高计算能力。但是消除冗余的范式建模不适合复杂业务分析景，例如拉链表，每天增加那么一丁点数据，业务上希望那一点变化发生在单表上，分析模型底层太大变化。

阿里的业务也是维度建模，维度建模不像关系建模那样消除数据冗余，相反它集成更多的数据冗余，提高计算能力，tpc-ds 就是采取了维度建模，tpc-ds 与 tpc-h 的的本质区别就是不同角度的应用建模，tpc-h 还能够为 OLTP 在线应用服务，而 tpc-ds 完全没有考虑范式，更加关心分析主题。tpc-ds 模型模拟一个全国连锁的大型零售商的销售系统，其中含有三种销售渠道：store（实体店）、web（网店）、catalog（电话订购），每种渠道使用两张表分别模拟销售记录和退货记录，同时包含商品信息和促销信息的相关表结构。TPCDS 采用雪花型数据模型，三种渠道的销售、退货表、及总体的存货清单作为事实表，其他商品相关信息、用户相关信息、时间信息等其他信息等都作为维度表，同时各表命名达到见名识义，详细如下表所示：

很明显，tpc-ds 的业务主题是销售渠道分析模型，根据模型业务人员很快可以进行渠道比较、渠道强弱，渠道环节对比、购买订单分析，但是不擅长财务分析模型、人力资源分析模型、装运分析模型、库存管理分析模型。7 张事实表和 17 张维度表如下，简单两表关联通过星型模型完成大部分的业务分析场景，再复杂的业务通过雪花模型也可以完成。

tpc-h 的特征如下

• 测试大规模数据，解决大数据问题

• 对实际商业问题进行解答

• 执行需求多样或复杂的查询（如临时查询，报告，迭代 OLAP，数据挖掘）

• 以高 CPU 和 IO 负载为特征，

• 通过数据库维护对 OLTP 数据库资源进行周期同步

前面说过了 TPC-DS 采用维度建模，与 TPC-H 的范式建模，所以必须要发生 ETL 过程。现实版的 TPC-DS 应用要打通多个数据源，对接多个数据库，对数据进行清洗、整理、规范，统一置放到数据仓库里面。根据业务调整数据分层分类分级，设计面向主题的数据集市，特别需要全局和发展的视角，建模应该在理解整体业务流程的基础上。

结尾

最后概括 TiDB 解决的问题 ，TiDB 是一个开源的、分布式、计算存储分离、弹性可扩展、支持行式列式、实现 HTAP 功能的数据库。首先它可以做业务应用的数据库，勿论它的 OLTP 可以去到多少并发，肯定会比 MySQL 高，事务、ACID、并发、封锁、串行化它都支持，所以解决 100% 的业务问题，当数据存储沉淀到 Tikv，同时会相同的数据沉淀到 TiFlash，TiFlash 是列存存储，TiDB 对 TiFlash 的访问操作是通过 MPP 的方式进行，但是由于关系范式建模的原因，TiDB 可能以类似 TPC-H 复杂的 SQL 做数据查询，充其量只能解决 30% 的分析问题。更复杂的数据应用系统建设，需要通过自身的生态工具把数据从 TIKV 转移到 HADOOP，另立数据仓库重新维度建模组织管理，可以解决 70% 的问题 。