图片有惊喜
1.HTAP数据库背景及现状1.1起源
大型实时分析应用的逐渐流行（实时库存/定价、欺诈检测，风险分析，物联网等）；
这些系统需要一个分布式的数据管理系统，要求能处理高并发的TP请求，同时支持对近期的数据进行分析；
有些应用甚至会在TP请求中进行AP操作；
Gartner：即有事务又支持分析的系统叫HTAP；
实时分析：指的是实时交易过程中的分析需求，不是数据时效性上的实时。
1.2方案1：一套系统同时支持OLTP和OLAP
传统的DBMS可以在一套系统上支持TP和AP，但对这两种业务场景都不高效；
基于内存的行存（VoltDB,Hekaton,MemSQL,Silo）和列存（MonetDB,Vertica,BLU,SAPHANA）系统，这些系统开始只是为一个场景专门设计的，后来为了支持HTAP增量了另一场景的支持。
1.2.1底层数据分开存储
SAPHANA和Oracle’sTimesTen最初是为OLAP专门设计的，同时也支持ACID事务操作；不过事务的数据时以行存方式支持的，而分析操作是通过列存支持的；
MemSQL最初是为in-memoryOLTP设计的，后来也支持分析。对于TP数据是以行存方式存在内存中的，当数据需要写到磁盘中时，会转换成列存；
IBMdashDB也是从传统的行存向HTAP演进的系统。通过行列混合的方式来分别支持TP和AP；
HyPer是从一开始就为HTAP设计的，最初使用行存来同时支持TP和AP，不过现在也支持通过列存方式来更好的支持AP场景。
1.2.2底层用一种方式存储数据
H2TAP，学术项目，以行存的方式同时支持TP和AP；
Hive，SQL-on-hadoop的解决方案之一，AP系统，在0.13版本开始通过ORCFile支持事务，但主要的应用场景是维度表更新以及实时流数据摄取；
Impala+kudu：支持SQL分析及数据的更新和删除。这类系统跟传统DBMS面临同样的问题，没办法同时为AP和TP进行优化。对于采用列存的系统，需要通过批量的方式来提高事务的吞吐能力；对于采用行存的系统，无法实现最佳的分析效果。
1.3方案2：两套系统来组合来支持OLTP和OLAP1.3.1解耦AP和TP的底层存储现状
需要用户的应用程序自己来协调AP和TP系统的使用；
数据在两个系统之间是通过ETL方式同步的；
这类方案在目前的大数据系统中非常常见，通常使用kv系统（如cassandra）来承载TP负载，然后将数据转换成ParquetorORC文件存储到HDFS中，再使用SQL-on-hadoop方案进行数据分析。
1.3.2AP和TP共享底层存储这类系统通常是使用Spark之类的系统，在原有数据上支持大规模分析的场景。由于数据只有一份，因此AP分析的数据是实时数据。
SAPHANAVora：TP业务负载有vora直接支撑，而分析场景则通过Spark-SQL来支持；
SnappyData：使用GemFire来承载TP业务，通过Spark生态来支持AP业务；
HBase和Cassandra等kv系统被广泛应用在需要实时更新的场景，而对这些数据的分析场景在通过组合SQL-on-Hadoop的解决方案来实现。TP和AP系统访问的是同一份数据，这需要开发一些额外的扩展，以使得AP引擎能直接读取TP存储中的数据，比如SparkHBaseconnector，SparkCassandraconnector等。通过connector来进行AP分析通常非常慢；
另外一些SQL-on-hadoop系统，使用HBase作为支持快速更新的存储引擎，如：HIVE，Impala,IBMBigSQL,andActianVectorH。数据的处理是通过HBase的处理引擎来实现的；
SpliceMachine、Phoenix则是在HBase之上构建了SQL引擎；
基于HBase的AP系统，在处理AP任务时都比较慢，因为在HBase上执行Scan非常慢。HBase适合快速更新和点查的场景；
Wildre：IBM最近开发的一套HTAP系统，使用列存方式来同时支持AP和TP，使用的是Parquet格式。Wildre可以立即分析最近提交的更新，同时支持使用Spark生态来执行大规模并行分析任务，提交给SparkSQL的请求会被尽可能的下沉到Wildre引擎来进行数据处理。
1.4.现状总结
目前没有一个系统支持true-HTAP；
大多数系统已经分别支持了AP请求和TP请求的处理，但是没有系统支持在TP中执行AP的场景；
要支持真正的HTAP，需要支持在同一个请求中既有TP又有AP的场景。
目前大多数系统需要组合各种解决方案来达到HTAP场景的需求，这对用户部署和维护系统带来挑战；
目前大多数TP系统为了加速TP的更新和点查，将索引全部放在了内存中，但是对于更大规模数据的场景，索引全部在内存中会导致TP系统变慢，应当考虑一种仅保留部分索引在内存中的方案，以提高常用数据的访问性能；
为AP场景设计的存储引擎，通常使用对象存储或者共享文件系统来存储数据。这些存储格式主要是为scan场景进行优化，无法提供高效的点查和更新能力。目前这还是一个未解决的难题。
1.5.设计HTAP系统要做的一些决策
Queryprocessingandingestionengines（数据分析和数据摄取引擎）
Storageoptions（存储方式：一套存储还是混合存储）
Dataorganization（数据组织格式：行存还是列存）
Transactionalsemantics（事务语义）
RecencyofdatabeingreadbyOLAP
Indexingsupport（索引支持）
2.HTAP类数据库分析2.1TiDB2.1.1TiSpark所属分类
两套系统来组合来支持OLTP和OLAP（采用Spark生态）
AP和TP共享底层存储
TiSpark是将SparkSQL直接运行在TiDB存储引擎TiKV上的OLAP解决方案
TiSpark深度整合了SparkCatalyst引擎,可以对计算提供精确的控制，使Spark能够高效的读取TiKV中的数据，提供索引支持以实现高速的点查
通过多种计算下推减少SparkSQL需要处理的数据大小，以加速查询；利用TiDB的内建的统计信息选择更优的查询计划
2.1.2TiFlash所属分类
底层数据分开存储，TP采用行存，AP采用列存
AP存储在一定程度上属于TP的一个副本，在比较高的层面上来看，可以认为是一套存储同时支持行列
两套系统来组合来支持OLTP和OLAP，TP通过原生的TiDB来支持SQL和事务；AP则通过TiFlash（基于clickhouse开发的向量化分析引擎）来实现
通过动态的SQL路由，TiDB在更高的层面隐藏了AP和TP引擎
技术实现
TiFlash基于列存和向量化分析引擎（Clickhouse）实现；
TiFlash作为TiDB的另外一个存储层，通过raftlearner从TiDB复制数据，并保证数据的事务性；
TiFlash目前不支持SQL直接写数据，因此其角色目前不能成为leader或者follower；
TiFlash节点如果发生故障，需要从TP集群重新同步数据；
TiFlash作为TiDB的扩展，属于TiDB集群的一部分；
通过全局时间戳来保证用户从TiFlash中读到的是最新的数据；
通过LSM-Tree来解决列存的更新带来的写放大问题；同时利用其局部有序性来解决AP场景对scan的需求；
可以通过动态增减不同类型的节点来增减，TP或AP能力；
TP节点和AP节点在系统层面有不同的标签，当启发式算法任务用户下发的SQL是一个AP运算时，会将请求路由到AP节点上执行。在一定程度上隐藏了AP和TP的具体角色分配；
一条join语句的两部分数，一份数据需要全表扫描、另一份可以利用索引，则可以分别将这两个子查询调度到不同类型的节点上执行，一部分利用TiFlash的scan能力、一部分利用TiKV的点查能力。
后续计划
支持SQL直接更新TiFlash中的数据
TiFlash支持MPP，从而可以将TiDB或TiSpark的一部分计算下推到TiFlash执行
重新设计TiFlash的存储引擎，从而将性能提升2倍（目前TiSpark+TiFlash的性能，与Spark+Parquet的性能差不多）
TiKV对应yugabyte的TabletServer（即DocDB），定位和实现框架几乎差别不大，都是在实现一个支持事务的分布式kv。TiKV是一个单独的项目，更解耦（意味着性能要差）。
都是提供RPC接口
都是Raft
都是基于rocksdb
2.2MemSQL技术细节所属分类
一套系统同时支持OLTP和OLAP
底层数据分开存储
技术实现
