一、什么是HTAP
1、OLTP与OLAP
在介绍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数据库正好可以派上用场。
2、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技术架构图分为两层——发动机层和存储层：
橙色的一层是存储层，通常是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计算。
三、DRDS HTAP功能演示
1、跨业务库的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可以完成查询，既保证了用户子系统的独立性，又给实时分析带来了极大的便利。
2、Streaming Join
再看一下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同样也是。DRDS HTAP适用AP类场景(TP这里先忽略类场景)主要有两个:
- 对延迟要求不是特别高的低并发应用，特别是跨多个业务库、跨多个表进行实时分析的场景；
- 流式基于时间JOIN例如，事实表的流动场景Join或者维表和事实表的流动Join也适合用DRDS HTAP来使用。
但是OLAP查询场景种类繁多，查询场景也很多DRDS HTAP例如，快速检索普通全文是不合适的，AdHoc等待查询场景。
目前，DRDS HTAP在公共云中，用户已经以分析型只读实例开放。DRDS HTAP为了支持更复杂的在线场景和分析场景，技术层将继续优化。
讲师介绍
阿里数据库事业部技术专家梁成辉(城璧)TDDL、云产品分布式关系数据库服务DRDS技术负责人。多次担任数据层稳定性负责人，保障双十一TDDL & DRDS目前，稳定性主要集中在DRDS HTAP技术研发致力于提供云OLTP与OLAP综合解决方案。
版权声明
本文仅代表作者观点，不代表本站立场。
本文系作者授权发表，未经许可，不得转载。
