1。什么是HTAP一、OLTP和OLAP在介绍HTAP的概念之前，请允许我先介绍另外两个概念——OLTP和OLAP，它们是数据库领域中非常重要的应用场景划分。OLTP数据库承载的应用通常是高并发、高吞吐、高可用的。SQL的应用非常简单（大部分都是枚举和写入），但是这种应用对数据的实时性和一致性要求很高。时延非常敏感，一般要求在几毫秒以内。相反，OLAP数据库承载的应用的SQL通常比较复杂（包括Join、GroupBy或SubQuery等复杂语法），涉及的数据读取范围大，数据量可能上千万级，甚至数十亿，所以这种SQL查询延迟比较大，但是应用并发度不高。由于应用场景的巨大差异，OLTP和OLAP两种类型的数据库在查询优化策略、数据组织方式和物理存储结构上都有不同。在一个企业内部，OLTP和OLAP一般是两个独立的系统。因此，业务中的一种常见做法是配置一条数据同步链路，每天将OLTP数据库产生的新数据同步到OLAP数据库中，以方便统计分析工作。例如，在盒马鲜生，我们使用移动应用程序查询产品、下单和付款。这是OLTP的业务。盒马鲜生通过阿里巴巴集团的数据同步工具（经纬同步、云梯等）将MySQL产生的数据导入到ODPS平台（阿里集团的Hadoop平台），进行日常的库存结算和对账、各类销售统计渠道等业务中的OLAP业务。业务上，将OLTP的数据拷贝出来导入到OLAP中，达到OLTP和OLAP相互隔离的效果。这种方案很常见，但也是有代价的——应用开发者额外负责这些数据同步链路的稳定性Guaranteedjobs，必然会带来很多其他不容忽视的问题。首当其冲的就是数据质量的下降和运维成本的增加。业务后每次新增数据库或新增表时，表都需要配备新的数据同步链路。比如盒马，已经有几十个业务同步链路，上百张表。维护成本高。比如某一个需求，需要对某张表增加一列，更改列名等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多个业务数据库，活动涉及的任务有上亿个红包，所以本次活动的业务逻辑非常复杂。在如此复杂的场景下，如何实现快速的业务监控和资产流失防控是整个活动最大的技术挑战。在业务开发调研中发现DRDSHTAP不仅具备承载普通OLTP的能力，还具备跨多个数据库进行实时关联分析的能力，非常适合业务场景。因此，开发同学直接基于DRDSHTAP搭建了业务监控系统，最终的结果超出了他们的预期。DRDSHTAP不仅帮助业务监控平台成功避免了10+次资金流失故障，还具备1分钟内完成多个业务数据库实时对账的能力。与之前的离线方案相比，数据要上传到数据仓库，需要在T+1或T+2时间内完成对账等操作。那么HTAP是如何实现这个效果的呢？让我们看一下DRDSHTAP的架构和关键技术。2.DRDSHTAP架构及关键技术下图是DRDSHTAP的技术架构图。架构图分为两层——引擎层和存储层：橙色层为存储层，一般为DRDSHTAP子数据库子层用于表的MySQL实例（云上的RDS实例)，通常每个物理分库都会配置一主多备来保证高可用。灰色层是引擎层。引擎层使用集群来提供高可用性。集群中的每个节点都是DRDS的一个无状态服务器节点。服务器端包括处理MySQL协议的网络模块、查询优化器、TP引擎对应的一组执行算子。通常，业务OLTP类的SQL完全在服务器的TP引擎中执行。但是，如果业务的SQL是OLAP类型的复杂SQL，引擎层会将SQL对应的物理查询计划发送给右边的Fireworks引擎进行计算。Fireworks是一个基于Spark的具有DAG能力的并行执行引擎，可以进行MPP计算和Streaming计算。Fireworks中的每个Worker都会主动连接用户的MySQL备用数据库获取数据并进行计算。DRDSHTAP的Fireworks引擎细节如下图所示：左右两张图是TP引擎中SQL的对比。在TP引擎中，SQL采用单机单线程执行策略。而在Fireworks引擎中，物理SQL查询计划会被拆分成多个子任务，然后分发到多台Worker机器上进行并行计算。值得一提的是，相对于开源的SparkWorker只能下推PROJECT/SELECT两个算子，FireworksWorker接收到的物理执行计划经过DRDS优化器优化。因此，一些常见的算子操作如PROJECT/SELECT/JOIN（分库中的JOIN）/AGGREATION（分库中的AGG）/SORT会尽可能的被DRDS优化器下推到物理存储，这样可以避免大量的中间数据的网络开销和本地计算开销，从而加速MPP引擎的执行。对于一些需要跨多个分库分表读取数据才能完成的查询，Worker机器会使用多个线程并行扫描单条数据，避免大量的查询时间花费在网络IO上。下面说一下DRDSHTAPStreaming的引擎。DRDSHTAP的Streaming引擎是在SparkStreaming的基础上开发的。但是在DRDSHTAP系统引入SparkStreaming的过程中，我们对Streaming的稳定性和可靠性做了大量的优化工作。例如DRDSHTAP引入RocksDB作为Streaming的StateStore，实现流计算任务中的自动容灾和恢复。再举个例子，DRDSHTAP是根据MySQLSchema的timestamp列来实现输入流的。这样用户就可以使用标准的StreamingSQL语法来完成DRDSHTAP中的Streaming-StreamingJOIN等常见的Streaming计算操作。业务开发不再需要像使用开源的Streaming引擎（如Flink）那样配置复杂的数据同步链路，可以给用户带来极大的便利。在HTAP中保证业务TP和AP查询的稳定性和高可用是非常重要的。为实现这一目标，DRDS采用了查询链路隔离的技术方案。下图为链路隔离方案的架构，分为引擎层和存储层：存储层默认由MySQL实现一主多备。比如TP引擎默认只会访问主库，这样可以保证数据的一致性。默认情况下，Fireworks引擎只允许访问应用程序的备用数据库。这样，业务存储层的AP流量和TP在物理上自然隔离，保证互不干扰。由于备库承载的是OLAP类型的SQL，SQL通常比较复杂，备库被毁是大概率事件。因此DRDSHTAP可以实现多备库的自动容灾和切换。如果一个备库宕机，另一个备库可以继续提供服务，从而实现高可用。在引擎层，DRDS通常建议业务的OLTP流量由DRDS主实例承载，业务的OLAP流量由DRDS只读实例承载。这样，业务的AP和TP服务也可以在引擎上进行物理隔离，从而保证各自的稳定性和高可用。接下来看DRDSHTAP的查询优化器。下图显示了查询优化器的体系结构。优化策略以RBO为基础，CBO为辅。优化过程分为三个阶段：PreOptimizer，Sql的很多重写操作（例如SubQueryUnnesting/ConstantFolding等）都会在这个阶段完成，生成一个简单SQL重写的逻辑计划；Optimizer，这个阶段的优化器会进行很多常见的算子优化（例如PredicateInference/OperatorPushdown/ColumnPruning/JoinCluster/JoinReorder等），然后生成优化后的逻辑计划；PostOptimizer，在这个阶段DRDSHTAP被用作特定于分布式查询引擎的阶段。在这个阶段，优化器会根据SQL查询条件对分库分表进行分表计算，然后针对具体的分片重新进行与上一阶段类似的Partition-aware优化操作。原则上，优化器会尽量将算子下推到物理存储，这样可以大大降低引擎成本的执行压力和中间数据的网络传输成本，从而提高执行效率。对于一些必须跨越多个物理分片或者跨多个逻辑库才能完成计算的算子（比如跨库JOIN），无法下推物理存储，优化器会自动采用MPP执行策略。将物理计划直接发送到Fireworks引擎进行MPP计算。三、DRDSHTAP功能演示1、跨业务数据库的MPP查询在电商场景中，为了降低耦合度，通常会将业务系统拆分成很多子系统。下图是模拟电商场景对交易库、商品库、用户库进行关联查询的示意图。每个子系统都会使用一个单独的MySQL实例（即一个RDS实例）进行存储：一旦业务需要进行营销活动，比如双十一促销、发红包等，应用的逻辑必然会涉及到多个数据库实例的读写。由于MySQL本身无法支持跨实例级别的关联聚合查询，这会影响业务后台的数据分析、监控、对账。场景会带来很多麻烦，使用DRDSHTAP可以解决这个问题。DRDS将各个RDS数据库统一抽象为逻辑库的概念。简单理解，它会为每个库生成一份配置信息和元数据。整个过程中，用户不需要做任何数据导入或数据同步。操作。基于这一层逻辑库的抽象，普通用户可以像在单机MySQL中一样，自由地跨DRDS数据库进行关联分析查询，不需要对业务数据库做任何其他修改，带来了极大的便利。业务将多个RDS数据库（不分库分表）接入DRDS后，当其中一个业务数据库发展，单机RDS无法承载，需要分库分表时，则DRDS拆分的所有细节都将隐藏在逻辑库下。这个过程本身的应用是透明的。因此，无需修改业务后台分析应用的SQL，从而避免了大量的SQL修改成本。为了演示方便，我提前建好了交易库、用户库、商品库的表信息。交易库和用户库在RDSA上，商品库在RDSB上。右边的SQL是跨三个业务库的JOINSQL。首先我分别登录RDSA和RDSB的信息，可以看到上面数据库的信息。RDSA有交易库和用户库，RDSB有商品库。然后通过命令登录DRDS，可以看到三个库都在同一个地方。***会有一个结果，就是我要演示的跨多个业务库的复杂查询场景。在实际场景中，SQL会更复杂。比如盒马聚合查询的SQL要使用之前的方案，执行前必须将业务导入统一数仓。现在DRDSHTAP上只有一个跨模式查询。可完成SQL查询，在保证用户子系统独立性的同时，为实时分析带来极大便利。2.StreamingJoin我们再来看看Streaming引擎的功能演示。这里要演示的场景是一张又大又宽的桌子。许多应用程序在设计数据库表时都遵循一些标准的设计范例。比如用户的购买和下单行为，会把用户的详情、商品详情、用户的下单行为存储在三个不同的表中。用户在后台做数据分析时，会JOIN成一个又大又宽的表，方便。进行向上钻取或向下钻取分析。我要模拟的场景是如何使用streamingJOIN创建大而宽的表。Streaming非常适合与时间强相关的JOIN查询。比如每天查看最近一天的交易量，新订单数等。在整个演示场景中，假设T1和T2表是已经存在的表，然后再创建一个额外的结果表，可以用来固化流式服务的结果。我开始模拟一个普通用户在DRDSHTAP上使用StreamingJOIN。首先，T1和T2将构建在CERATESTREAM上，最后T1JION和T2Stream将使用JOIN构建。***将流结果写入结果表。看SQL的具体操作。首先使用命令执行构建两个流T1和T2，然后构建一个T1和T2JOIN的流。现在模拟向T1和T2引入数据，你会发现有JOIN结果。这样做的好处是结果的突然固化可以使查询非常快，因为不需要做中间计算。4.DRDSHTAP使用场景及局限性没有一个数据库可以适用于所有的业务场景，DRDSHTAP也是如此。DRDSHTAP适用于AP场景（此处忽略TP场景）主要分为两类：那些对并发和低延迟要求低的应用，尤其是跨多个业务数据库和表进行实时分析的场景；基于时间的streamingJOIN场景，比如事实表的streamingjoin或者维度表和事实表的streamingjoin，也适合和DRDSHTAP一起使用。但是OLAP有多种查询场景，很多查询场景并不适合DRDSHTAP，比如常见的全文快速搜索、AdHoc等查询场景。目前DRDSHTAP已经在公有云以解析只读实例的形式开放给用户使用。但DRDSHTAP未来会在技术层面不断优化，支持更多更复杂的在线场景和分析场景。讲师介绍了阿里巴巴数据库事业部技术专家、阿里巴巴分布式数据层中间件TDDL和云产品分布式关系数据库服务DRDS的技术负责人梁成辉（程碧）。多次担任??数据层稳定性负责人，保障双十一TDDL&DRDS的稳定性。目前主要专注于DRDSHTAP的技术研发，致力于提供云端OLTP和OLAP一体化解决方案。
