在介绍HTAP概念之前，请允许我先介绍一下另外两个概念——OLTP和OLAP，这两者在数据库领域是很重要的应用场景的划分。

OLTP数据库承载的应用通常是高并发、高吞吐、高可用的，应用SQL很简单(大部分都是点查点写)，但这种应用对数据的实时性、一致性要求很高，对查询时间延迟很敏感，一般要求是几毫秒以内。

相反地，OLAP数据库承载的应用的SQL通常会比较复杂（多含Join、GroupBy或SubQuery等复杂语法），所涉及到都是大范围的数据读取，数据量可能是百万千万，甚至亿，所以这种SQL查询延时比较大，但应用并发不高。

由于OLTP与OLAP这两类数据库所应对的场景的巨大差异，因此两者在查询优化策略、数据组织方式与物理存储结构都会不一样。在企业内部，OLTP与OLAP一般都是独立的两套系统。所以，业务上常见的做法，就是配置一条数据同步链路，把OLTP数据库每天产生新数据同步到OLAP数据库，以方便进行做统计分析的工作。

举个例子，我们在盒马鲜生用手机APP做商品查询、下订单和付款，这就是OLTP的业务。盒马鲜生将MySQL产生的数据通过阿里集团数据同步工具（精卫同步、云梯等）导入到ODPS平台（阿里集团Hadoop平台），进行每天的库存结算对账、各渠道销售额统计等，这都是业务里的OLAP业务。

业务上将OLTP数据复制一份并导入到给OLAP，达到OLTP与OLAP相互隔离的效果，这个方案很通用，但这有一个代价--应用的开发人员要额外负责承担这些数据同步链路稳定性的保障性工作，那必然会带来其它很多不可忽视的问题。

首当其冲的是数据质量的下降以及运维成本的上升。业务以后每加一个新的数据库或新增一张表，表就要新配一条数据的同步链路，像盒马已经有几十个业务同步链路、几百张表，这样数据同步链路的维护成本很高。

比如，某个需求需要给某个表加个列、改列名等DDL操作，同步链路的工作都需要暂时，等到完成了才能重新开始。这中间的过程容易遗漏导致故障。

一般来说，根据数据量的大小，同步系统会有分钟级、小时级甚至天级的时间延迟。因此，同步后的数据的时效性是比较差的。

同步链路的上下游系统一般众多，如果中间某一个系统因为程序Bug导致数据丢失或不可用，就可能会直接产生严重的数据故障。这对业务的稳定性带来很大的风险。

此外，同步链路上下游各系统不一定兼容MySQL协议，这样开发人员还可能要修改业务代码适配这类系统，从而带来额外的开发成本。

为了解决这一系列的问题，HTAP数据库就刚好可以派上用场。

HTAP数据库简单理解就是OLAP业务和OLTP业务都统一地在一套数据库系统里内完成。HTAP数据库相对于传统TP数据库有TP所不具备的计算引擎，可以加快SQL执行效率，而HTAP数据库基于于传统AP数据库，又有AP所不具备的事务引擎，能做到所写即可见，数据具有高时效性。

HTAP型数据库可以具备哪些技术点呢？以下是我们对它的几点总结：

• TP/AP数据时效性：简单说，就是业务的TP查询和AP查询看到总是“同一份数据”，不会有明显的延迟。目前成熟的MySQL主备同步机制能保证数据延迟达到毫秒级或亚秒级，用户几乎不会察觉，并且同步准确性非常高，这比依赖于异步的外部数据同步系统的可靠性高很多；

• TP/AP 稳定性与高可用：TP与AP两者相互隔离,保证各自的稳定可靠是HTAP的基本要求。要做到这一点,可以基于独立部署进行物理隔离，也可以基于链路隔离以及备库自动容灾与切换方案进行隔离；

• 跨业务库的关联查询：跨业务库关联分析是HTAP常见场景，这要求HTAP查询引擎能基于MySQL协议对接不同的类MySQL存储；

• 复杂SQL处理能力：除了要有强大的优化器之外，MPP计算引擎和Streaming的计算引擎等加速SQL执行的手段也必须要有的。

举个HTAP的应用例子。双11主互动及合伙人集能量的抢红包活动，活动在设计时已经涉及到10多个业务的数据库，活动参与的任务有亿万红包金额，所以这个活动的业务逻辑是很复杂的。

在这样复杂的场景中，业务如何做到快速的业务监控以及资损防控是整个活动最大的技术挑战。业务开发在进行方案调研的时候发现DRDS HTAP这个产品，除了具有承载普通的OLTP的能力外，还具有跨多个数据库做实时关联分析的能力，非常符合业务的场景。

因此，开发同学直接将业务的监控系统直接基于DRDS HTAP来搭建，最后的结果超出他们期望。

DRDS HTAP不但帮助业务监控平台成功避免了10+起的资损故障的出现，还具备了在1分钟以内完成多个业务库实时对账的能力，这相比于以前的离线方案，要将数据要上传到数据仓库里，像对账这种操作需要在T+1、T+2的时间才能完成。

那么HTAP是如何达到这种效果的呢？下面一起来看一下DRDS HTAP的架构和关键技术。

下图是DRDS HTAP的技术架构图，架构图分为两层——引擎层和存储层：

橙色的一层是存储层，这层一般都是DRDS HTAP分库分表的MySQL实例（云上就是RDS实例），通常每一个物理分库都会配一主多备保证高可用。灰色的一层是引擎层, 引擎层使用集群提供高可用，集群的每一个节点都DRDS的无状态的Server节点。Server里包含了用于处理MySQL协议的网络模块、查询优化器以及一整套TP引擎对应的执行算子。

通常业务OLTP类的SQL在Server的TP引擎内完成全部执行。但如果业务的SQL是OLAP类的复杂SQL，引擎层会将SQL对应的物理查询计划发到右侧Fireworks引擎进行计算。

Fireworks是一个基于Spark 的具有DAG能力并行执行引擎，它能够进行MPP计算及Streaming计算。Fireworks内部的每一个Worker会主动连用户MySQL的备库获取数据并进行计算。

DRDS HTAP 的Fireworks引擎的细节如下图所示：

左右两图是一条SQL分别在TP引擎的对比图。在TP引擎中，SQL采用单机单线程执行策略。但是，在Fireworks引擎中，SQL的物理查询计划会被拆分为多个子任务，然后分发到多台Worker机器实施并行计算。

值得提及是，相比于开源Spark的Worker只能下推PROJECT/SELECT两种算子，Fireworks的Worker接收到的物理执行计划是被DRDS优化器进行过优化的。

因此，一些常见的PROJECT/SELECT/JOIN（分库内的JOIN）/AGGREATION（分库内的AGG）/SORT等算子操作，都会被DRDS优化器尽可能下推到物理存储，这样可以避免大量的中间数据的网络开销以及本地计算开销，从而使MPP引擎执行得到加速。

对于有一些需要跨多个分库分表读取数据才能完成的查询， Worker机器都会采用多线程并行扫描单个分片数据，以避免查询时间大量耗在网络IO上 。

再说一下DRDS HTAP Streaming的引擎，DRDS HTAP的Streaming引擎是在Spark Streaming的基础上开发的。但我们在将Spark Streaming引入DRDS HTAP体系过程中，对Streaming的稳定性与可靠性做了很多优化工作。

例如，DRDS HTAP引入了RocksDB作为Streaming的State Store，并实现流计算任务中间关态的自动容灾与恢复。又如，DRDS HTAP基于MySQL的Schema的时间戳列实现输入流。

这样用户在DRDS HTAP可以使用标准的Streaming SQL语法完成诸如 Streaming-Streaming JOIN常见Streaming计算操作。业务开发也不再需要像使用开源的Streaming引擎(如Flink)那样，需要自己配置复杂数据同步链路，从而能给用户使用带来极大的方便。

在HTAP里保证业务TP和AP查询稳定及高可用是非常重要的，DRDS为达到这个目标，采用了查询链路隔离的技术方案。下图是链路隔离方案的架构，分为引擎层和存储层：

在存储层默认用MySQL的一主多备来实现。像TP引擎会默认只访问主库，这样数据可以保持是保持数据一致性。而像Fireworks引擎默认只允许访问应用的备库，这样业务在存储层AP流量和TP是天然的物理隔离，保证相互不受干扰。

由于备库承载的是OLAP类的SQL, SQL通常有相当的复杂性，备库被打垮是高概率事件，所以，DRDS HTAP能在多个备库之间实施自动的容灾和切换，这样就算一个备库宕机了，另一个备库也可以继续提供服务，从而高可用。

在引擎层，DRDS通常建议业务将OLTP流量用DRDS主实例来承载，业务的OLAP流量用DRDS只读实例来承载，这样业务的AP和TP业务就能在引擎上也能实现物理隔离，从而保证各自的稳定性和高可用。

接下来看一下DRDS HTAP的查询优化器，下图是查询优化器的架构，优化策略是以RBO为主，CBO为辅的策略。优化过程可以分为三个阶段：

• PreOptimizer，Sql的很多Rewrite操作（例如， SubQuery Unnesting/Constant Folding等）会在这个阶段完成，产生出一份经过简单SQL改写的逻辑计划；

• Optimizer，这个阶段优化器会进行很多常见算子优化（例如，Predicate Inference /Operator Pushdown/Column Pruning/Join Cluster /Join Reorder等），然后再产生出一份经过优化后的逻辑计划；

• PostOptimizer，这个阶段DRDS HTAP作为分布式查询引擎所特有的阶段。这个阶段中，优化器会基于SQL的查询条件进行分库分表的Sharding计算，然后再针对特定分片重做类似上一阶段的Partition-aware的优化操作。

原则上，优化器会尽可能地算子下推到物理存储，这样可以大大减少引擎成本的执行压力以及中间数据的网络传输代价，从而提升执行效率。

对于一些诸如必须要跨多个物理分片的或跨多个逻辑库才完成计算的算子（如跨库JOIN）, 它们没法下推物理存储的，优化器会自动采用MPP的执行策略，直接将物理计划发给Fireworks引擎做MPP计算。

在电商场景，业务系统里为了降低耦合性， 通常被会拆分成很多子系统。下图就是模拟电商场景分别对交易库、商品库、用户库进行关联查询的示意图，各个子系统会使用单独MySQL实例(即RDS实例)进行存储：

一旦业务要搞营销活动，如双11大促、发红包等，应用的逻辑必然会涉及到多个数据库实例的读写，由于MySQL本身是不能支持跨实例级别的关联聚合查询的，这会对业务后台的数据分析、监控、对账等场景会带来很大的麻烦，而使用DRDS HTAP则可以解决这个问题。

DRDS对于每一个RDS数据库会统一抽象成逻辑库的概念，简单理解，就是会为每个库生成一份配置信息和元数据，在整个过程中用户本身并不需要做任何数据导入或数据同步的操作。

基于这一层逻辑库的抽象，普通用户可以如同在单机MySQL一般地随意执行跨DRDS数据库的关联分析查询，并且不需要对业务的数据库任何其它改造，带来极大的使用便利。

业务将多个RDS的数据库（不做分库分表的拆分）接入DRDS后，当其中某个业务数据库因业务发展了，单机RDS无法承载并需要做分库分表时，那DRDS的所有拆分的细节会隐藏在一个逻辑库之下。

这一过程本身应用是透明的，因此，业务后台的分析应用的SQL也不需要做改造， 从而避免了大量的SQL改造成本。

为了演示方便我已经提前将交易库、用户库、商品库的表信息建好。其中交易库和用户库分别在RDS A上，商品库在RDS B上。右边的SQL是一条跨三个业务库做JOIN SQL。

首先我分别登到RDS A和 RDS B的信息，可以看到上面数据库的信息。RDS A有交易库和用户库，RDS B有商品库。再通过命令登录到DRDS里，可以看到三个库都在同一个地方。最后会出现一个结果，这就是我要演示的跨多个业务库进行复杂查询的场景。

在实际场景中SQL会更为复杂，比如说盒马聚合查询的SQL，如果要用以前那种方案，业务肯定要导到统一的数据仓库才能执行，现在在DRDS HTAP上只冉一条跨Schema的SQL查询就可以完成，这样在保证用户子系统独立性的同时给实时分析带来了很大便利。

再看一下Streaming引擎的功能演示，这里要演示的场景是大宽表。很多应用在数据库表设计的时候会遵守一些标准的设计范式。

比如，用户购买下单的行为会将用户的详情、商品的详情与用户下单的行为用三张不同的表存储，用户后台做数据分析的时候会通过JOIN打成大宽表，这样做方便做上钻分析或下钻分析。

我要模拟的场景是怎么使用流JOIN来打大宽表，Streaming很适用用于跟时间强相关的JOIN查询。例如，每天都要查一下最近一天的交易量、订单量的新增数目等。整个演示场景先是假设T1跟T2表是已经存在的表，再额外建一张结果表，结果表是可以用来固化做流式业务的结果。

我开始模拟一个普通用户在DRDS HTAP上使用Streaming JOIN。首先会在CERATE STREAM上建设T1和T2，最后使用JOIN建T1 JION和T2 Stream。最后将流结果写入结果表中。

看一下SQL的具体操作，先使用命令执行建了两个流T1和T2，再建一个T1和T2 JOIN的流。现在模拟向T1、T2引入数据，你会发现有JOIN的结果出来。这样的好处在于这种结果突然固化业务做查询可以非常快速，因为不需要再做中间的计算。

没有数据库能适用所有的业务场景，DRDS HTAP同样也是。DRDS HTAP适用AP类场景（TP类场景这里先忽略）主要有两个：

• 那些低并发且对时延要求不是特别高的应用，特别有跨多个业务库、跨多个表进行实时分析的场景；

• 基于时间做流式JOIN的场景，例如事实表的流Join或者维表和事实表的流Join也适合用DRDS HTAP来使用。

但是OLAP的查询场景是多种多样的，还有很多查询场景对于DRDS HTAP还不太适合， 比如，常见的全文快速检索、AdHoc等查询场景。

目前，DRDS HTAP在公有云已经以分析型只读实例的方式向用户开放。但DRDS HTAP后续会在技术层继续不断优化，以支持更多更复杂的在线场景与分析场景。