关于数据库:使用-TiDB-构建实时应用

作者介绍：雷宇，TiFlash 研发工程师，毕业于中山大学软件工程业余。目前次要在 PingCAP 从事 TiDB SQL MPP 的相干研发工作。

本文由 PingCAP 研发工程师雷宇分享，次要从宏观角度剖析 TiDB 到底能做什么，发明什么样的价值，以及研发过程中的一些设计立足点。 文章将从四个局部分享：

首先，数据管理技术的演进；
其次，TiDB 能做什么？
第三，大家是怎么用 TiDB 的？
第四，TiDB HTAP 的将来。

首先，简略的回顾一下数据管理技术的演进。

上个世纪 70 年代，IBM 研发了世界上第一个关系型数据库 System R，是第一个应用 SQL 作为查询语言的数据库，也为起初的关系型数据库的设计奠定了根底。
到了 80 和 90 年代，关系型数据库开始横蛮成长，涌现出一大批商业关系型数据库，比方以后出名的 Oracle、IBM 的 DB2、微软的 SQL Server，以及当初比拟风行的开源关系型数据库 PostgreSQL、MySQL 等。这个期间，技术上的重点次要是数据库的功能完善，比方存储过程、触发器、各种各样的索引，以满足不同的业务需要。
2000 年代初期，全世界都进入了互联网时代，数据开始出现指数型增长，传统的关系型数据库无奈包容如此宏大的数据。此时，一些互联网公司开始牵头，将外部解决海量数据的计划进行开源。2004 年左右，由谷歌牵头发表了三篇论文，别离是他们的 分布式文件系统 GFS、分布式计算零碎 MapReduce、分布式存储系统 BigTable。在这三篇论文的领导下，Hadoop 生态社区凋敝倒退。同时，分布式 KV 数据库 Cassandra、MongoDB 等也在这个期间呈现；传统的关系型数据库也在倒退，呈现了一些十分要害的技术，比方 MySQL 的 InnoDB 引擎、Oracle RAC 剖析引擎。繁多的数据库产品已无奈满足用户的需要，整个数据处理畛域的技术方向呈现了重大的分化。OLTP 畛域仍然被传统关系型数据库霸占，OLAP 畛域则成为了起初的大数据技术主战场。
Pre – 2010s，得益于硬件的倒退，内存的容量和网络的带宽与提早有了极大晋升，数据库架构迎来改革。内存数据库和分布式数据库大规模投入生产。代表产品：Google Spanner、SAP HANA、SQL Server Hekaton、Amazon Aurora。这个期间 OLTP 的概念和 OLAP 的概念逐步开始含糊，并有人提出了 HTAP，将 OLTP 和 OLAP 混合在一起，在同一个数据库上同时解决这两种负载，回到了数据库产品的初衷。
Post – 2010s，连续了 2010 年代初期的辉煌，各种 NewSQL 数据库呈现，能够承载更加简单的负载。代表产品：CockroachDB、TiDB、VoltDB、Azure Cosmos DB，各种技术开始走向不同的方向。

整体来看，从 2000 年开始，大数据的技术就迈入了互联网生态，应用大数据技术来建设数据仓库已较为广泛。只管数据仓库的理念在 90 年代就曾经呈现了，但各个数据仓库的产品都尚未开源，业界不足共识。而 Hadoop 开源之后，基于Hadoop 的数仓架构逐步成为支流，也即传统的数仓架构。

如上图所示，右边是 OLTP 在线业务所应用的数据库，因为无奈间接在下面进行剖析，所以个别会通过 MySQL 的 Binlog CDC 或间接读写数据库 ETL 的形式，将数据变更或全量的数据导至 Hadoop 平台，而后在 Hadoop 中应用 Hive 等软件进行数据分析，并且生成报表，将后果写入到另一个 OLTP 的数据库中，也就是左边用来做离线剖析的后果出现的 Data Serving 层。最初再由 Data Serving 层将数据展示给利用。

因为这一整套链路十分长，还有 Hadoop 中各种各样实现的起因，所以这一架构在最开始只能做到 T+1 的水平，即当天的数据写入后第二天能力计算出来。

尽管解决了海量存储与计算的问题，然而失去了数据处理的实时性。近年来，随着实时性的需要越来越多，为了保障数据处理的实时性，呈现了一种新的架构：Lambda架构。

Lambda 架构的特点在于为离线的 Hadoop 加了一个实时计算层，个别称之为 Speed Layer，晚期次要应用 Spark Streaming 或 Storm 流式计算引擎来间接采集 OLTP 的数据，将其计算为实时的数据，而后和离线的 T+1 的数据混合在一起，提供给利用。如此，利用即可失去一个相对来说比拟实时的数据。

传统数仓时代只能做到 T+1，有了 Lambda 的架构后，就能够实现 T 加零点几，昨天的数据和明天半天的数据合并在一起解决。不过，在此基础上是否实现更实时的数据分析？

Kappa 架构应运而生。之前 Lambda 架构的痛点在于须要做非常复杂的保护，因为同时要把数据写到 T+0，也要把数据写到实时的局部，而后再将两局部的后果整合起来。有了 Kappa 架构之后，只有通过实时的计算层，按需拉取 OLTP 业务的变更，而后将计算结果数据出现进去即可。然而这一套体系因为性能方面的起因，临时还没有失去特地宽泛的利用。

能够看到，在数仓架构演讲的过程中，数据实时性曾经变成了大家广泛的需要，同时海量的数据处理能力也必不可少。在这种状况下，咱们来看看 TiDB 能做什么。

TiDB 1.0 公布时，架构图如下，这也是所有很多人对 TiDB 的第一印象。

TiDB 的架构非常简单，首先是 Load Balancer，能够将用户的 SQL 申请打散，发送到 TiDB Server 中。TiDB Server 是一个无状态的计算层，能够随便扩大，理论的数据存储在分布式 KV 存储 TiKV 中。此外，还有一个 PD 组件来对这些数据进行调度以及规整。

这一套架构最突出的局部是扩容，以扩容作为第一要义。扩容体现在两个方面，一是存储扩容，传统的单机数据库无奈承载的数据量，TiDB 能够将其存储到分布式存储中。二是计算上，传统数据库单机无奈接受较高的 QPS，通过这种扩容的形式，QPS 能够打散到不同的计算节点上。

在 TiDB 4.0 之前，咱们始终连续这套架构。以下是 TiDB 4.0 之前咱们能做到什么的总结：

兼容 MySQL 协定及个性的关系型数据库；
存储天生具备程度扩大能力，无需分库分表；
承载千万级 QPS 在线业务；
计算存储拆散，可进行弹性的资源配置；
数仓 Serving 层的优质载体（数据中台）。

首先，TiDB 的立足点是一个 兼容 MySQL 协定以及 MySQL 个性的关系型数据库，具备程度扩大能力，包含存储和计算都能够进行程度扩大，并且不须要分库分表。在此基础上，因为反对计算的程度扩大，所以能承载高 QPS 的在线业务，并且存储、计算拆散，为弹性资源配置提供了根底。

但超乎咱们设想的是，许多开源社区用户将 TiDB 作为数仓的优质载体。TiDB 能够承受海量数据的存储，同时也能够提供比拟不便的拜访接口，所以很多用户天然地将其作为数仓的中间层。

在 TiDB 4.0 之前，设计上齐全没有思考到这种用法，所以存在很多问题，比方计算是单节点，无奈进行分布式扩容，一些比拟重的计算工作也不反对。同时，TiDB 的存储引擎 TiKV 应用的是行存的存储格局，行存的劣势在于 OLTP 场景下能够较好的解决并发事务，然而在 OLAP 场景下的性能不太现实。

因为收到了各种各样的用户需要，所以咱们专门研发了 TiDB 的列存引擎 TiFlash，来承载 TiDB 的 OLAP 负载。在 TiDB 4.0 中，TiFlash 正式成为了 TiDB 家族的一名成员。

在 4.0 之前，社区曾经提供了一套 TiSpark。TiSpark 实质上是一个 Spark 插件，通过 TiSpark，咱们能够在 Spark 中拜访 TiDB 集群中的数据，并对其进行读写。然而应用 Spark 拜访 TiDB 的数据会存在肯定问题，因为它是一个高并发的扫表申请，会导致 TiKV 自身 OLTP 的负载受到影响。

在有了 TiFlash 之后，就能够齐全隔离到 OLAP 和 OLTP 的负载，也能保障一致性。TiFlash 的一致性是通过 Raft 的同步协定来做的，相熟 Raft 的同学应该晓得，它是一个同步复制协定，所有的数据都是以 log 的模式来出现。每一条 log 都有一个全局统一的 ID，也是其地位的 index。如果两条 log，一个是 4，一个是 5，那么 Raft 协定能够保障 5 肯定是在 4 之后才会写入，当 5 进行写入时所有的 Client(TiDB) 均能读到 4，从而满足线性一致性。

一般来说，在 Raft 中只有 leader 能够进行读写操作，但如果对此进行优化，实现一个 learner 或者 follower 的状态即可满足读取 leader 上同样一个 index 的条件，就能够间接从 learner 上读取数据。TiFlash 就是利用这样一种机制从 TiKV 集群中同步数据，并且达到线性一致性的。这样做的长处在于：

首先，假如用 binlog 等形式来将数据同步到列式剖析引擎中，两头会有额定的传输开销或者相似于中间件的解决开销。而间接通过 Raft 协定来进行写入，在一条数据写到 leader 时，会走 Raft 的 quorum 确认流程，此时数据曾经被发送到 TiFlash 进行写入了。另外，尽管 TiFlash 的写入确认不须要同步，然而它的数据和 TiKV 外部的高可用优先级是一样的，这是达到一致性的要害。

总体而言，在有了 TiDB 4.0 之后，剖析能力上了一个台阶 。此时，咱们能够骄傲说 TiDB 是一个真正意义上的 HTAP 数据库了。TiDB 的特点 如下：

真正意义上的 HTAP 数据库；
相互隔离的 OLAP 和 OLTP 负载；
剖析敌对，强实时性、强一致性的列存；
一体化部署运维体系，优化器智能抉择存储引擎；
ALTER TABLE \`db\`.\`table\` SET TIFLASH REPLICA 1，一句简略的 SQL 即可体验 TiFlash 带来的加强。

在 5.0 的时候，为了解决上述痛点，咱们研发了 TiDB 的 MPP。先理解一下 MPP 到底是什么。

在执行 SQL 时，应用的是一套 Volcano 的模型，其劣势在于算子之间是能够解耦的，毛病在于上下游之间的调用有耦合，即必须是上游找上游要数据，而后上游才会将数据算进去提供给上游。每一个算子之间的生产能力和生产能力十分不匹配。只管 TiDB 自身也做了十分多的优化，在算子外部通过并行计算来放慢其计算速度。但归根结底它也只是一个单机的计算引擎，下限非常低。为了解决这个问题，咱们充分利用了 TiFlash 节点。

首先，看看如何实现。

一条 SQL 从 TiDB 进来，通过 Parser 和 Planner 生成一个 TiDB Logical Plan，而后 Logical Plan 通过 TiDB 的优化器之后，会判断是否是 OLAP 申请。

如果是 OLAP 的申请，须要依据代价估算来抉择从 TiKV 进行读写，还是 TiFlash 进行读写。在此过程中，咱们还会为这些 join 的算子加上 exchange，也就是 Volcano 论文 中提到的并行化的形式，生成一个并行的执行打算，再将这些执行打算的片段给推送到对应的 TiFlash 节点执行。

来看一个理论的例子。

上述是来自于 TPCH 数据集的数据。TPCH 数据集中有一个叫做 lineitem 的表，lineitem 的表中存取的是所有的商品的信息，一般来说是 6 亿行左右。此外，还有 orders 表，orders 表是商品订单的事实表，咱们在做简略的 Join 之后，加上一个 Count Star 的聚合。此时的 Plan 在 MPP 架构下则有所不同。以前，通常状况下 Join 上面是两个 Table Scan，如果是在 TiDB 中进行计算，两个 Table Scan 之后能够间接放到 Join 的算子中。但在 MPP 之后，咱们会先对 Scan 进去的 Table 进行一个依据 Join Key 的 Shuffle，而后将数据推送到对应的计算节点，整体计算实现之后，再推到 TiDB 中返回给用户。

这样的 益处有两点，一方面如果应用单个 TiDB 节点来进行计算，须要在内存中放大量数据，甚至数据可能是 TiDB 包容不下的，此时就必须将其落到磁盘上，计算效率非常低。然而通过 shuffle 分区之后，每个计算节点上须要计算的数据质变小，能够全副包容在内存中，能够实现减速的成果。另外，MPP 能够同时利用多台机器的 CP，实践上能够实现十分强的扩展性。

为了验证 TiDB MPP 的性能，咱们比照了其余产品，集群是三个节点的集群，每个节点下面应用的都是 NVMe 的 SSD，能够尽可能的排除存储上读取对于整个计算速度的影响。

如上图，能够看到蓝色的是 TiFlash MPP 的性能，长短代表它的执行工夫，这项指标越短越好。从上图能够看出，比照 Greenplum 和 Apache Spark，MPP 在绝大多数的查问下都处于劣势位置。起因在于：一方面，TiDB 5.0 自身集成了一套列式计算引擎，性能十分弱小；另外一方面，MPP 架构绝对于批处理引擎的劣势在于所有的工作是平行的，不会存在相互依赖的状况，所以它能够用更好的形式进行并发。但毛病在于，相较于批处理，无奈反对过于宏大的数据量，不过在绝大多数的场景下，MPP 架构曾经十分够用了。

总结一下TiDB 的 MPP。

反对多种并行执行算法：
- Broadcast Join。
- Repartition(Shuffle) Join；
- Two Phase Aggregation；
- One Phase Aggregation；
可扩大简单的查询处理能力；
TiDB 高度集成，优化器主动抉择；
降级到 TiDB 5.0 后，仅需开启开关 SET tidb\_allow\_mpp=ON 即可应用。

有了 MPP 架构之后，TiDB 5.0 新引入的几个 Feature，使 TiDB 的 HTAP 能力失去了极大的晋升：

OLTP:
- Async Commit，1PC 提供更低的事务提早。
- Clustered Index 强化特定负载下的提早和吞吐量。
OLAP:
- SQL MPP 大幅晋升 TiDB 解决简单查问的能力。

以上分享了 TiDB 不同阶段的性能个性和产品能力，上面将具体阐明大家是怎么用 TiDB 的。

依据用户反馈以及咱们本人的整顿，发现了以后 TiDB 最罕用的几个场景。

首先，交易剖析的一体化，这种场景下数据量级个别处于中等水平，即 TB 级别。

如果单纯应用 MySQL，无奈比拟好地进行数据计算，所以个别须要将这些数据导入到剖析型数据库中进行计算，比方 ClickHouse、GreenPlum 等，再将计算出来的报表出现进去。有了 TiDB 之后，能够将这两局部相结合，TP 间接写 TiDB，AP 也间接在 TiDB 上进行计算 ，而后出现后果，这样能够 极大节俭了运维老本，并且可能实现性能上的晋升。

交易剖析一体化的场景比拟常见的，如：CRM 零碎、ERP 零碎等，也是咱们十分推崇的最残缺的 HTAP 的场景。然而互联网公司个别无奈应用，必须也有离线的局部来解决海量的数据。

因而，在这套体系中，TiDB 次要被用于实时剖析。

业务数据通过 Kafka + Flink 的形式，在 Flink 中做预聚合或拼宽表，而后再将这个后果写入到 TiDB 中，供给用查问。这是常见的实时剖析架构。而如果利用的线上业务曾经用了 TiDB，整套架构就更天然了，能够间接应用 TiDB 的 CDC 性能，将数据导入到 Flink 中进行解决。

因为整套架构十分实用，目前已广泛应用于多个业务场景，前面将举例说明。

实时剖析中应用 Flink 也有几种常见的架构。

应用 Flink MySQL connector 解析 MySQL CDC

第一种架构，前端业务应用的是 MySQL，比方分库分表计划，通过 Flink MySQL Connector 获取 MySQL 的数据变更，而后再将数据写入 TiDB。

应用 Kafka 推送 Canal JSON 等格局

第二种架构，通过 MySQL binlog 解决的中间件，比方 Canal 等解决数据，而后写入到 Kafka 供 Flink 生产，最初再写进 TiDB，这种形式比拟常见。

应用 TiCDC 推送 Canal JSON 到 Kafka

第三种架构，用户前端曾经应用了 TiDB，通过 TiDB 的 CDC 性能，输入 Canal JSON 格局到 Kafka 中供生产，Flink 再将数据写入到 TiDB 相似的数据库或者其余 sink 中。

数仓减速层 / ODS 层

还有一种常见的计划，数据仓库的减速层或者说 ODS 层。

最常见的用法个别数据仓库会将减速层离开，有了 TiDB 之后，两局部是能够合起来的，用户的数据能够通过各种各样的形式写进 TiDB，在 TiDB 外面在进行一些 ETL 之类的操作而后写入到离线计算中，最初再将后果反馈到 TiDB。TiDB 能够间接对外提供实时数据分析的服务，这也是十分风行的架构之一。

接下来，将分享一些事实中公司的案例。

首先是大家都比拟相熟的中通快递，中通快递当初应该是寰球业务规模最大快递企业之一。近几年，他们开始尝试应用 TiDB 来做包裹追踪管理工作。晚期，他们应用 TiSpark 进行计算，而后将数据拼成宽表写到 TiDB 中，再进行一些聚合。最近，他们曾经在测 5.0 的 MPP 架构，看看 TiDB 5.0 是否提供更多帮忙。

中通快递
- 寰球业务规模最大快递企业。
物流全链路生命周期治理
- 同一套 TiDB 平台服务包裹追踪治理与实时报表。
- QPS 峰值 12 万 +。
- 实时统计分析。
- 通过 TiSpark 连接离线平台。

中通快递的架构如上。首先，包裹追踪是线上业务，通过 Spark Streaming 训练形式写入到 TiDB 中，同时进行实时剖析，而后 TiDB 的归档数据将发送到中通的大数据平台进行计算，最初大数据平台的计算的后果再写回到 TiDB。在这个构造中，TiDB 是整个实时计算的整合层。

小红书是一个内容同时做垂直电商相干的平台，目前用户量和访问量都也十分大。

小红书的晚期架构是业务应用 MySQL 分库分表的计划，业务数据通过 ETL 写入到离线产品，进行 T+1 的计算后，再写回到另一个 MySQL 的分库分表集群中，对外提供数据服务。同时，也会利用离线数仓来做风控相干的业务。

上述架构的痛点在于 T+1，业务和运维都十分好受。在尝试 TiDB 之后，将架构进行了降级。

目前业务在线层依然应用分库分表，但业务数据会间接通过一些简略的形式写到 TiDB 中，同时 TiDB 将数据反馈给离线层，做完离线数据的解决再写回到 TiDB。

上述构造间接应用 TiDB 进行数据分析或风控服务，整体架构从 T+1 变成了 T+0，并且据小红书工程师反馈，用了 TiDB 之后，节俭了很多 MySQL 分库分表的运维精力，这也是 TiDB 的长处之一。

智慧芽是提供 SaaS 服务的厂商，为寰球 50 多个国家超 10000 家科技公司、高校、科研与金融机构提供大数据情报服务。

智慧芽
- 高速倒退的科技翻新 SaaS 服务商，为寰球 50 多个国家超 10000 家科技公司、高校、科研与金融机构提供大数据情报服务。
实时数仓
- 部署于 AWS 云环境。
通过 AWS Kinesis / AWS EMR Flink 进行数仓建模。

智慧芽的所有业务都部署在 AWS 之上。晚期，智慧芽通过 AWS 的 Redshift 来进行数据分析，然而 Redshift 自身的速度并不特地现实，因而为了取得更好的实时性，智慧芽开始尝试应用 TiDB 构建实时数仓。在数仓架构上跟其余公司十分类似，也是应用 Flink 进行实时数据处理，而后将各种各样的数据写入到 TiDB，最初间接出现给数据利用。

以上几个案例是十分典型的应用 TiDB 来做实时数据分析的场景，其中也有绝对偏差于 HTAP 的业务如小红书的架构，其线上业务数据会间接写到 TiDB 中，能够充分利用 TiDB 的 OLTP 能力。

看了这么多案例之后，咱们也能够设想一下 TiDB HTAP 的将来。

首先，最重要的一点，5.0 之后，TiDB 曾经 能够用来做简单计算了，同时咱们能够提供更加实时的场景来验证。

有了 SQL 和 MPP 之后，咱们有了更快的计算速度，同时能够承载更简单的计算工作，再加上强实时性的数据，以及强一致性保障。有了这些之后，咱们能够做到什么？

首先，直播场景。在某个大主播开播时，用户会间接就涌进来，此时用户的信息会插入到拜访的事实表中，主播的直播间也会对其维度表进行更新。这一套架构如果依照传统的形式来，可能会应用 Flink 对数据进行解决，但同时也存在一个问题，操作的并发度将会十分高，并且须要在短时间内实现。因而，如果要 Flink 进行解决，须要保护一些比较复杂的 Watermark 等，并且在进行预处理后，可能也会带来一些提早。

如果间接应用 TiDB 来承载这些负载，当数据写进来时能够马上对它进行剖析，生成剖析报表，及时反馈到平台或主播，以便及时进行业务上的调整。当然，直播场景的利用目前还是假如，咱们期待着 TiDB 在直播场景的落地。

另外一个场景，以实时风控为例。局部在线平台常常会产生交易和转账类业务，但新闻中常常报道的欺骗事件也与此相关。事实上，金融或其余交易平台个别存在风控业务来检测和躲避相似事件的产生。

之前的风控可能存在的问题之一是作案过程十分迅速，以至于风控规定还未触发但欺骗的流程曾经完结了。不仅造成用户的经济损失，也影响警察办案效率。

如果将 TiDB 利用于风控业务中，在违规交易产生的霎时，能够间接进行剖析，触发风控策略。整个链路提早将极大升高，也有助于相干部门能更快破案。

其余更多 TiDB HTAP 的利用场景也欢送大家来帮忙咱们设想，独特畅想 TiDB 的将来。

关于数据库:使用-TiDB-构建实时应用

数据管理技术的演进

传统数仓架构

Lambda 实时数仓

Kappa 实时数仓

TiDB 能做什么？

TiDB 4.0 之前

TiDB 4.0 之后

TiDB 5.0 HTAP

大家是怎么用 TiDB 的？

交易 / 剖析一体化

实时剖析

实时剖析：Flink 架构

利用案例

中通快递物流

小红书

智慧芽

TiDB HTAP 的将来

SQL MPP 意味着什么？

直播场景

实时风控场景