课程名称：课程版本（101/201/301）+ 课程名称
学习时长：23
课程收获：
TiDB可以提供业务后台和业务中台的能力
业务后台既可以使用原生的复制，为BI系统提供实时的数据分析，进行决策
业务中台记对一些温数据进行留存，使用TiSpark进行数据流传
课程内容：
第一部分什么是HTAP,本章节会给予HTAP的简介，什么是HTAP,TP和AP数据库的分类不同点。为什么HTAP可以帮助你以及实现HTAP的技术困难？
什么是HTAP,HTAP是由Gartner 1家著名的市场分析和调研机构发明的词汇，HTAP他本身其实是一个很简单的概念。TP是transactional processing的缩写，AP是analytical processing的缩写，其中TP和AP分别有不同的技术特点，TP就是传统意义上说的交易处理交易处理，往往使用行存，他的更新模式是实时更新，一般来说TP的交易会有非常高的并发，然后要求有一致性，而且每次访问只触及一小部分行，一般TP数据只存当前数据。AP的处理一般就是分析处理，往往使用列存格式，而列存格式更新，一般使用批量更新，列存和分析型作业一般是低并发的，而且每次查询会触及和处理非常多的数据。而且AP处理往往是处理历史数据
由于刚才说的两点不同的技术方向，所以一般来说，我们会把TP和AP数据库拆成两套不同的系统，而传统的数据平台，一般来说都会多多少少长成像上图这样子的样子，就是你会把在线的TP交易放到在线的数据库oltp的数据库，然后每隔一段时间。会把这些数据通过etl的方式转移到你的数仓或者你的数据库湖当中，然后这etl过程本身会带来很大的延迟，换句话说，你在数仓或者数据湖当中能分析到你数据的时候，其实已经是旧的数据。在数仓和数据库当中整理完数据的时候，你有可能就需要把它转储到，比如data server的数据库，或者是说再回馈到在线的数据库，那么又需要经过一次数据转运，这样子不但会带来数据平台非常复杂，而且数据转运的过程当中，etl也会带来你们数据新鲜度的丢失，那为什么我们需要HTAP？
现在用户往往发现说TP和AP之间的界限会变得模糊起来。你会遇到有一些有点像TP，但它实际上是AP的case，或者说有点像AP，但它实际上是TP的case,比如说你需要架构一个综合型的查询平台，然后这个查询平台不但要提供报表类查询，也需要提供高并发的短查询。或者是说你需要对在线数据进行实时的分析，或者是说你需要实时的分析跨不同数据业务线汇聚过来的实时数据，那为什么HTAP能帮助你呢？HTAP数据库可以使架构变得简单，也可以降低你的运维成本，而对业务来说，HTAP数据库可以使得你能达到实时查询和实时分析能力。还能促进业务的敏捷性，因为你可以做实时的分析和实时的决策，所以的业务决策会变得更敏捷
来看一个具体的例子，这是一个销售数据平台，在这张图的最左和最右测分别。也是tp 和 ap类的业务，大家先看最左侧online orders就是在线订单管理的业务，那么这个业务不管从任何意义上来说，它其实都是一个tp类的业务，那么在线订单管理，大家可以想一下说你到底需要数据库能提供什么样的能力，首先说订单管理，你需要能精确定位到某一笔订单，或者说通过某种条件去定位到某一笔订单，比如说我通过购物车的关联。或者说通过用户订单号去查询具体的订单，那么这些不同维度的查询，搜寻具体某一些订单的时候，你需要的是索引的能力，能精细化的查询到某一些记录，然后同时订单管理假设说我付款下单，那么你需要改变订单的状态。那么换句话说，订单管理系统也需要拥有实时更新的能力，在线订单管理毋庸置疑说会有，同时有很多用户发起订单的查询变更，那么这些也会要求数据库拥有高并发吞吐的能力，那大家再来看最右侧history report就是销售历史报表，这从不同意义上各种意义上来说，它都是一个典型的AP的业务。那这样的业务对于系统有什么需求？首先说你要存储的历史数据，换句话说，历史数据要求数据库有可扩容的计算和存储能力，所以他需要 Scalable，而列存往往是用在分析型数据库，或者是说分析型业务，一般来说标配就是列存。所以上的业务也要求数据库拥有列存，那再来看看两个圆的交集，那这些交集当中的业务就属于你，不是很容易区分他到底是分析型业务还是在线交易业务，比如说如果做一次双11大促，然后在大促的同时，我希望能对最新鲜的数据进行分析，然后给用户一个提示，说现在卖的最好的是什么产品，这就是所谓best seller realtime的分析,那么。对于这样的业务来说，需要的数据库能力是，首先我是一个分析业务，我要求他能使用列存提供最好的分析性能，同时我不止是说需要列存，而是说我需要这个列存的数据，能实时的反应在线业务的变更，也就是说用户的订单，每一笔订单下单，买了每一笔东西，那我都能在我的列存分析当中体现出来。而不是说我需要通过etl转储到第二天才能显示，所以说这样子的业务需要同时拥有列存和实时更新两种能力，类似的还有real time campaign adjustment，比如说我在双11大促的时候，需要实时看售卖的情况如何，然后决定说我是否要调整我的价格，或者是说我需要接入实时大屏，那这些都是非常类似的需求。有一些不同的是，比如说我需要架构一个综合性的查询平台，然后这个查询平台需要能实时的接入不同数据源的数据，然后要能提供不同的查询，首先说你接入实时数据源的时候，这些实时数据源会给你在线的增删改查的同步数据，那么这些在线的增删改的数据。我希望能实时地写入我的分析平台当中，那所以这个分析平台需要能够实时的变更，而且前端的业务线带来的数据很可能是非常高的并发，所以他也需要有高并发的能力，那我需要做分析，那么他需要有列存，但这个查询平台有可能也会需要说我需要定位具体的某一些数据，那么他也需要有索引，然后因为是汇聚不同的业务线的数据，所以他只需要它的存储和扩展，所以类似这样的综合查询平台其实是需要数据库，同时拥有TP和AP两侧的能力
技术上来说，为什么我们不能做这样一个数据库呢？实际上来说，同时需要满足两者的能力是非常困难的，首先说Scalability可扩展性，AP数据库，其实很早就具备了可扩展性，你可以认为说八九十年代的时候，类似于像 paradata(没听过不知拼配拼错)的产品。他其实就已经有了可扩展的分析数据库的能力，但是tp类的数据库可扩展性从nosql一直到现在，只有最近开始尤其后兴起，那么你可以认为说tp类数据库，他解决了可扩展性的问题，除此之外，AP同时存在或者同时运转也是一个很困难的事情，首先你需要同时支持刚才说的两种不同的format，store format 也就是存储格式，那另外你还需要避免不同的业务互相之间有干扰，尤其是说AP业务会一下子占用非常多的计算资源，那么这个时候你的TP业务就会受到影响，一般来说假设你在一个在线库上做一个全年报表，那么你的在线业务本身，比如说订单。查询或者说订单更改状态，那些都会变慢，这是一个非常显而易见的事实，那所以TP和AP同时存在，也意味着说你需要通过某种方式去解决你的TP和AP之间的负载，互相之间有影响这个问题，然后另外并不是说所有数据库只要具备了，说我有TP也有AP，我能存行存也能存列存就可以说我是HTAP数据库。并不是这样子，就假设说你现在有一个行存数据库，然后这个行存数据库同时也能存列存，但是如果我要做实时分析的话，仍然无法避免说我需要把行存的数据转存成列存，那如果是这样子的话，那么HTAP数据库的实施性其实也就丧失了，所以换句话说，这两者之间还要能产生紧密的耦合，或者说紧密地集成数据，能做实时同步，能查询到新鲜的数据，那么这样才能算是一个HTAP数据库
第二部分，这部分会讲一下为什么HTAP数据库能帮助你呢，这也会包含TiDB的HTAP介绍以及实际生活当中的应用场景。
首先说TiDB的HTAP特性，TiDB本身是一个可扩展的数据库，在最开始的时候，他其实是为了很严苛的交易型场景而设计的，它已经被很多金融场景所验证，而同时它也具备分析引擎，所以结合这两点，那么它其实是一个良好的也很天然的数据中枢，或者说实时分析的平台
TiDB 4.0的HTAP架构有一些什么特点呢？
首先说TiDB4.0加入了一个可更新的内存引擎，这个内存引擎可以实时更新，可以实时的承载交易类的数据的变更，另外由于有了列存引擎，所以我们TiDB本身就同时具备了行存格式和列成格式两种，这两种引擎可以分别使用不同的机器资源，所以他们互相之间运转起来是没有任何互相干扰。而本身从行存到列存之间的复制也可以达到一个一致性的数据复制，列存分析本身具备了向量化的引擎，所以他拥有良好的性能，而对于用户来说，一旦创建了列存副本。其实你并不需要关心说你需要怎么样去优化你的查询是使用行存还是什么列存，优化器本身会自动帮你选择行存或者列存，甚至说同时使用行存以及列存，这张图表示的是TiDB的4.0新架构，左边部分是TiKV节点，这是大家之前已经熟悉的内容，那这里重申一下，TiKV节点是使用mutil raft的架构来进行数据的复制，那这里可以看到说range4有绿线进行串联，这意味着说range4的不同副本是使用raft来进行数据复制，而右边 TiFlash 节点是刚才所说的列存，如果你在列存当中创建了一份数据复制。那么比如说是range4，那么range4会通过raft的协议进行数据复制，之所以这里使用虚线的意思是说这个数据复制本身并不是强制要求写入完成才能返回给client表示说数据写入完成，而是说你可以按照正常的考虑，没有TiFlash的场景，底下写完你的数据就可以返回，而数据会经过异步的方式传输到TiFlash节点，被转成列存，这样子的设计可以最大程度的保障说。我在HTAP的这个架构体系底下，我TiKV执行的交易型作业并不会受到TiFlash的列存复制影响，哪怕说TiFlash在这边节点宕机，或者说断电等遇到事故故障，也不会影响TiKV的正常写入。
再讲一下真实案例，TiFlash开始经过一段时间推广，已经积累了非常多的用户，那我们总结过这些用户基本上分成这么几种，最容易想到的用法就是TP+AP的一站式服务，假设说你拥有一个在线数据库，然后他进入的是你的在线应用，也是你的TP应用，然后你需要对这些TP数据进行分析。将会把它导入到一个分析型数据库，然后分析型数据库会承担你的bi相关的业务，比如说你的report或者进行分析其他的决策性的分析业务，在传统的设计当中，你需要使用两套系统，这里说的MySQL可以代表你的OLTP的数据库，那你也需要另外一套分析型数据库，然后你会把在线的业务库向分析型数据库进行复制，这里会增加一个时间延迟，所以你分析到的数据往往是旧的数据，而且你需要两套系统来进行整个业务的开展，那假设说你换成TiDB，你就可以把在线业务的部分使用TiDB业务的行存程进行承载，然后分析型业务使用TiDB的列存进行承载，那么整体来说，你可以用一套数据库去替换原本的两套的架构，除了简化你的架构之外，你还得到了更新鲜的数据，换句话说，你的BI数据库能查询到的数据将是最新鲜的数据，而不是说有T+1 所谓的T+1需要进行等待的昨天的数据，或者几个小时之前的数据。
第二场景，Real-Time DW / Data Hub,这是所谓的实时数仓或者是数据中枢。那这个场景描述的是，用户可以在前端拥有不同的数据孤岛，每条业务线可能都拥有自己的数据库，那这些数据库承载这些业务线的在线业务，那这些在线业务在数据变更的同时，它可以通过CDC或者变更日志的方式向TiDB输送现在当前的数据变化，由于TiDB本身拥有的TP属性，所以它可以很方便地承载这些变更，而且实时的反映到他的数据状态当中。与此同时TiDB具有列存的设计，所以在承载这些业务变更的同时，它也可以进行分析业务，比如说我可以使用TiDB的列存进行报表分析，使用我的BI工具，或者是说有可能用户需要有这样子的需求，还有一个客服中心，那么，这些客服中心可能同时会承载类似于分析的业务，或者是说一些点查型的业务。比如说客服中心可能要统计说今天的报账或者事故发生率，那同时它又需要对客户的投诉，或者说对客户反映的问题进行具体的某一些订单的查询，那么他就同时需要有点查，或者同时也同时具备一些报表查询能力，那么他也许会同时使用到行存或列存两种不同的数据格式，那另外还包含一些常见的比如说实时的 charts，就是实时的图表显示，或者说你可以配合 spark来进行AI的作业，
那也有同学可能问说，我现在已经有了一个数据平台，那我是否还值得使用TiDB，TiDB在这样的场景低下是否还有用，其实我们也有诸多用户是这样使用TiDB的，他已经有一个综合的数据平台，原来是说我的应用层对接我的离线层，那离线层可能是一个Hadoop，或者是说一个企业的数仓，他已经有了完整的数据架构，完整的数据流转的一些控制，那我是否还是需要使用TiDB？那么有些用户的答案是说他觉得TiDB，对此还是有很大的帮助呢，比如说。有些用户需要使用实时的分析，那么在它的在线业务和离线数据之间，他加设了TiDB，这时候他的就像刚才的data hub那种场景一样做数据集成，而且是实时的数据集成，那你可以把你的在线数据或者说APP service直接应用打上去，或者是说你通过streaming的方式去把其他的变更数据放到TiDB当中去，那么这样子的话，也就是说，我可以把TiDB当作数仓前站的入口，这些入口一旦数据就位之后，我就可以直接提供一些实时的查询服务，一旦数据积攒到一定的量，他需要进行离线分析，或者说他觉得他对这种场景来说，存储成本太高的时候，那么它也可以把旧的过期的数据再 archive到之前的数仓，就以前的数仓的架构，或者说数据湖的架构当中。这个archive的动作会变得非常简单，为什么，因为我们有TiSpark这样的组件，TiSpark本身，Spark本身是一个可以横跨多个数据平台的，你可以认为它是一个federation的 xxxxtion（没听清），比如说是可以达到数据联邦效果的一个查询引擎。使用TiSpark你可以很方便地对接TiDB以及Hadoop，或者说其他可以和Spark兼容的数据目的，你可以使用，比如说select from tidb 某一张表，然后某一些时间段的数据，然后再insert into Hadoop的数据湖，那么这样执行这样的query，你就可以很方便的把数据从TiDB当中转储到你的Hadoop当中。除了刚才说的在数仓的入口，使用TiDB进行数据集成和实时查询之外，有很多用户在出仓的出口当中使用TiDB，那这些用法包含说，比如说把Hadoop或者数仓当中已经计算好的模型需要高速缓存，或者说需要进行数据服务的那些场景，然后从Hadoop当中把数据导出来，然后再转储到TiDB里边。大家可以想一下说，为什么Hadoop本身是一个能承载大量数据，然后能进行批量计算的系统，但他并不适合数据服务，比如说我算好的user tag,进行user tag的检查，类似于这样的服务其实在Hadoop中就并不是十分合适，对于这些用户，他们也许发现TiDB可以进行 Scalable 的存储和计算，或者是说他们觉得TiDB，相对noSQL来说，能更好地承载复杂的业务查询，那对于这些需求来说，他们会把数据从Hadoop当中再转出。缓存出来，然后放到TiDB当中去，然后这些转存方式也可以使用TiSpark，也可以像刚才说的那样，从Hadoop当中或者从你的hive数仓当中select 1张表，然后在插入到TiDB当中，TiSpark也能支持对TiDB的分布式写入。所以哪怕使用了你已经有了现有的数据平台，然后这个数据平台已经有相当多的组件，比如说你要离线层或者你的在线业务层，那么对于这样子的数据平台来说，也有很多用户觉得TiDB仍然可以嵌入到他们的组件架构当中，只要能提供他独特的服务和提供它独特的价值。