共计 5774 个字符，预计需要花费 15 分钟才能阅读完成。
作者介绍：马晓宇，PingCAP HTAP 产品部负责人。
数据实时化成为业务必须
数字化转型浪潮是当初进行时，在企业数字化转型的过程中，咱们看到一个广泛的趋势，企业对“海量、实时、在线”的数据需要变得更加迫切。数字化转型并不是互联网公司的专利，人工智能、大数据、物联网这些技术也不仅仅是互联网公司才会应用。事实证明，越来越多的传统企业正在利用这些新兴技术进行业务的翻新。每一项新技术的利用都须要肯定的技术积攒，互联网公司兴许会装备很多工程师来反对一个数据体系架构。但对于传统公司来说兴许不具备这样的实力，他们会发现自己很难驾驭大数据技术栈。此外，传统大技术栈曾经缓缓开始难以应答突飞猛进的业务需要和爆炸性的数据增长。企业的很多业务对数据实时性的要求越来越高，比方风控、反欺诈等，更早地辨认和阻断危险能够让企业缩小损失；在物流行业，更实时的数据让物流企业能够更实时地调配行车路线和各类资源，以达到更好的经营效率；公共服务也会对实时数据产生要求，如果去柜台办理一个业务，须要等很久能力查到刚刚办的上一个流程的数据，这对于用户体验来说是十分蹩脚的。
用户心愿用简略的数据库应用体验应答大数据到来
数据的实时化对技术自身要求十分高，一个实时化的数据技术栈，对业务和技术的复杂度提出了更进一步的需要。事实的状况往往是企业的前台业务和离线数仓之间短少良好的连接，短少一个能够与成熟大数据技术无缝连接的体系。在企业的混合负载场景中，ERP、CRM、MES 等蕴含多种不同数据拜访模式，无奈简略辨别 OLTP（在线交易解决）与 OLAP（在线剖析解决），DBA 须要一直实时查问各种不同维度的报表。以往用户应用传统单机数据库承载业务，但当数据量暴涨之后，他们被迫应用更简单的架构去重构业务零碎，这个代价和工夫老本通常是业务无奈接受的。
举个例子，比方 DBA 把流水账以 OLTP 的形式来录入，同时有一部分数据是转存到离线数仓之中提供报表查问。在这样的数据架构中，数据链路变得非常复杂：首先应用服务器同时面对数仓类和 OLTP 类的数据库，这两类数据库之间还要搭建 T+1 的 ETL 数据处理流程，从而使两者能共享数据。前端的业务也会面临间接跟应用服务器打交道或者从大数据技术栈捞取数据的状况，这对于利用架构来说非常复杂。更进一步而言，SaaS 或应用软件供应商会感觉尤其苦楚，因为他们要面对客户的所有零碎，技术栈的复杂度和保护难度将呈指数级回升。
在流式计算场景中，基于大数据或者互联网架构，通常得把日志流传向后端，而后进行日志和行为剖析。传统业务在应用流计算场景的时候，更多的时候前端可能是 OLTP 类的数据库，通过 CDC（Change Data Capture 变更数据捕获）组件向上游输入带有“删”和“改”不同类型操作的数据日志。这些日志在传统的架构下，并没有一个十分好的技术栈去解决。对于上游来说，依据不同的业务需要，也会派生出不同的数据存储去寄存和应答这些不同的数据申请。
如果心愿承载 CDC 的日志，要求上游的数据库也能实现实时的对应“删”和“改”，或者能够选 MySQL，但抉择传统单机数据库遇到常常遇到的问题是在海量数据下没有方法做很好的扩容。如果抉择既能够扩容、又反对删改的，第一个可能想到 NoSQL 数据库，然而 NoSQL 没有方法进行简单的数据分析，即便用来做数据分析，也无奈达到现实的性能。所以这两种抉择在数据量增长的数据分析场景都不太实用。
还有一些其余的抉择，比方 Elasticsearch，他其实是一个搜索引擎，如果用来做聚合，就会面临灵活性丢失的问题。此外还有传统的 MPP，他是依据传统 T+1 数仓入库的流程而设计的，所以无奈很好地应答数据的实时更新，尤其是 CDC 类的数据更新。
综上所述，无论是从数据链路层，还是到整个上游的承载，目前都短少成熟的计划来应答，这就造成了很多时候数据架构师们会把不同的技术架构栈组合在一起以满足业务层的需要。 举个例子，企业的某种业务蕴含多个子需要，这些子需要须要多种查问零碎或者多种数据平台联结起来工作能力实现，这就造成了企业整个数据架构栈会变得非常复杂，而且栈和栈之间数据的一致性和时效性无奈保障。
在 2000 年互联网浪潮还没有到来之前，大多数企业曾经在建设上一代的数字化，次要是通过应用数据库来实现的。单体数据库在那个阶段能够能胜任大多数不同的业务需要，所有的数据拜访需要其实都应该由数据库来实现，而不是由各种各样简单的组件来实现。尤其对于传统企业来说，他们更偏向有一个更像传统数据库的技术解决方案来升高技术转型的门槛，这套计划在提供传统数据库体验的同时，还能给数字化转型带来的业务和规模复杂度提供等量的反对。
从大数据技术的发展趋势能够看到，Hadoop 这类传统的大数据技术栈前行的脚步在放缓，整个传统的大数据技术栈曾经达到了应有的成熟度，遇到了相应的天花板，要想达到相似成熟数据库个别的体验，简直是不可能的。在技术倒退变缓的前提底下，现有的产品依然无奈达到企业期待的成熟度，于是企业开始寻找其余现实的计划。企业期待中的现实计划是怎么样子的？首先，能够应答一直收缩的数据规模 ；其次， 须要应答不同作业类型所需业务模型的技术能力 ；最初， 须要像经典数据库一样架构简略，应用和保护也更加简略。 在 TiDB 4.0 中，HTAP 架构是由 TiKV 和 TiFlash 独特组成的行列混合的存储架构引擎，应用 TiDB 作为共享的 SQL 入口，共享前端，用同样的数据权管控，优化器会主动依据代价来抉择行存或者列存。4.0 架构不完满的中央次要体现在存储和计算能力之间的不匹配。从存储节点而言，TiKV 或者 TiFlash，舒服区是在数据量几百 TB 这个级别。从算力上讲，TiDB-Server 尽管能够多机部署，然而多机部署自身无奈实现多机协同，短少独特做一个大简单查问切分的能力。形象一点进行比喻，在 TiDB 4.0 以及 4.0 之前，TiDB 领有十分大的数据存储能力就像小熊宏大的身材，但计算能力就像小熊的头部，两者是不成比例的。
在 TiDB 5.0 的 HTAP 体系中，TiFlash 曾经不仅仅是一个列式存储引擎这么简略。TiFlash 引入了 MPP 模式，使得整个 TiFlash 从单纯的存储节点降级成为一个全功能的剖析引擎，保留繁多的入口，应用用同样的权限管制，OLTP 和 OLAP 依然是由优化器提供主动的抉择。
TiDB 4.0 中，OLTP 和 OLAP 的抉择只波及抉择行存或者抉择列存，5.0 能够提供更加多维度的抉择，例如抉择 MPP 引擎或者抉择用单机来进行计算。在架构更新的同时，TiDB 5.0 基于 MPP 引擎，提供了超过传统大数据解决方案的性能。
TiDB 5.0 HTAP 架构设计
TiDB 5.0 HTAP 架构图中，能够看到右下角的 Storage Cluster 是整个 TiDB 的存储引擎，蕴含 TiKV 节点，应用的是行式存储，所谓行式存储就是一行的数据会间断寄存在相邻的地位。TiFlash 节点应用的是列式存储，列式存储的含意就是不同行当中同一列数据会相邻存储在一起，行和列别离会应答不同的业务需要，行存偏向于响应 OLTP 类业务。
个别 OLTP 类业务是大量查问个别的行，进行批改，而后再进行回写，业务心愿尽可能地把所有一次操作的数据都放在同一个地点，这就是行存具备的能力。列存个别用来响应报表类和 BI 类申请，例如从一个相当宽的表当中选出其中几列进行筛选和聚合，在这个场景，列存能够抉择其中须要读到的列，而不必去碰那些不必的列，而这在行存当中是无奈实现的。此外，列存引擎也会更好地配合向量化引擎，做到从磁盘读取或者到内存计算，都是一个向量的形式来进行数据的排布，这是对 BI 和剖析型引擎最好的减速。
在 TiDB 5.0 中，TiFlash 会全面补充 TiDB 的计算能力，TiDB 在 OLAP 场景下就会进化成一个 master 节点，PD 职责没有任何变动。基于 MPP 架构，用户会向 TiDB Server 发送查问 SQL，这个查问 SQL 会由共享的 TiDB 服务器来承当。这些 TiDB 服务器会进行 Join，而后交给优化器去决策。优化器会把应用行存、列存、某些索引、单机引擎、MPP 引擎，或者是应用不同组合产生不同的执行打算，都纳入到同一个代价模型中进行评估，最初选出一个最优的执行计划。假如业务须要依据某一个人的订单号去查问以后的订单，这是一个点查的查问，优化器将间接向 TiKV 发送点查申请。如果业务有一个报表类查问需要，须要关联百万甚至千万级别的表，并在关联的后果之上再进行聚合与剖析，这就是一个 典型的 MPP 加列存的查问，优化器就会把这部分查问下发给 TiFlash 的剖析型引擎节点进行计算。
上图是剖析型引擎的执行打算拆分和解决流程的示意。图中所有红色的虚线框都代表一组节点的物理边界，例如右上角的一个查问，须要 SELECT COUNT 两张表的关联，并依照条件排序。这样的一个表查问就会被拆分成一个查问打算，有两组机器进行扫描，这两组机器可能是共享同一组硬件资源，有一组节点负责扫描左表，有另一组节点负责扫描右表，两个节点别离依照关联查问条件 Join 数据，同样的数据会被关联到一起，属于同一个分片的数据都会达到同一组机器或者同一个机器上，机器再进行部分的关联，把后果合并产生一个残缺的后果，最初进行聚合后返回给用户。这就是整个 MPP 架构带来的益处，相似 Join 这样大规模的查问，能够很不便地通过多节点来进行分担。
很多人关怀 MPP 引擎到底有多快，这里展现了一个实在场景比照测试的后果。在三节点 TPC-H 100GB 环境下，主表白到几亿规模的数据量，查看在等同的硬件和资源投入下测试执行不同 Query 所须要的工夫。从测试后果能够看到，比照 Greenplum 6.15.0 和 Apache Spark 3.1.1，TiDB 5.0 MPP 展现了更好的性能减速，总体取得 2 – 3 倍的性能劣势，个别查问可达 8 倍性能晋升。
在 TiDB HTAP 底下用户只有写 SQL 就好
绝对于 TiDB 4.0 来说，TiFlash 曾经不仅仅是一个列式存储引擎，曾经进化成为一个残缺的计算剖析引擎，最终实现了把 OLTP 和 OLAP 残缺地合二为一，应用同一个前端，数据库就回到了靠近于最后经典状态的样子。一个数据库其实能够同时解决各种模式的查问，数据库只有保障以尽可能高效的形式运行，返回用户应该有的后果就行了。用户只管写 SQL，只管对提出查问或者写入需要，不必管业务是 OLTP 还是 OLAP，TiDB 提供对立入口，同一份逻辑数据，两种存储格局，依附前端优化器自由选择最优的执行形式，对用户屏蔽了底层架构的复杂度，用户只管写 SQL 就能够了。
在混合负载场景下，应用 TiDB 能够承载 OLTP 类业务，同时应用 TiFlash 减速实时报表，减速对剖析业务的查问响应。从架构上来说，以往须要有不同的数据链路去保护不同数据引擎之间的数据流转和存储，当初对用户而言只须要一个入口，一个 APP Server，不同的业务类型能够不加区分地接入这个 APP Server，APP Server 向 TiDB 发送申请，TiDB 将不同的业务向不同的引擎进行分流和减速，整套技术架构栈变得十分简洁。
数字时代，越来越多的业务对实时剖析的需要更加迫切，在流式计算场景下，对于传统的日志流剖析的需要，大数据提供了比拟成熟的解决方案。在联机交易或者要求传统 OLTP 类数据库传输带有删改的数据，以及带有 Join 数据的场景下，TiDB 就是目前最现实的计划。
首先，TiDB 是一款真正的 HTAP 分布式数据库，能够十分不便地作为一个从库，挂接在 Oracle 或者 MySQL 这样的数据库前面，不须要简单的数据同步伎俩，借助 Kafka 或者其余数据管道来进行同步即可。TiDB 能够挂在 MySQL 前面作为从库或者作为 Oracle 的一个复制目的地。与此同时，如果业务心愿做一些数据处理的话，也能够随时切换到传统的数据架构上。
TiDB 自身是一个带有 OLTP 类属性的 HTAP 数据库，对于任何实时的删改增落地，TiDB 是能够达到实时响应，整条数据链路能够实现秒级查问。TiDB 自身的行列混合属性也象征数据落地不论是明细数据的明细查问，还是对于数据的各种不同维度的实时聚合，都能够很好地响应。
在数据中枢场景中，假如前端有多个业务线，每个业务线都有本人不同的 OLTP 类数据库，例如财务、EPR、销售、仓储数据库，有 Click Stream、有 User Profile、也有产品库，还有用户登录和第三方不同的数据源，这些数据寄存在各自的数据库中，能够通过 CDC 的形式或者通过 Kafka 实时集成到 TiDB 外面。这些从不同数据源、不同业务线整合过去的数据，能够放在数据中枢层。
数据中枢层是绝对于离线的数仓层来说的一个概念，首先他只寄存一部分时间段内的数据，而数仓可能会放更长远的历史数据；数据中枢层更偏向于是寄存温和热的数据，能够提供实时的数据存取和查问服务。绝对于大数据和离线数仓层而言，数据中枢能够间接对接数据利用端，作为一个既能够承接高并发拜访，又可能以数据服务的模式来提供全量数据的存取，而离线数仓和数据湖更偏向于离线的形式，通常提供不太陈腐的数据来进行报表与 BI 类查问。
当 TiDB 集成到整个数据平台当中，他充当了一个数据中枢的角色。即便数据平台中曾经有了离线数层和 Hadoop 平台，依然能够把 TiDB 放在业务层、Hadoop 层，或者在数据仓库层之间，作为提供一个实时数据存储和治理的平台，用来满足越来越多用户对于实时存取与实时剖析的需要。
从以上几个场景能够看到，TiDB 的能力曾经超过了一个分布式关系型数据库自身 ，随着 5.0 MPP 性能的引入与多项企业级个性的加强，TiDB 曾经倒退成为“ 一栈式数据服务生态”，即“one stack to serve them all”。在这整个数据服务生态中，并不只有 PingCAP 在发明和建设，宽广社区小伙伴们参加了这套生态的共建和迭代，总计有 538 位 Contributor 提交了 12513 个 PR 协同 PingCAP 一起实现 5.0 这个里程碑版本的开发。例如知乎，给社区奉献了多个大数据生态相干的组件和生态工具，对于大体量用户的业务场景极具利用价值。
咱们置信凋谢和通明的合作，必定会发明出全新的、有限的可能性，把 TiDB 打造成为一个更加欠缺的“一栈式数据服务生态”，咱们一起在路上。