简介：第12个双11已圆满结束，但对技术的探索永不止步。每年双11，不仅仅是剁手族的狂欢节，更是数据人的“大考”，是检验阿里云数据库技术团队技术水平与技术创新实践的舞台。本站已陆续推出双11护航背后的数据库技术实践与经验分享系列干货文章，敬请关注！今天为云原生数据仓库AnalyticDB的技术解析。

前言

每年双十一购物狂欢节都是云原生数据仓库AnalyticDB MySQL版（原分析型数据库MySQL版）的一块试金石。今年AnalyticDB除了在阿里数字经济体内进入更多核心交易链路，全力支撑双十一以外，AnalyticDB全面拥抱云原生，构建极致弹性，大幅降低成本，释放技术红利，重磅发布了诸多全新企业级特性，让用户及时拥有极高性价比的云原生数据仓库。

云原生数据仓库AnalyticDB

云原生数据仓库AnalyticDB是一种支持高并发低延时查询的新一代云原生数据仓库，高度兼容MySQL协议以及SQL:2003 语法标准，可以对海量数据进行即时的多维分析透视和业务探索，快速构建企业云上数据仓库，实现数据价值的在线化。

AnalyticDB全面覆盖数据仓库场景，包括报表查询、在线分析、实时数仓、ETL等，应用范围广。AnalyticDB兼容MySQL和传统数据仓库生态，使用门槛低。

AnalyticDB全力支撑双十一

2020年双十一，AnalyticDB支持了阿里数字经济体内几乎所有BU的业务，承载了集团的菜鸟、新零售供应链、DT数据系列产品、数据银行、生意参谋、人群宝、达摩院店小蜜、AE数据、盒马、天猫营销平台等130多个主要业务。从核心交易链路的高并发在线检索到复杂实时分析应用场景，表现非常稳定。当天各项指标再创新高，AnalyticDB当天的写入TPS峰值到达2.14亿，通过离在线一体化架构，支持在线ETL及实时查询Job数达到174571个/秒，离线ETL导入导出任务570267个，处理的实时数据量达到7.7万亿行。

在本次双十一中，在公有云上支持聚水潭、递四方、EMS等诸多核心业务，在专有云上支持了中国邮政集团的各类业务。AnalyticDB数据库为这些业务方提供了数据处理ETL、实时在线分析、核心报表、大屏和监控能力，为数十万商家和千万消费者提供稳定的离在线数据服务。

AnalyticDB面临的挑战

双十一的一连串亮眼数据背后，AnalyticDB也面临极大的挑战，主要体现在：

1、进入集团核心交易链路
AnalyticDB开始正式接入集团内的核心交易链路，进入集团核心交易业务买家分析库业务，这对AnalyticDB的实时高并发写入、在线检索的能力提出了极高的要求。双十一总共超过600亿条订单记录，其中双十一1号0点和0点30分预付尾款的多波峰值达到500万TPS，是日常的100倍。Query 95分位RT在10ms以内。

AnalyticDB全新研发的行存引擎首次表现亮眼，可支持千万级QPS在线高并发检索和分析，关键技术点包括高并发查询链路、全新的行存存储、任意列TopN下推、联合索引、智能索引选择等，实现了单节点10000+QPS并可线性扩展。在相同资源下，单表点查、聚合及TopN是开源ElasticSearch的2-5倍，存储空间节省50%，写入性能是其5-10倍，并且保证数据的实时可见和数据高可靠。

2、进入更多生产作业环节
这一年来，AnalyticDB深入到菜鸟仓储的核心作业环节。仓库操作人员的数据看板、数据核对、发货操作等都依赖AnalyticDB的高并发实时写入、实时查询和相关的数据分析能力，每秒峰值6000订单。ADB作为菜鸟数仓引擎，实时监控亿级包裹在仓、揽、干、运、配每个作业节点的状态，确保每一笔订单都能按时履约，极大提升了用户体验。在11月1日的第一波流量峰值中，菜鸟仓储单实例的TPS 40万+，QPS 200；供应链履约单实例TPS峰值160万，1200 QPS。

菜鸟数仓数据架构图：

3、接入更多的导入任务
一些依赖数据洞察（类似DeepInsight）的业务，他们本身也是平台方，上面每天都大量的导入任务，且这些任务需要在规定的时间内导入完成，有些甚至配置了基线要求，不仅要求所有任务在规定的时间点导入完成，还要求每个任务在规定的时间点内完成。这在原来AnalyticDB 2.0上（依靠跑MapReduce任务）是不可想象的，然而在AnalyticDB 3.0上可以轻松地跑完。AnalyticDB 3.0的任务导入做到更加轻量和实时。以11月8日的导入任务为例，9074个任务最长的只需要921秒，最短的3秒完成，平均时长39秒完成。

4、接入更多高吞吐的写入业务
类似数据银行之类的业务，每天会有大量的数据导入，导入的数据量巨大，对AnalyticDB的写入吞吐量要求极高，双十一前后数据银行的AnalyticDB TPS峰值写到近1000万，写入流量达到1.3GB/s。数据银行利用AnalyticDB实现人群画像、自定义分析、触发式计算、实时引擎和离线加速。单库存储了6PB+的数据，中间使用了大量的复杂SQL的交并差、group by、count、distinct、多张万亿级别的大表的join操作。

5、在线离线混合负载
基于在线分析和离线ETL混合负载的能力，AnalyticDB支持了AE中台的多个双十一业务：商家端业务实现100 QPS的基于明细事件的商家端人群预估，将复杂的画像从平均10秒钟降低到平均3秒内。相比于传统将商家的事件加工为物化的标签，通过明细事件的分表过滤能力大幅度降低了基于事件的新人群的上线时间，从原先需要数据开发一周的工作量，降低到半天的数据配置。基于AnalyticsDB实现了AE用户洞察人群的实时聚类，从原先离线的20分钟离线聚类提升为分钟级别的在线聚类，并实现了权益分包算法的准实时化，从原先离线的20分钟分包，提升为在线的分钟级分包。后续AE、Lazada的在线人群缩放，精排都能够基于在线的AnalyticDB算法实现算法的在线化，帮助国际化提升人群、商品运营的整体效率。

AnalyticDB最新关键技术

过去一年，AnalyticDB完美承载起阿里数字经济体业务和阿里云公有云+专有云业务，其背后，AnalyticDB技术架构全面拥抱云原生，AnalyticDB完成了重大架构升级，在公有云上也同步发布了新版弹性模式，让用户拥有极高性价比、极致弹性的新一代数据仓库。以下将对新版弹性模式的关键技术点一一道来。

计算存储分离

AnalyticDB预留模式的产品形态是采用Shared-Nothing架构，具备良好的扩展性和并发性。后端采用计算与存储耦合的方式，两者共享相同的资源。存储容量和计算能力均与节点数有关。用户可以通过扩容、缩容节点数来调整自己的资源需求，但是没法自由搭配计算与存储资源配比，来满足不同的业务负载需求。此外，节点数的调整往往面临大量的数据迁移，会花费比较长的时间，对当前系统的运行负载也有一定的影响。另外，计算、存储不能灵活配比，也导致性价比成为一个问题。

全面拥抱云平台的弹性能力，AnalyticDB主推新弹性模式的产品形态，后端采用了计算存储分离的新架构，提供统一的服务化Serverless存储层，计算层可以独立弹性扩展，同时兼具了预留模式的性能。通过计算与存储的解耦，用户可以较为灵活地单独对计算资源、存储容量进行扩缩，更加合理控制总成本。针对计算资源的扩缩，不再需要数据的搬迁，具备更极致的弹性体验。

数据冷热分层

数据存储的高性价比是云上数据仓库的核心竞争力之一，AnalyticDB具备数据冷热分离这一企业级特性。AnalyticDB可以按表粒度、表的二级分区粒度独立选择冷、热存储介质，比如指定用户表数据全部存储在SSD，或指定表数据全部存储在HDD，或指定这个表的一部分分区数据存储在SSD，另一部分分区数据存储在HDD，完全可以按业务需求自由指定，并且冷热策略可以任意转换。同时，热数据和冷数据的空间使用是Serverless按量计费的。未来AnalyticDB将实现智能冷热分区，即自动根据用户业务访问模型，提前对冷数据进行预热。

冷热存储定义

冷热分离的第一步是确定冷热的粒度和边界。AnalyticDB冷热分离技术延用了现有的二级分区机制，即以分区为冷热存储的基本单位。热分区存储在节点SSD盘上，获得最好的性能，冷分区存储在OSS上，以达到最低的存储成本。

用户可以定义全热表（所有分区在SSD），全冷表（所有分区在OSS），以及混合表（部分分区在SSD，部分在OSS）来灵活使用，达到性能与成本的平衡。如下是一个游戏日志表的实例，采用混合分区策略，最新7天的数据存储在热区，7天前的数据存储在冷区。

create table event(
id bigint auto_increment
dt datetime,
event varchar,
goods varchar,
package int
...
) distribute by hash(id)
partition by value(date_format(dt, '%Y%m%d')) lifecycle 365
storage_policy = 'MIXED' hot_partition_count = 7;

冷热数据自动迁移

AnalyticDB数据写入时，数据会首先进入热空间SSD上，当热存储数据积累到一定程度或者用户指定的冷表策略时会自动调度后台的Build任务，把数据迁移到冷存储空间。对于用户来说，写入和查询完全是透明的。

之所以这样设计是借鉴了写读优化存储的设计理念，为了实现高效任意维组合分析能力，AnalyticDB默认是自适应全索引，即每个列上都有列级索引，这保证了AnalyticDB的查询性能做到开箱即用，但这会对写入性能带来较大挑战。因此AnalyticDB采用类LSM架构，把存储分为实时和历史两部分，实时部分采用行存混存的块级粗糙索引，历史部分采用全索引以保证极快的查询性能，并且通过后台数据构建任务（Build）实现实时到历史分区的转换。冷热分区自动迁移的机制是：

• 数据积累到一定程度，内部自动调度Build任务，对实时数据建立快照，进行数据整理，构造出新的历史分区（Partition），并根据冷热策略将这些历史分区（Partition）分别写入热区和冷区。
• 在Build调度的同时，根据冷热策略的滑动窗口，自动把历史分区从热区迁移到冷区。下图中，定义的热分区个数为3，在11月4日，热分区为11-04、11-03日、11-02日共3个，在11月5日，写入了新的11-05的数据，根据滑动窗口，最新的热分区为11-05、11-04、11-03三个，因此在Build时，会触发热分区到冷分区的迁移，11-02分区自动迁移到冷区。

冷数据查询加速

冷区降低了存储成本，但增加了数据访问的开销。虽然AnalyticDB已经做了分区裁剪、计算下推等优化，仍避免不了需要对历史分区做随机和吞吐扫描。为了加速对冷分区的查询性能，AnalyticDB在存储节点开辟了一部分SSD空间作为Cache。利用这块SSD Cache，AnalyticDB做了如下优化：

• 不同粒度的SSD Cache Entry，确保可以同时兼顾索引的随机查找和吞吐型数据扫描。
• 元信息预热，每次Build结束，会自动生成冷分区的元信息，加速访问
• 无锁化的冷热访问队列，避免经常访问的数据被频繁换入换出。

冷热存储使用

1、全热表：适用于整张表全部数据都被频繁访问，并且对访问性能要求比较高。DDL如下：

create table t1(
 id int,
 dt datetime
) distribute by hash(id) 
partition by value(date_format('%Y%m',dt) 
lifecycle 12 
storage_policy = 'HOT';

2、全冷表：适用于整张表全部数据都不频繁访问，并且对性能访问要求不高。DDL如下：

create table t2(
 id int,
 dt datetime
) distribute by hash(id) 
partition by value(date_format('%Y%m',dt) 
lifecycle 12 
storage_policy = 'COLD';

3、冷热混合表：适用于数据冷热有明显时间窗口，比如，最近一个月数据是频繁访问且对性能有较高要求，而之前的数据是冷数据，只是偶尔访问。针对这种场景，DDL如下：

create table t3(
 id int,
 dt datetime
) distribute by hash(id) 
partition by value(date_format('%Y%m',dt) 
lifecycle 12 
storage_policy = 'MIXED' hot_partition_count=1;

整张表按照月做二级分区，总共保存12个月，最近一个月的数据保存在SSD上，一个月以前的数据保存在HDD上。通过这样设置，性能和成本达到良好的平衡。

*在离线一体化
*

AnalyticDB使用一套引擎，同时支持了面向低延迟的在线分析，和面向高吞吐的复杂ETL。

混合计算负载

在存储计算分离的架构下，AnalyticDB的计算能力也得到了极大的释放，可以支持非常丰富和强大的混合计算负载能力，在经典的在线（online）/交互式（interactive）查询执行模式之外，也支持了离线/批处理(batch)查询执行模式，同时可以通过集成开源的计算引擎（比如Spark）来支持迭代计算和机器学习等复杂计算能力。

在线分析（Online/Interactive）
在线查询基于MPP架构，中间结果和算子状态完全使用内存（all-in-memory），计算过程完全流水线化（pipelined），查询RT小，适用于低延迟、高并发的场景 ，比如BI报表、数据分析、在线决策等。

批处理（Batch）
批处理模式基于DAG执行模型，整个DAG可以切分为若干个stage进行，stage-by-stage执行，中间结果和算子状态可以落盘，支持大吞吐量的数据计算能力，也可以在较少的计算资源场景下执行，具备更低的计算成本，适用于数据量大或者计算资源有限的场景，比如ETL、数据仓库等。

复杂计算（Iterative/ML等）
AnalyticDB提供了开放和可扩展的计算架构，通过集成和兼容开源生态的计算引擎（目前为Spark）为用户提供复杂计算能力。用户可以基于Spark的编程接口（DataFrame/SparkSQL/RDD/DStream）来编写更加复杂的计算逻辑，满足业务越来越智能化和实时化的数据应用场景，比如迭代计算，机器学习等。

资源组（池）多租户

AnalyticDB新版弹性模式下，支持了资源组功能，即对计算资源进行弹性划分，不同资源组之间的计算资源在物理上完全隔离。通过AnalyticDB账号绑定到不同的资源组，SQL查询根据绑定关系自动路由至对应的资源组执行命令，用户可以选择为不同的资源组设置不同的查询执行模式，从而满足用户实现实例内部多租户、混合负载的需求。

资源组相关命令

-- 创建资源组
CREATE RESOURCE GROUP group_name
    [QUERY_TYPE = {interactive, batch}] -- 指定资源组查询执行模式
    [NODE_NUM = N] -- 资源组节点个数
    
-- 绑定资源组
ALTER RESOURCE GROUP BATCH_RG ADD_USER=batch_user

-- 调整资源组大小
ALTER RESOURCE GROUP BATCH_RG NODE_NUM=10

-- 删除资源组
DROP RESOURCE GROUP BATCH_RG

资源组可以支持不同的查询执行模式：

1. interactive：采用all-in-memory、pipelined的方式执行，适用于延迟要求高的在线分析
2. batch：采用Stage by stage执行模型，中间结果、算子状态可以落盘，适用于高吞吐，延迟要求低的查询，具备更低的计算成本

分时弹性

一般情况下，业务具备非常明显的波峰波谷，低峰期资源往往处于闲置阶段。AnalyticDB分时弹性功能可以让这类用户定制弹性计划（每天定时、每周定时），在业务高峰期来临之前自动进行扩容满足业务流量。定时的弹性计划即满足了业务流量高峰的需求，又降低了AnalyticDB使用成本。结合资源组功能，用户甚至可以让某个资源组在低峰期时0节点，成本极低。

智能优化

查询优化是影响数据仓库系统性能的关键因素，如何生成更优的执行计划、以何种方式分区、如何配置索引、何时更新统计信息等等问题经常对数据开发人员造成困扰。AnalyticDB一直深耕于智能优化技术，通过实时监控运行的查询，动态调整执行计划和其依赖的统计信息，自动提高查询性能；内置智能算法，可以依据系统的实时运行状态，动态调整引擎参数以适应当前的查询负载。

智能调整

智能调整是一个连续的监控和分析过程，通过不断的分析当前工作负载的特征，来识别潜在的优化并加以调整，并根据调整后实际的性能收益，来决策是否回滚或进一步的分析。

**动态执行计划调优
**

查询计划经常会由于统计信息、代价模型等原因导致性能回退。AnalyticDB充分利用了运行中与运行后的执行信息，进行执行计划的事中和事后调整。并通过对历史的执行计划和对应的运行指标进行机器学习，调整执行计划的代价预估算法，使其更加贴合当前的数据特征和工作负载，随着不断的学习和调整，达到自动优化的目标，让用户觉得越用越好用。

动态管理物化视图

物化视图(Materialized view)是数仓领域核心特性之一，可以帮助用户加速分析，简化数据清洗流程(ETL: Extract, Load, Transform)，应用场景十分广泛。比如：大屏类业务加速，配合BI工具使用，或者是缓存一些公共中间结果集用以加速慢查询。AnalyticDB从3.0版本开始逐步支持物化视图，可以高效的维护物化视图，并提供全自动的更新机制。

结语

AnalyticDB定位为新一代的云原生数据仓库，在一个系统中实现在离线一体化，成功赋能双十一诸多业务，抗住极端业务负载，也进一步提升业务上数据价值挖掘的实时性。随着平台的业务演进和技术演进，AnalyticDB也在不断构建企业级数仓的能力，近期AnalyticDB已释放新版弹性的核心能力，极致弹性和高性价比，真正让用户所购即所得。

原文链接：

除特别声明，本站所有文章均为原创，如需转载请以超级链接形式注明出处：SmartCat's Blog