一、背景随着云时代的到来，数据库也开始拥抱云数据库时代。各种数据库系统（OLTP、OLAP、NoSQL等）部署在各种内外云平台（AWS、Azure、阿里云）全面开花，包括从传统数据库开源的MySQL、PostgreSQL、MongoDB、SQLServer、Oracle厂商，以及云厂商开发的Aurora、Redshift、PolarDB、AnalyticDB、AzureSQL等。部分数据库还处于云托管阶段，只是将原有架构迁移到云主机上，利用云资源。一些数据库已经进入CloudNative阶段，基于云平台IAAS层的基础设施，构建弹性、Serverless、数据共享等能力。本文主要介绍阿里云的云原生数仓AnalyticDBMySQL版（以下简称AnalyticDB）这几年在弹性方向的探索和成果。2、为什么要将计算和存储分开？MPP（MassiveParallelProcessing）架构是OLAP数据库最常用的技术架构。MPP架构下，计算和存储共享一个节点，每个节点都有自己独立的CPU、内存和磁盘资源，彼此不共享。数据通过一定的分区规则（hash、random、range）分散到不同的节点。在处理查询时，每个节点并行处理自己的数据，彼此之间不存在资源竞争，具有比较好的并行执行能力。这种将存储资源和计算资源紧密耦合的架构，在云时代并不容易满足不同场景下不同的工作负载需求。比如数据导入任务，往往需要消耗比较大的IO和网络带宽，但是CPU资源的消耗并不大。然而，复杂的查询任务往往会消耗大量的CPU资源。因此，面对这两种不同的工作负载，在选择资源规格时，需要结合不同的工作负载进行不同类型的选择，很难用一种资源规格同时满足两种类型。因为业务在不断发展，工作量也在不断变化，很难提前规划。当业务发展时，对CPU资源有更高的需求。当我们扩展集群来扩充CPU资源的时候，也会造成数据的重新洗牌，会消耗比较大的网络带宽和CPU资源。即使是建立在云平台上的数据仓库，也无法通过在查询低峰期释放部分计算资源来降低使用成本，因为这也会造成数据重新洗牌。这种耦合架构限制了数据仓库的灵活性。通过分离存储资源和计算资源，您可以独立规划存储和计算资源的规格和容量。这样可以相对快速地完成计算资源的扩容、缩容和释放，无需额外的数据迁移成本。存储和计算也可以更好地结合各自的特点，选择更适合自己的资源规格和设计。三、行业趋势1、Redshift作为AWS上最受欢迎的数据仓库产品，采用MPP架构，一直在向弹性方向演进。Redshift于2018年11月推出了Elasticresize功能，与classicresize相比，其扩缩时间大大缩短。2019年11月，进一步上线ElasticResize调度，允许用户配置扩容和缩容计划，实现自动弹性。此外，Redshift于2019年12月正式推出RA3形式，采用计算与存储分离的架构。数据存储在S3上。计算节点采用高性能SSD作为本地缓存，加速数据访问。在这种架构下，计算和存储可以独立弹性，具有很好的弹性能力。2.SnowflakeSnowflake从诞生的第一天起就采用了计算存储分离的架构。作为跨云平台的云数据仓库，其存储层为对象存储（可以是AWSS3、AzureBlob等），计算层为虚拟仓库（简称VW），每个用户可以创建一个或多个对应的VW，每个VW是由若干个EC2（AWS上的虚拟主机）组成的集群。这样可以根据不同的工作负载为不同的用户灵活创建不同规格的VW，用户之间的隔离性很好。基于VW的灵活性，Snowflake支持VW的自动挂起、恢复和自动伸缩能力，通过计算和存储分离带来的弹性能力，为用户带来“按需付费”的体验。4.AnalyticDB的弹性模式与Redshift类似。AnalyticDB最初是基于传统的MPP架构构建的。2020年5月，AnalyticDB推出计算存储分离架构的弹性模式。AnalyticDB的弹性模式分为访问层、计算层和存储层。接入层兼容MySQL协议，包括权限控制、优化器、元数据、查询调度等模块，负责数据的实时写入和查询。1、存储层弹性架构下，存储层负责实时数据写入、索引构建、数据扫描、下推谓词计算（过滤、列剪枝、分区剪枝等），不再是负责查询计算任务。存储层的数据仍然按照MPP的方式组织，数据以hash和random的形式均匀分散在分区（shards）中。分区（分片）方式可以轻松实现实时数据写入的强一致性，同时在数据扫描过程中，可以实现分片级别的并发读取，保证并发性。同时，存储层提供冷热一体化分层存储能力。数据可以以热表的形式存储在本地SSD，也可以以冷表的形式存储在底层DFS，也可以以冷热表混合的形式存储，实现冷热数据的融合。自动迁移，详见文章《数据仓库分层存储技术揭秘》。2.计算层在弹性模式下，计算层由若干个计算节点组成。计算节点负责接收接入层下发的物理执行计划，并根据物理执行计划转换为相应的算子。计算层采用矢量化执行模型，算子之间的数据以流水线的形式进行交互。几行（通常是几千行）数据组成一个batch，batch内部数据以列存的形式组织。另外计算层的JIT模块会根据查询计划动态生成代码加速计算，包括表达式计算、排序、类型比较等。JIT模块也以计划模式为key缓存动态生成的代码，从而降低交互式查询下动态生成代码的成本。3.在执行计划、计算和存储分离架构下，计算层新增了一个reshardingoperator，负责从存储层加载数据。数据以批存储和列存储的形式在存储层和计算层之间传输。单个请求会传输多批数据，一般不超过32MB。由于存储层仍然保留了MPP数据预分区的方式，优化器在生成执行计划时会根据这种分布特性减少join和agg操作时不必要的数据重新分区。此外，优化器还会判断查询中的filter是否可以使用存储层索引，并尝试将存储层可以识别的filter下推到存储层使用索引加速过滤，减少数据与计算层传输。无法下推的过滤器仍然保留在计算层进行过滤。4.分区动态重分配在Resharding算子和Scan算子之间，分区（分片）按照以下原则进行重分配：来自同一个存储节点的多个分区应该尽可能分散到不同的计算节点。在同一个查询中，不同表的同一个分区会映射到同一个计算节点。同一分区在不同查询之间随机分配给不同的计算节点。不同于Snowflake和Redshift，计算节点和分区之间没有固定的映射关系，因为计算节点没有本地缓存??，数据访问的加速完全依赖于存储层的SDD和内存缓存。这种动态重分配方式可以极大缓解分区不均匀、分区数据倾斜等问题，不会对固定计算节点造成热点。5.数据加载优化与原有架构相比，计算和存储分离，多了一次远程数据访问，对查询延迟和吞吐量会有比较大的影响。我们优化了以下方面：合并网络连接。如图3所示，通过合并连接，减少了小数据量查询的网络交互次数，降低了查询延迟。数据压缩。batch基于列存格式进行压缩，减少了网络带宽的消耗，有效提升了resharding算子的加载吞吐量。异步读取。网络模块异步加载，将数据放入缓冲区，resharding算子从缓冲区中获取数据，使CPU和网络IO完全并行化。6.性能测试本节将探讨计算存储分离架构对AnalyticDB大数据量分析场景查询吞吐量的影响。测试环境示例1：非分离模式，4组存储节点，存储节点负责数据扫描，查询计算。示例2：弹性模式，4组存储节点+6个计算节点。存储节点负责数据扫描，计算节点负责查询计算。两个实例分别导入tpch1TB数据作为测试数据集。存储节点计算节点不分离模式4*3*8core弹性模式4*3*8core6*16core测试场景我们选择TPCHQ1作为测试SQL，Q1是单表聚合查询，收敛度非常高，存储层与计算层之间传输的数据量约为260GB。我们以单并发顺序执行的方式执行TPCHQ1，取查询的平均执行时间。selectl_returnflag,l_linestatus,sum(l_quantity)assum_qty,sum(l_extendedprice)assum_base_price,sum(l_extendedprice*(1-l_discount))assum_disc_price,sum(l_extendedprice*(1-l_discount)*(1+l_tax))assum_charge,avg(l_quantity)asavg_qty,avg(l_extendedprice)asavg_price,avg(l_discount)asavg_disc,count(*)ascount_orderfromlineitemwhereel_shipdate<=date'1998-12-01'-interval'120'daygroupbyl_returnflag,l_linestatusorderbyl_returnflag,lTP_linestatus计算节点QCPU消耗1测试数据CPU消耗无分离模式83s98%弹性模式81s19.5%97%测试结论从上面的测试数据可以看出，TPCHQ1在弹性模式下的执行时间稍好一些。乍一看，这个结果相当令人意外。计算和存储分离后，性能更好。我们可以仔细分析，灵活模式和非分离模式的存储节点数量相同，保证分离模式下的存储节点不会成为瓶颈。从执行时的资源消耗来看，分离模式的总资源消耗（19.5%+97%）是非分离模式（98%）的1.19倍，额外的CPU消耗来自于网络传输、序列化，以及反序列化等等。对于计算层来说，只要存储层能够提供足够的数据吞吐量，保证计算层的CPU能够得到充分利用，计算存储分离并不会降低查询的处理吞吐量。当然，与非分离模式相比，它会消耗更多的资源。5.总结基于AnalyticDB的弹性模型，我们未来会进一步发展我们的弹性能力，包括计算资源池化，按需弹性能力，以及基于共享存储的存储层快速扩缩容能力。通过这些弹性能力，可以更好地满足客户对云数据仓库的需求，进一步降低客户的使用成本。
