课程名称：课程版本（101/201/301）+ 课程名称
学习时长：60min
课程收获：了解HTAP概念，TiDB的发展史，TiDB的架构及周边工具，TiDB的技术特性
课程内容：
课程：1.2 Why HTAP Matters（HTAP 数据库简介）、1.3、1.4、1.5
笔记：
1.2 什么是HTAP
背景：由于实时分析和HTAP的需求不断提升，HTAP是由Gartner（市场分析调研机构）发明的词汇
TP特性：
1)行存储，实时更新
2)高并发和高一致性，只触发一小部分行
3)存储当前数据
AP特性：
1)列存储，批量更新
2)低并发，每次查询会涉及大量数据
3)处理的是历史数据
由于AP与TP不同的场景，所以一般公司会将在线TP交易的数据存储在OLTP的数据库中，每隔一段时间通过ETL转移到数仓或者
数据湖当中，经过整理后转存到Data Sering数据库或者在线数据库中，缺点：数据平台非常复杂，数据新鲜度的丢失
为什么需要HTAP：
1)现在TP/AP业务的界线比较模糊
为什么HTAP可以帮助到你：
1)简化架构
2)降低运维成本
3)实时查询和实时分析
4)可以促进业务的敏捷性
HTAP数据库的难点：
1)可扩展性：构建一个分布式的AP数据库很简单，但是TP数据库就很难
2)同时支持TP/AP业务：需要支持两种存储格式（行存、列存）、避免不同业务的干扰
3)无缝集成：数据实时同步，能查询到新鲜数据
HTAP如何帮助你：
1)TiDB特性：
a)一个可扩展数据库
b)为了严苛的交易型场景设计
c)已经被很多金融场景严重
d)同时具备分析引擎
e)天然的数据中枢/实时分析的平台
2)TiDB 4.0 HTAP架构的新特点
a)加入了可以实时更新的列存引擎
b)同时具备行存和列存引擎的可扩展性；行存和列存引擎可以使用不同的机器资源，互相之间运转没有干扰；行存与列存之间的复制可以达到一致性的数据复制
c)列存引擎是矢量化引擎，具备良好的性能
d)行和列格式之间的智能选择
案例：
1)TP+AP的一站式服务
拥有一个在线业务，将数据存入在线数据库，如果需要将TP的数据进行分析，将会导入分析型数据库，这时会需要两套系统，需要将TP的数据复制到分析型数据库，这中间会有延迟，这时分析到的数据已经是旧的数据；假设使用TiDB，在线业务使用行存进行承载，分析型业务用列存承载，这时使用一套数据库替换原来的两套架构，而且分析的是最新鲜的数据。
2)实时数仓/数据中枢
用户可以在前端拥有不同的数据孤岛，每条业务线可能都拥有自己的数据库，这些数据库承载了这些在线业务，在线业务在数据变更的同时可以通过cdc或者变更日志的方式向TiDB输送当前的数据变化，由于TiDB拥有TP的属性，可以很方便的承载这些变更而且实时地反映到数据状态当中，由于拥有列存设计，在承载业务变更的同时可以进行分析型业务。
3)综合数据平台
例如用户需要实时的数据分析，在离线数据和在线业务中间架设了TiDB提供实时的分析服务，当数据量较大或者存储成本太高时，可以将数据通过TiSpark转存到离线数据平台，既可以作为数仓的入口也可以作为数仓的出口。
1.3 TiDB发展简史
1)早期的TiDB
自从 v1.0.0 GA 开始，TiDB 做到了：可以从计算和存储两个层面的无限扩展，兼容了 MySQL 的语法和协议，对应用透明的分片策略，强一致的真分布式事务。
早期的TiDB集群架构分为TiDB、TiKV、PD三个组件，TiDB是一个无状态的sql引擎，承担计算业务，可以多实例启动，TiKV是分布式KV存储引擎，使用Raft算法来进行副本之间的复制来保证高可用，PD主管元数据的存储以及TiKV中数据的调度。
具备良好的中台能力，用户可以通过同步工具Syncer向TiDB进行数据汇总，由于Coprocessor协处理器的存在，汇总的数据可以并行的在TiKV中进行聚合生成报表。具体表现在：兼容MySQL协议，可以方便的从各类MySQL数据库中同步数据；不需要数据分片，对应用透明；实时的数据汇总，可以将备机和中台合二为一。
使用中发现的问题：TP场景下有一些小问题但问题不大，AP场景下复杂的查询太慢、TiDB经常OOM、不能和大数据平台整合。
解决方案：将TiDB和TiKV串起来做成类似MPP引擎，但是需要很长的时间并且风险很高；拥抱开源寻求成熟的分布式计算框架。
2)融入TiSpark的TiDB
TiSpark可以将单节点的TiDB计算能力扩展为多节点的并行计算。TiSpark提供了一个分布式的计算框架，无缝的接入了大数据生态，脚本、python、R语言都可以轻松的操作TiDB集群。缺点：并发度低、消耗大量的计算资源。用户仍然需要一个高并发、中等规模的AP查询，TiDB优势：TiDB处理复杂查询消耗的资源更少，维护TiDB比维护Spark简单很多。
与此同时，围绕TiDB做了各方面的优化：优化器从简单的优化器优化成RBO+CBO的优化器以及将来支持的Cascades优化器；执行器从火山模型优化到批量执行再优化到向量执行以及更好的并发控制和一些新特性，例如分区表，index merge等。
3)融入TiFlash的TiDB
仍有2个核心问题没有解决：a)行存不适合做分析；b)没有资源的隔离
TiFlash通过Raft Learner向列存引擎同步数据，优点：代价极低，读取时通过Raft index以及MVCC实现强一致性读，通过打标签的方式实现物理隔离，这样AP和TP的负载就不会互相影响。
TiFlash作为只读节点可以接收从TiSpark和TiDB的读请求，通过Raft Learner将写请求同步过来。
到今天为止，TiDB可以称为真正的HTAP，同时拥有行存和列存，数据自动的进行行列转换，中间不需要其他工具进行转存，当系统进行TP业务时也可以进行报表查询。
1.4 TiDB平台框架和全景图
1)TiDB集群架构
TiDB集群是计算存储分离的架构，TiKV和TiFlash是存储层，TiDB和TiSpark是计算层，分别处理MySQL和Spark SQL的请求，PD与Spark组件及TiDB均有交互，PD节点负责存储元数据、分配TSO数据定位功能。
TiDB是无状态的SQL层，客户端可以任意连接一个TiDB实例；支持MySQL协议，功能完善，有基于成本的优化器，支持二级索引、在线DDL。
TiKV是行式存储，适合事务处理；TiFlash是列式存储，适合分析处理；数据根据范围切分，同个范围的数据有多个副本，副本之间通过Raft共识协议同步，保证强一致以及高可用，TiFlash上的副本固定为Raft Learner，使得对TiKV上的事务处理影响最小化，通过TiDB优化器的选择可以做到事务类的处理查询走TiKV，分析类查询走TiFlash，从而最大程度的隔离OLTP和OLAP。
PD是TiDB集群的智能大脑，部署三副本、支持etcd同步数据、保证高可用，主要负责几件事：a)存储集群的元数据，例如region的位置处于哪些TiKV上、raft leader是哪个；b)调度和负载均衡region，例如将region调度到另外几个TiKV上、或者将raft leader迁移给另外的follower；c)负责分配全局单调递增的事务时间戳。
TiSpark是将Spark SQL直接运行在TiKV上的OLAP解决方案。从数据集群的角度看，TiSpark+TiDB可以让用户无需进行脆弱、难以维护的ETL，直接在同一平台进行事务和分析两种工作，简化了系统架构和运维。
2)TiDB生态工具
a)TiUP
TiUP是TiDB 4.0新引入的组件管理工具，提供单机部署、集群部署、组件下载、版本控制、分发功能。
b)Lightning，Dumpling
Lightning是TiDB的全量导入工具，用于读取从mydumper或CSV数据源导出的SQL dump。
Dumpling是TiDB的全量导出工具，可选的导出格式有SQL或者CSV。
c)Backup&Restore(BR)
Fast Backup&Restore简称BR，BR是一个对TiDB进行分布式备份和恢复的工具，备份的粒度可以是全量或者单库单表，它直接从TiKV存储层入手，将备份或恢复命令下发到各个TiKV节点执行，将备份恢复带来的cpu、io均匀分布在各个TiKV上，它的备份恢复性能上可以随着TiKV节点数进行水平扩展
d)Change data capture(CDC)
TiCDC 是一款通过拉取 TiKV 变更日志实现的 TiDB 增量数据同步工具，具有秒级上下游数据同步、将数据还原到与上游任意 TSO 一致状态的能力，同时提供开放数据协议 (TiCDC Open Protocol)，能够与多种异构生态系统对接，支持其他系统订阅数据变更，满足用户在大数据场景中对各类数据的应用和分析需求。
e)DM(Data Migration)
DM是将 MySQL/MariaDB 数据迁移到 TiDB 的工具，支持全量数据和增量数据的迁移。
f)TiDB Operator
云上的TiDB部署工具。
g)Dashboard
Dashboard用于监控数据诊断。
1.5 TiDB技术特性
1)TiDB的基础架构及拓展架构
TiDB基础架构分为3个基础组件：无状态的SQL计算引擎(TiDB)、分布式KV存储引擎(TiKV)、调度引擎(PD)。
a)TiDB用于解析应用层发起的连接以及SQL解析功能，在应用层与TiDB之间加一层proxy，一般是硬件F5或者软负载HAProxy。
b)TiKV通过raft协议存储3个副本。
c)PD主要有2个功能：元数据的信息管理，全局事务管理中提供TSO功能(基于timestamp时序分配)
加入TiSpark的TiDB架构，在基础架构上加入TiSpark(分布式的并行计算引擎)，由多个worker组成一个Spark集群，用于解决复杂的查询。
加入TiFlash的TiDB架构(HTAP)，TiKV是通过raft构建强一致多副本的协议，TiFlash也是通过raft构建另外一个副本，将行存转换成列存，对于应用而言仍是通过标准的SQL，经过CBO优化引擎来判断是查TiKV引擎还是TiFlash引擎。
2)TiDB的重要特性
a)可扩展性
在线扩缩容，传统的数据库一般是share-disk或者share-everything架构，类似oracle双机和rac解决方案，这时候会有单点限制，磁盘或内部网络会成为瓶颈，扩容时需要先上升级硬件来解决；分库分表的解决方案，扩容时非常麻烦，几乎无法实现缩容；TiDB是share-nothing架构，无论是计算引擎还是存储引擎，理论上可以做到无限扩容，计算引擎扩展只需要准备好对应资源，将进程起起来加入到前端proxy负载当中，存储引擎扩展时需要一个数据rebalance的过程，由TiDB内部完成，PD自动调动等。
b)高可用
share-nothing架构；基于raft的复制协议，不存在主从数据复制延迟的情况；故障自恢复，由于是使用raft多副本强一致协议，当出现故障时，PD会自动感知，对于业务来说几乎没有影响；基于raft和share-nothing架构，可以做到两地三中心业务多活架构。
c)分布式事务
由数据库保证分布式事物的ACID特性；对于业务而言不需要指定分片键；支持同一个集群跨多个数据中心的查询。
d)实时的HTAP架构
由于行列共存的架构来提供实时的HTAP功能，基于raft的复制协议，额外复制出一个副本转换成列存的形式存入TiFlash存储引擎，通过CBO优化器来判断从行存引擎还是列存引擎取数分析，虽然列存可能会有延迟，当查询进入列存需要提供数据时，通过内部机制去raft主节点上做延迟请求，以此保证返回给上层强一致性的数据；不需要ETL过程，保证实时的数据分析。
3)TiDB 4.0的改进
a)新的安装部署工具TiUP
支持在线部署（建议测试环境使用）和离线部署（将离线部署包下载上传到生产环境的服务器上），将硬件资源检测步骤去除。
b)对大事务的支持
3.0版本事务限制：事务大小不能超过100M，单行数据不能超过6M，事务转换成key-value模型不能超过30w个key
4.0版本事务限制：事务大小不能超过10G，单行数据不能超过6M
c)临时表
通过oom-use-tmp-storage参数控制，当内存使用超过32G，将数据转储到磁盘上，以此支持大sql的查询。
d)Dashboard
可视化的运维工具，可以查看集群的状态，可以快速识别热点，慢sql的分析排序，提供性能分析诊断功能。
e)调度功能
基于k8s实现的调度功能，4.0优化了PD调度算法和策略，默认3副本，当感知某些数据存在很明显的读请求调度时，可以快速增加副本，通过follow read将集群中的热点读请求打散，实现自动弹性调度功能，当热点峰值流量过去后，将增加的副本删除，结合k8s对于容器编排能力将对应的资源释放。
学习过程中遇到的问题或延伸思考：
- 问题 1：raft协议
- 问题 2：列存的优点